New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SR-14548] 5.4 Linux Toolchain no longer ignores @objc #56900
Comments
@swift-ci create |
Comment by Ken Carroll (JIRA) I don't see the relevance of the link. |
Varun created a Radar link for internal tracking. kencarroll (JIRA User) can you tell us more about the error that you're seeing with this code? If you can attach the full compiler output it would help us to start investigating. |
Comment by Ken Carroll (JIRA) @xymus Build output: ----- BEGIN swift build -v lsb_release -r ----- END swift build -v |
Comment by Ken Carroll (JIRA) Up to 5.4 @objc was ignored in Linux on enums and classes. A protocol had to be defined like this: #if os(Linux) public protocol P { func Q() } #else public protocol P #endif This requires duplication of the protocol. Painful, but with enums and classes it will become unbearable. I can have this: func R() But not this: #if !os(Linux) #endif public protocol P I can understand there is probably a good reason. And yet, preprocessor-like processing of the '#if', as in the given illegal example, would solve the problem I am facing (maintaining two copies of enums, classes and protocols). |
Comment by Ken Carroll (JIRA) Any update on this? |
Rejecting (@slavapestov, just in case I'm wrong that this behavior change was intentional.) Since we want the compiler to reject this code, I think we should close this bug report. |
Comment by Ken Carroll (JIRA) How can you have Swift code that works on MacOS and Linux then? The suggestion in your comments is that Swift code cannot target both Linux and mixed MacOS Swift/Objective-C projects. The idea of keeping a completely separate code base of the same identical code for different target platforms goes against all coding philosophies of the last 40 years. Is this progress? And ... the Swift project supports doing this for what, 8 years, before removing it? Am I the only one caught out by this? |
Comment by Ken Carroll (JIRA) Please advise on best method for maintaining cross-platform code. Thanks. Forget it. Just re-close the bug. I'll just work around it. Find another language probably. |
Comment by Ken Carroll (JIRA) Pointless pursuing this. |
Hi kencarroll (JIRA User), could you try using the |
Comment by Ken Carroll (JIRA) This was the first thing I tried. It appears that this is an 'unknown option' on Linux. |
Although in general, we do not support ObjC interop on Linux, for enums, there's no reason we should need to require ObjC interop support to support |
Comment by Ken Carroll (JIRA) For the record, I am not requesting Objc interoperability on Linux, I am just asking for the parser to continue to ignore @objc. Treat it as nul token. |
kencarroll (JIRA User) with my change @objc enums will work on Linux again. This is allowed because as Joe said they don't rely on bridging or the Objective-C runtime. However to the best of my knowledge, @objc protocols never worked on Linux and it was a mistake to allow them after importing corelibs-foundation. Method calls on @objc protocols always compiled down to objc_msgSend(). |
Comment by Ken Carroll (JIRA) @slavapestov This is correct. For protocols I have had to maintain separate Linux and MacOS definitions. For classes and enums, the @objc annotation would just be ignored on Linux. |
Comment by Ken Carroll (JIRA) Will this be fixed? Currently the only way I can move to Swift 4 is to write a pre-processor. I would really prefer not to have to do this. |
This should be fixed in Swift 5.5 (#37664 please verify with a Swift 5.5 Development snapshot from swift.org. |
Comment by Ken Carroll (JIRA) theindigamer (JIRA User) I have tested this with the snapshot build and it only addresses enums. Classes and protocols still fail. The link to the issue you sent is only concerned with enums. |
Comment by Ken Carroll (JIRA) @slavapestov What is the recommended way of supporting code that is intended to run on Linux and macOS (and be callable from Objective C but only on macOS)? Is there a reason that @objc cannot just be ignored on Linux? It could for example be discarded in the lexical phase as a null token. |
Comment by Ken Carroll (JIRA) Re-opening this bug because it only addresses enums. Please read the text of comments. Enums was just a part of the issue. It was only used for illustrative purposes. But classes are similarly affected. The code example has been expanded to demonstrate this. If the Linux swift compiler is to stay as is, what are the cross-platform support mechanisms for a 'code base'? Completely separate code repositories for Linux/macOS means that this is not a cross-platform language as advertised. Quite simply: If you have a class that is exported to Objective C on macOS, it cannot compile for Linux. |
Comment by Ken Carroll (JIRA) Any movement on this? Do I have to write a pre-processor? |
Comment by Ken Carroll (JIRA) Will fix with build process. |
The preprocessor idea is one option. Having the attribute be ignored on Linux for classes and protocols would require a Swift evolution proposal [earlier, they were ignored due to a bug, not intentionally]. You could submit a small evolution pitch for that. If that gets some momentum, you could submit a proposal with an implementation. Another option is a Swift evolution pitch for more flexible usage around attributes. In https://forums.swift.org/t/accepted-se-0308-postfix-if-config-expressions/47780, it says
|
Environment
Toolchain Ubuntu-18.04.
Additional Detail from JIRA
md5: 30e0bafaa0fe2efb3b254fa1b8f290b8
relates to:
Issue Description:
The following code fails to compile with 5.4 on Linux. It compiled with 5.3.3.
import Foundation
@objc enum XY: Int
{
case x = 1
case y = 0
}
@objc class XY
{
var text = "Hello World"
}
The text was updated successfully, but these errors were encountered: