Skip to content
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-4266] Compatibility header emits unknown type NSKeyValueChangeKey #4635

Closed
swift-ci opened this issue Mar 16, 2017 · 5 comments
Closed

Comments

@swift-ci
Copy link

Previous ID SR-4266
Radar None
Original Reporter marc (JIRA User)
Type Bug
Status Closed
Resolution Cannot Reproduce
Environment

Xcode 8.3 beta 4

Additional Detail from JIRA
Votes 0
Component/s Compiler, LLDB for Swift
Labels Bug, PrintAsObjC
Assignee None
Priority Medium

md5: 6f7db3986ec1263911c5ab3f911168b5

Issue Description:

Sometimes I cannot print anything in LLDB because a generated compatibility header doesn't compile:

error: in auto-import:
failed to get module 'Test' from AST context:
<module-includes>:2:9: note: in file included from <module-includes>:2:
#import "Headers/JetPack-Swift.h"
        ^

error: /…/JetPack/JetPack.framework/Headers/JetPack-Swift.h:855:113: error: no type or protocol named 'NSKeyValueChangeKey'
- (void)observeValueForKeyPath:(NSString * _Nullable)keyPath ofObject:(id _Nullable)object change:(NSDictionary<NSKeyValueChangeKey, id> * _Nullable)change context:(void * _Nullable)context;
                                                                                                                ^

error: could not build Objective-C module 'JetPack'

I guess NSKeyValueChangeKey should be replaced with String when emitting the header?!

How can we work around this? Can I somehow prevent types or functions from appearing in the compatibility header even if they're @objc?

@belkadan
Copy link

Hm. NSKeyValueChangeKey is a perfectly good typedef in Foundation, which should certainly be imported by the generated header. Are you using LLDB from the command line, or within Xcode? Do you have any custom build settings? Can you attach a project that reproduces this behavior?

@swift-ci
Copy link
Author

Comment by Marc Knaup (JIRA)

Nevermind, now the LLDB RPC crashed when printing that variable in the debugger so I've deleted DerivedData. Everything is back to normal again and this issue doesn't occur anymore…

We have multiple issues with LLDB, auto completion and syntax highlighting. If you have any tips on how we can better isolate and report such issues we would love to hear them!
It's so frustrating that in most cases there aren't any error messages or log files.

@belkadan
Copy link

Some things that would help us:

- There should be crash logs for both SourceKit and LLDB (as lldb-rpc-server), which you can find in the Console. These are only minimally useful because they don't include how the crash happened, but they're better than nothing.

- When completion or syntax highlighting goes out, immediately trying to compile will let you (and us) know if it's actually a compiler bug. (And then you get a better crash log, with the info at the bottom that says what it was trying to do at the time.)

- LLDB does have logging modes that dump a massive amount of information. I'm not an LLDB dev, but they'd probably ask you to use the "types" log, which you can turn on by running "log enable lldb types". If LLDB fails even before your process starts, you can put that line (sans quotes) in a file ".lldbinit-Xcode" in your home directory, and then it'll get run as soon as LLDB attaches to your process.

@swift-ci
Copy link
Author

Comment by Marc Knaup (JIRA)

Great tips, thank you!
We keep two eyes open for bugs and will try to catch ’em all 🙂

@swift-ci
Copy link
Author

Comment by Marc Knaup (JIRA)

I'll re-open this issue should it occur more often.
The single occasion was fixed by a deletion of DerivedData, i.e. a full rebuild.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@shahmishal shahmishal transferred this issue from apple/swift May 7, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants