-
Notifications
You must be signed in to change notification settings - Fork 10.5k
ClangImporter: Build type-checked AST for constants #25009
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
ClangImporter: Build type-checked AST for constants #25009
Conversation
@swift-ci Please test |
@swift-ci Please test source compatibility |
@swift-ci Please test compiler performance |
Build failed |
These will be used shortly to avoid name lookups into the imported type.
This allows Sema to skip checking external definitions altogether.
fc30048
to
8075b09
Compare
@swift-ci Please test source compatibility |
@swift-ci Please test |
Build failed |
Build failed |
@swift-ci Please test source compatibility |
What's the motivation here? Just to speed up build times? It seems unfortunate that we're increasing the duplication of information across Sema and ClangImporter. Are there higher-level operations that can be factored out that'd we'd also use for synthesized code in Sema? |
@jrose-apple I wrote up a blurb here: #24665 Basically we want to be able to synthesize declarations at any time, instead of everything happening before the magic point where Sema walks an 'external declarations' list. Doing this for accessors was a requirement for lazily checking conformances from SILGen instead of relying on Sema 'guessing' and populating a UsedConformances list. I did it for literals for completeness for performance and because I want to remove ExternalDeclarations. I agree there's a bit more duplication but we can factor it out, and also in this specific case of literal constants its a lot easier now that we have LiteralExpr that is lowered directly by SILGen, rather than Sema using callWitness() to build calls to the literal protocols. |
I see the point, but this is definitely harder to maintain, and more likely to become incorrect if we change how the AST works again. That's why we moved away from type-checked ASTs in the first place. |
…an alias This comes up when an imported error enum has duplicate cases. The FooError.Code enum has an alias for the duplicate case, and the wrapper type FooError defines aliases for every member of FooError.Code. The implementation of importEnumCaseAlias() assumed that 'original' was an EnumElementDecl, and built AST accordingly; however if it is a 'VarDecl', we have to build a MemberRefExpr instead. This regression was introduced in swiftlang#25009. Fixes <rdar://problem/58552618>.
…an alias This comes up when an imported error enum has duplicate cases. The FooError.Code enum has an alias for the duplicate case, and the wrapper type FooError defines aliases for every member of FooError.Code. The implementation of importEnumCaseAlias() assumed that 'original' was an EnumElementDecl, and built AST accordingly; however if it is a 'VarDecl', we have to build a MemberRefExpr instead. This regression was introduced in swiftlang#25009. Fixes <rdar://problem/58552618>.
Follow-up to #24797. Now everything on ExternalDeclarations is fully type checked, paving the way for removing that list altogether.