Skip to content

Conversation

MaxDesiatov
Copy link

No description provided.

compnerd and others added 20 commits August 20, 2020 13:48
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]
@MaxDesiatov MaxDesiatov added ⤵️ Upstream Tracking release Issues with the release version labels Aug 28, 2020
@MaxDesiatov MaxDesiatov marked this pull request as ready for review August 28, 2020 14:32
@MaxDesiatov MaxDesiatov merged commit 4fe9b11 into swiftwasm-release/5.3 Aug 28, 2020
@MaxDesiatov MaxDesiatov deleted the maxd/5.3-merge branch August 28, 2020 14:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
⤵️ Upstream Tracking release Issues with the release version
Projects
None yet
Development

Successfully merging this pull request may close these issues.