forked from swiftlang/swift
-
Notifications
You must be signed in to change notification settings - Fork 30
Fix build issues in the 5.3 branch #1635
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
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The order of attribution was swapped which failed on platforms which use `comdat` (i.e. Windows).
Codable's magic previously relied on the subject of every qualified lookup in an unqualified lookup stack to force the synthesis of this member. This allowed users to reference CodingKeys transitively through a non-primary input without qualification. As part of the requestification of name lookup, this synthesis was moved out of the normal qualified lookup path and into the Type Checker's semantic lookup entrypoints in order to prevent wild cycles caused by protocol conformance resolution. In the process, we forget to restore the synthesis check at this entrypoint. To patch up the source break this caused, we need to walk the context stack again and force synthesis. Unfortunately, we're stuck with a hack like this until we bring Codable's implementation back out of the realm of magic once more. A future implementation of synthesizeSemanticMembersIfNeeded should aim to just craft the AST for CodingKeys, but not actually run any of the semantic checks until we check the conformance to CodingKey. rdar://65088901, SR-13137
Don't tempt llvm to misbehave on partially initialized bytes -- it will. Explanation: Before this patch we would store integer types of non integral byte widths (e.g i1) with llvm store instructions of the same type. The semantics of a load of a differently sized store for such non-integral sized byte widths is undefined in LLVM. And indeed LLVM ends up misoptimizing code involving a combination of a full byte store and a partial bit store, such as the attached test case. Scope: This changes how we store non integral byte sized integer values. Risk: Low, instead of storing an i1 we store a i8 which in hardware is the same byte store. Testing: Regression test added Reviewed by: Joe Groff rdar://67408302
Using a SetVector fixes an issue where many source files imported the same SPI group from the same module, the emitted private textual interfaces superfluously repeated the `@_spi` attribute on the import. rdar://problem/63681845
…ted types Extensions to implementation-only types are accepted at type-checking only if they don't define any public members. However if they declared a conformance to a public type they were also printed in the swiftinterface, making it unparsable because of an unknown type. Still accept such extensions but don't print them. rdar://problem/67516588
Additional restriction to keep printing some extensions to implementation-only imported types. This will be accepted only if the extension is marked SPI.
…ytes_5.3 [5.3] IRGen: Store scalars as bytes to avoid undefined bits
Function builder bodies are applied in several stages. First of them is `pre-check` stage which is, among other things, responsible for member lookup and reference resolution, if that action fails it would be diagnosed inline and affected expression is going to be replaced with `ErrorExpr`. This works fine in context of regular expressions but not function builders, because matching of function builder bodies happens in the middle of type-checking of enclosing context, so solver needs to implement graceful handling of such problems and delay diagnostics until solver reaches a solution. To accommodate that `PreCheckFunctionBuilderRequest`, `ConstraintSystem::preCheckExpression`, and `TypeChecker::resolveDeclRefExpr` have been adjusted to know explicitly whether diagnosing and AST mutation is permitted. Solver is adjusted to ignore closure bodies which fail pre-check in their entirety. Resolves: rdar://problem/65320500
…ns-5.3 [5.3][ModuleInterface] Don't print extensions to implementation-only imported types
…-castle [5.3] Patch A Regression in Lookup for CodingKeys
[5.3][FunctionBuilders] Implement graceful handling of pre-check failures
…uest AbstractGenericSignatureRequest tries to minimize the number of GSBs that we spin up by only creating a GSB if the generic parameter and requirement types are canonical. If they're not canonical, it first canonicalizes them, then kicks off a request to compute the canonical signature, and finally, re-applies type sugar. We would do this by building a mapping for re-sugaring generic parameters, however this mapping was only populated for the newly-added generic parameters. If some of the newly-added generic requirements mention the base signature's generic parameters, they would remain canonicalized. Fixes <rdar://problem/67579220>.
test: repair Serialization.autolinking after swiftlang#33379
…ot a PatternBindingInitializer The function builder transform creates pattern bindings parented in other DeclContexts. If those pattern binding initializer expressions in turn contain multi-statement closures, we will try to perform unqualified lookups from those contexts when we get around to type checking the closure body. Change some unconditional casts to conditional casts in ASTScope lookup, to handle this case. The casts are only performed while checking if the initializer context is part of a 'lazy' property, which doesn't apply here. Fixes <rdar://problem/67265731>.
This was not needed. The list of depenencies should not be changed during fast-completion sessions. This was also harmful because it calls stat(2) for all the dependency files. rdar://problem/67773257 (cherry picked from commit bf5fb4d)
…ith-pattern-binding-init-function-builder-5.3 AST: Fix ASTScopeLookup crash if a PatternBindingEntry's context is not a PatternBindingInitializer [5.3]
…ar67773257 [5.3][CodeCompletion] Don't update VFS content hash map after each completion
…rements-in-inherited-inits-5.3 AST: Try harder to preserve type sugar in AbstractGenericSignatureRequest [5.3]
kateinoigakukun
approved these changes
Aug 28, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.