[swift-evolution] [swift-dev] [Compiler] Help IR gen in targetting MSVC

[Sangjin Han]

I made a PR https://github.com/apple/swift/pull/2351 introducing os(Cygwin).


2016-04-27 5:54 GMT+09:00 John McCall <rjmccall at apple.com>:

> > On Apr 26, 2016, at 1:39 PM, Joe Groff <jgroff at apple.com> wrote:
> >> On Apr 26, 2016, at 1:24 PM, John McCall via swift-evolution <
> swift-evolution at swift.org> wrote:
> >>
> >>> On Apr 26, 2016, at 1:03 PM, Sangjin Han <tinysun.net at gmail.com>
> wrote:
> >>> The problem can be solved by modifying that code. Thanks you. I
> thought that code will affect only to the CLong type not Int.
> >>
> >> It changes what 'long' gets imported as.  If there's a Windows API
> defined using 'long' (rather than some more meaningful typedef like
> 'size_t'), it's important for it to be imported as Int32 rather than Int,
> since 'long' is always 32 bits under MSVC.
> >>
> >>> But I meet another problem to fix it. I couldn't find the conditional
> method to distinct x86_64-*-windows-msvc with x86_64-*-windows-cygnus in
> Swift source.
> >>>
> >>> "#if os(Windows)" can not distinct MSVC from Cygwin.
> >>>
> >>> Should I add new condition 'env()' for the environment?
> >>
> >> That is an excellent question.
> >>
> >> My understanding / memory is that, as far as their programming
> interfaces goes, Cygwin and MSVC are very, very different environments.
> Maybe it's useful to have a condition that's true for both environments —
> although I'm not sure why it would — but I don't think it deserves to be as
> prominent as os(Windows).  So my gut reaction is that, rather than adding a
> #env, we ought to just reserve os(Windows) for MSVC compatibility and make
> a new os(Cygwin) for Cygwin.
> >>
> >> This needs to be raised on swift-evolution, though.  CC'ing that list.
> >
> > It's an interesting question. Mingw, Cygwin, and MSVC definitely vary
> greatly in ABI and C language level behavior, but the underlying Win32
> system libraries remain the same. I think it makes sense to consider them
> different os(...) environments, but it would also make sense IMO to have a
> broader platform check for Win32.
>
> If, after import and however much magic, they both end up exposing a
> similarly-typed set of system APIs, I agree that it makes sense to have a
> condition that says "yes, the target has those APIs".  It certainly seems
> like a worthwhile goal for Swift to present them with the same imported
> types.
>
> John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160430/a727f8a1/attachment.html>