make build with MSVC #21578
make build with MSVC #21578
Conversation
This adjusts the sources to build with Visual Studio. This is helpful in cases where the compiler needs to be debugged on Windows.
|
@jrose-apple - the @mikeash - I'm not sure if there is any option for the I'd like to figure out what we can do here so I can setup continuous builds for the compiler using cl. |
|
@swift-ci please test |
| @@ -29,11 +29,19 @@ typedef __SIZE_TYPE__ __swift_size_t; | |||
| #endif | |||
|
|
|||
| // This selects the signed equivalent of the unsigned type chosen for size_t. | |||
| #if defined(_MSC_VER) | |||
There was a problem hiding this comment.
Hmm, I suppose that this should be:
#if defined(_MSC_VER) && !defined(__clang__) ...
I think we want both here, really: |
| #if defined(_MSC_VER) | ||
| #if defined(_M_X86) || defined(_M_ARM) | ||
| typedef int ssize_t; | ||
| #elif defined(_M_AMD64) || defined(_M_ARM64) |
There was a problem hiding this comment.
_WIN64 then _WIN32, maybe? Although I'm wondering why MSVC is ever even looking at this header; it should always be compiled with the just-built Clang, no?
There was a problem hiding this comment.
Whoah... its a wild @jrose-apple!
There was a problem hiding this comment.
@jrose-apple - nope, because this is getting indirectly included into the compiler. It is really sad that we cannot limit this header to just the stdlib/runtime which I would really prefer.
There was a problem hiding this comment.
That seems…wrong. Maybe that's the thing worth tackling: figuring out which runtime / shims headers need to go into the compiler and separating them out.
There was a problem hiding this comment.
@jrose-apple I agree. I had tried to remove the use of the header, but @jckarter didn't want to lose the re-use of the types defined in the headers IIRC.
There was a problem hiding this comment.
That's what I would recommend; the only place we need to avoid using the platform headers is when importing the header to build the standard library.
There was a problem hiding this comment.
ssize_t is not available on all platforms as it is not mandated by the standard, it is an extension.
There was a problem hiding this comment.
It's probably the same as ptrdiff_t, if SSIZE_MAX isn't defined? Or intptr_t.
EDIT: Or std::make_signed<std::size_t>::type.
There was a problem hiding this comment.
SSIZE_MAX is also not available IIRC. Yes, we should be able to use std::make_signed<std::size-t>::type but obviously only in the C++ context.
There was a problem hiding this comment.
Yeah, I meant to use the absence of SSIZE_MAX as a signifier to use a fallback type, but in practice I think it'd be valid to say that these headers must be included in either a Swift or a C++ context. (Note that Swift should be tested first, since someday we'll probably have C++-in-Swift. Somehow.)
Unfortunately, MSVC doesn't like the |
Or conditionalize it somehow. Or use an enum instead of a constant, though I hate doing that. |
|
Catching up after an extended winter break.... @compnerd The generic |
|
#21979 takes care of the storage |
This adjusts the sources to build with Visual Studio. This is helpful
in cases where the compiler needs to be debugged on Windows.
Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.
Resolves SR-NNNN.