Exit


(Drew Crawford) #1

on Darwin, we can say:

import Foundation
exit(2)

I'm not totally sure how this works, since exit is provided by Darwin, not by Foundation. But somehow importing Foundation imports Darwin as well.

I think for source compatibility, we should support this, because people <http://stackoverflow.com/questions/34186994/swift-2-2-on-linux-use-of-unresolved-identifier-exit> are asking <http://stackoverflow.com/questions/24102157/seeking-an-exit-equivalent-in-swift> why it doesn't work out of the box.

I considered PRing an exit implementation in corelibs-foundation, but I think that might cause the opposite problem–introduce a conflict between Darwin/Glibc exit and Foundation "exit".

Can someone speak to how this is solved in Darwin Foundation and what we should do about it?


(Tony Parker) #2

Hi Drew,

I assume this works on Linux if you import Glibc as well?

- Tony

···

On Jan 14, 2016, at 8:44 AM, Drew Crawford via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:

on Darwin, we can say:

import Foundation
exit(2)

I'm not totally sure how this works, since exit is provided by Darwin, not by Foundation. But somehow importing Foundation imports Darwin as well.

I think for source compatibility, we should support this, because people <http://stackoverflow.com/questions/34186994/swift-2-2-on-linux-use-of-unresolved-identifier-exit> are asking <http://stackoverflow.com/questions/24102157/seeking-an-exit-equivalent-in-swift> why it doesn't work out of the box.

I considered PRing an exit implementation in corelibs-foundation, but I think that might cause the opposite problem–introduce a conflict between Darwin/Glibc exit and Foundation "exit".

Can someone speak to how this is solved in Darwin Foundation and what we should do about it?

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev


(Philippe Hausler) #3

The reason is that Foundation on darwin re-exports modules below it (by the virtue of objective-c headers) and the linux version is not re-exporting Glibc.

···

On Jan 14, 2016, at 8:44 AM, Drew Crawford via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:

on Darwin, we can say:

import Foundation
exit(2)

I'm not totally sure how this works, since exit is provided by Darwin, not by Foundation. But somehow importing Foundation imports Darwin as well.

I think for source compatibility, we should support this, because people <http://stackoverflow.com/questions/34186994/swift-2-2-on-linux-use-of-unresolved-identifier-exit> are asking <http://stackoverflow.com/questions/24102157/seeking-an-exit-equivalent-in-swift> why it doesn't work out of the box.

I considered PRing an exit implementation in corelibs-foundation, but I think that might cause the opposite problem–introduce a conflict between Darwin/Glibc exit and Foundation "exit".

Can someone speak to how this is solved in Darwin Foundation and what we should do about it?

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev


(Tony Parker) #4

Do we control this via the module map or some other mechanism?

I could see re-exporting Glibc on Linux as a reasonable solution for now.

- Tony

···

On Jan 14, 2016, at 9:04 AM, Philippe Hausler via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:

The reason is that Foundation on darwin re-exports modules below it (by the virtue of objective-c headers) and the linux version is not re-exporting Glibc.

On Jan 14, 2016, at 8:44 AM, Drew Crawford via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:

on Darwin, we can say:

import Foundation
exit(2)

I'm not totally sure how this works, since exit is provided by Darwin, not by Foundation. But somehow importing Foundation imports Darwin as well.

I think for source compatibility, we should support this, because people <http://stackoverflow.com/questions/34186994/swift-2-2-on-linux-use-of-unresolved-identifier-exit> are asking <http://stackoverflow.com/questions/24102157/seeking-an-exit-equivalent-in-swift> why it doesn't work out of the box.

I considered PRing an exit implementation in corelibs-foundation, but I think that might cause the opposite problem–introduce a conflict between Darwin/Glibc exit and Foundation "exit".

Can someone speak to how this is solved in Darwin Foundation and what we should do about it?

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev


(Drew Crawford) #5

It does, but on Darwin, importing Foundation alone is sufficient.

···

On Jan 14, 2016, at 11:03 AM, Tony Parker <anthony.parker@apple.com> wrote:

Hi Drew,

I assume this works on Linux if you import Glibc as well?

- Tony

On Jan 14, 2016, at 8:44 AM, Drew Crawford via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:

on Darwin, we can say:

import Foundation
exit(2)

I'm not totally sure how this works, since exit is provided by Darwin, not by Foundation. But somehow importing Foundation imports Darwin as well.

I think for source compatibility, we should support this, because people <http://stackoverflow.com/questions/34186994/swift-2-2-on-linux-use-of-unresolved-identifier-exit> are asking <http://stackoverflow.com/questions/24102157/seeking-an-exit-equivalent-in-swift> why it doesn't work out of the box.

I considered PRing an exit implementation in corelibs-foundation, but I think that might cause the opposite problem–introduce a conflict between Darwin/Glibc exit and Foundation "exit".

Can someone speak to how this is solved in Darwin Foundation and what we should do about it?

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev


(Chris Lattner) #6

Do we control this via the module map or some other mechanism?

I could see re-exporting Glibc on Linux as a reasonable solution for now.

This seems like the best short-term solution to me.

It would be ideal (IMO) to define a common “POSIX” (or something like that) module which would have shared unix level interfaces that would portable to all platforms. Then corelibs-foundation could re-export THAT module, providing a common set of APIs on all platforms. A POSIX module would also eliminate the annoying #import glibc/darwin #ifdef dance in many cases.

-Chris

···

On Jan 14, 2016, at 9:04 AM, Tony Parker via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:

- Tony

On Jan 14, 2016, at 9:04 AM, Philippe Hausler via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:

The reason is that Foundation on darwin re-exports modules below it (by the virtue of objective-c headers) and the linux version is not re-exporting Glibc.

On Jan 14, 2016, at 8:44 AM, Drew Crawford via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:

on Darwin, we can say:

import Foundation
exit(2)

I'm not totally sure how this works, since exit is provided by Darwin, not by Foundation. But somehow importing Foundation imports Darwin as well.

I think for source compatibility, we should support this, because people <http://stackoverflow.com/questions/34186994/swift-2-2-on-linux-use-of-unresolved-identifier-exit> are asking <http://stackoverflow.com/questions/24102157/seeking-an-exit-equivalent-in-swift> why it doesn't work out of the box.

I considered PRing an exit implementation in corelibs-foundation, but I think that might cause the opposite problem–introduce a conflict between Darwin/Glibc exit and Foundation "exit".

Can someone speak to how this is solved in Darwin Foundation and what we should do about it?

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev


(Philippe Hausler) #7

So we should be using `@exported import Glibc` on linux and `@exported import Darwin` on darwin then? Does this need to be for every import of Glibc? or just one somewhere in the swift files?

···

On Jan 17, 2016, at 10:11 AM, Chris Lattner <clattner@apple.com> wrote:

On Jan 14, 2016, at 9:04 AM, Tony Parker via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:

Do we control this via the module map or some other mechanism?

I could see re-exporting Glibc on Linux as a reasonable solution for now.

This seems like the best short-term solution to me.

It would be ideal (IMO) to define a common “POSIX” (or something like that) module which would have shared unix level interfaces that would portable to all platforms. Then corelibs-foundation could re-export THAT module, providing a common set of APIs on all platforms. A POSIX module would also eliminate the annoying #import glibc/darwin #ifdef dance in many cases.

-Chris

- Tony

On Jan 14, 2016, at 9:04 AM, Philippe Hausler via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:

The reason is that Foundation on darwin re-exports modules below it (by the virtue of objective-c headers) and the linux version is not re-exporting Glibc.

On Jan 14, 2016, at 8:44 AM, Drew Crawford via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:

on Darwin, we can say:

import Foundation
exit(2)

I'm not totally sure how this works, since exit is provided by Darwin, not by Foundation. But somehow importing Foundation imports Darwin as well.

I think for source compatibility, we should support this, because people <http://stackoverflow.com/questions/34186994/swift-2-2-on-linux-use-of-unresolved-identifier-exit> are asking <http://stackoverflow.com/questions/24102157/seeking-an-exit-equivalent-in-swift> why it doesn't work out of the box.

I considered PRing an exit implementation in corelibs-foundation, but I think that might cause the opposite problem–introduce a conflict between Darwin/Glibc exit and Foundation "exit".

Can someone speak to how this is solved in Darwin Foundation and what we should do about it?

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev


(Chris Lattner) #8

So we should be using `@exported import Glibc` on linux and `@exported import Darwin` on darwin then?

Yep.

Does this need to be for every import of Glibc? or just one somewhere in the swift files?

Just do this in the same places it is happening for Darwin.

-Chris

···

On Jan 17, 2016, at 10:14 AM, Philippe Hausler <phausler@apple.com> wrote:


(Philippe Hausler) #9

So I tried it out and it looks to be spot on exactly what we want. But the grammar is `@_exported` is this kosher for Foundation to use?

···

On Jan 17, 2016, at 10:40 AM, Chris Lattner <clattner@apple.com> wrote:

On Jan 17, 2016, at 10:14 AM, Philippe Hausler <phausler@apple.com> wrote:

So we should be using `@exported import Glibc` on linux and `@exported import Darwin` on darwin then?

Yep.

Does this need to be for every import of Glibc? or just one somewhere in the swift files?

Just do this in the same places it is happening for Darwin.

-Chris


(Chris Lattner) #10

So I tried it out and it looks to be spot on exactly what we want. But the grammar is `@_exported` is this kosher for Foundation to use?

It isn’t ideal, since it is effectively a compiler-private implementation API. However, you have no other option (and are already doing it for Darwin) so I think it is the best path.

-Chris

···

On Jan 17, 2016, at 1:29 PM, Philippe Hausler <phausler@apple.com> wrote:

On Jan 17, 2016, at 10:40 AM, Chris Lattner <clattner@apple.com> wrote:

On Jan 17, 2016, at 10:14 AM, Philippe Hausler <phausler@apple.com> wrote:

So we should be using `@exported import Glibc` on linux and `@exported import Darwin` on darwin then?

Yep.

Does this need to be for every import of Glibc? or just one somewhere in the swift files?

Just do this in the same places it is happening for Darwin.

-Chris