a list of their elements, instead of abusing TupleExpr/ParenExpr
to hold them.
This is a more correct representation of what is going on in the
code and produces slightly better diagnostics in obscure cases.
However, the real reason to fix this is that the ParenExpr's that
were being formed were not being installed into the "semantic"
view of the collection expr, not getting type checked correctly,
and led to nonsensical ParenExprs. These non-sensical ParenExprs
blocked turning on AST verification of other ones.
With this fixed, we can finally add AST verification that
IdentityExpr's have sensible types.
Swift SVN r27850
This fixes <rdar://problem/20494437> SILGen crash handling default arguments
again, and includes a fix for MiscDiagnostics to look through the generated
TupleShuffleExprs in @noescape processing (which tripped up XCTest).
This fixes <rdar://problem/16860940> QoI: Strict keyword arguments loses type sugar in calls
where we'd lose some type sugar.
This fixes sanity in the ASTs: ScalarToTupleExpr now always has consistent
types between its argument and result, so we can turn on AST Verification of it.
Swift SVN r27827
Move the map that keeps track of conforming decl -> requirement from ASTContext
to a nominal type's ConformanceLookupTable, and populate it lazily.
This allows getSatisfiedProtocolRequirements() to work with declarations from module files.
Test on the SourceKit side.
Part of rdar://20526240.
Swift SVN r27353
Consistently open all references into existentials into
opened-existential archetypes within the constraint solver. Then,
during constraint application, use OpenExistentialExprs to record in
the AST where an existential is opened into an archetype, then use
that archetype throughout the subexpression. This simplifies the
overall representation, since we don't end up with a mix of operations
on existentials and operations on archetypes; it's all archetypes,
which tend to have better support down the line in SILGen already.
Start simplifying the code in SILGen by taking away the existential
paths that are no longer needed. I suspect there are more
simplifications to be had here.
The rules for placing OpenExistentialExprs are still a bit ad hoc;
this will get cleaned up later so that we can centralize that
information. Indeed, the one regression in the compiler-crasher suite
is because we're not closing out an open existential along an error
path.
Swift SVN r27230
Place OpenExistentialExprs for references to lvalue subscripts or properties
(in protocol extensions) via existentials just outside of the member
or subscript reference, rather than far outside the expression. This
gives us a tighter bound on the open-existential expressions without
introducing the post-pass I was threatening.
OpenExistentialExprs just outside of lvalue member/subscript are
themselves lvalues. Resurrect John's OpenOpaqueExistentialComponent to
handle the opening of a (materialized) existential lvalues as an
lvalue path component. This has the nice effect of codifying the
formal access rules for opened existentials as well as handling inout
on opened existentials appropriately.
Big thanks to John for talking through the model with me and leaving
dead code around for me to use.
Swift SVN r27105
Previously some parts of the compiler referred to them as "fields",
and most referred to them as "elements". Use the more generic 'elements'
nomenclature because that's what we refer to other things in the compiler
(e.g. the elements of a bracestmt).
At the same time, make the API better by providing "getElement" consistently
and using it, instead of getElements()[i].
NFC.
Swift SVN r26894
Currently a no-op, but effective access for entities within the current
module will soon need to take testability into account. This declaration:
internal func foo() {}
has a formal access of 'internal', but an effective access of 'public' if
we're in a testable mode.
Part of rdar://problem/17732115 (testability)
Swift SVN r26472
Allows us to distinguish between "we know this conformance exists" and
"we're doing a detailed check of this conformance". Use it, rather
than membership in the nebulous ASTContext-wide caching structure
"ConformsTo", to detect recursive attempts to complete a conformance.
Swift SVN r26248
Previously, a multi-pattern var/let decl like:
var x = 4, y = 17
would produce two pattern binding decls (one for x=4 one for y=17). This is convenient
in some ways, but is bad for source reproducibility from the ASTs (see, e.g. the improvements
in test/IDE/structure.swift and test/decl/inherit/initializer.swift).
The hardest part of this change was to get parseDeclVar to set up the AST in a way
compatible with our existing assumptions. I ended up with an approach that forms PBDs in
more erroneous cases than before. One downside of this is that we now produce a spurious
"type annotation missing in pattern"
diagnostic in some cases. I'll take care of that in a follow-on patch.
Swift SVN r26224
This changes 'if let' conditions to take general refutable patterns, instead of
taking a irrefutable pattern and implicitly matching against an optional.
Where before you might have written:
if let x = foo() {
you now need to write:
if let x? = foo() {
The upshot of this is that you can write anything in an 'if let' that you can
write in a 'case let' in a switch statement, which is pretty general.
To aid with migration, this special cases certain really common patterns like
the above (and any other irrefutable cases, like "if let (a,b) = foo()", and
tells you where to insert the ?. It also special cases type annotations like
"if let x : AnyObject = " since they are no longer allowed.
For transitional purposes, I have intentionally downgraded the most common
diagnostic into a warning instead of an error. This means that you'll get:
t.swift:26:10: warning: condition requires a refutable pattern match; did you mean to match an optional?
if let a = f() {
^
?
I think this is important to stage in, because this is a pretty significant
source breaking change and not everyone internally may want to deal with it
at the same time. I filed 20166013 to remember to upgrade this to an error.
In addition to being a nice user feature, this is a nice cleanup of the guts
of the compiler, since it eliminates the "isConditional()" bit from
PatternBindingDecl, along with the special case logic in the compiler to handle
it (which variously added and removed Optional around these things).
Swift SVN r26150
When we check a protocol conformance, we recurse to check the implied
protocol conformances for inherited protocols first. When doing so, we
were passing down the current DeclContext, which would force the
creation of a new conformance to that protocol within that
DeclContext. This isn't what we want: we want to find or create the
conformance in whichever context it naturally belongs.
This is a partial step toward solving the problem, which eliminates
the duplicate witness tables from the example in
rdar://problem/18182969. However, we're still not using the
conformance lookup table to decide where the witness tables/protocol
conformances go, which means the actual declaration context for a
witness table is still a bit ad hoc.
Baby steps.
Swift SVN r26129
Brace statement created for wrapping IfConfig inside TopLevelCodeDecl does not have
closing brace, so we should use the previous token’s location as right brace location.
Swift SVN r24797
Local type declarations are saved in the source file during parsing,
now serialized as decls. Some of these may be defined in DeclContexts
which aren't Decls and previously weren't serialized. Create four new
record kinds:
* PatternBindingInitializer
* DefaultArgumentInitializer
* AbstractClosureExpr
* TopLevelCodeDecl
These new records are used to only preserve enough information for
remangling in the debugger, and parental context relationships.
Finally, provide a lookup API in the module to search by mangled name.
With the new remangling API, the debugging lifecycle for local types
should be complete.
The extra LOCAL_CONTEXT record will compressed back down in a
subsequent patch.
Swift SVN r24739
with more explicit/semantic conversions in and out.
Using a PointerUnion with overlapping pointer types
is both error-prone and pretty close to illegible.
Swift SVN r24707
Curried function parameters (i.e., those past the first written
parameter list) default to having argument labels (which they always
have), but any attempt to change or remove the argument labels would
fail. Use the fact that we keep both the argument labels and the
parameter names in patterns to generalize our handling of argument
labels to address this problem.
The IDE changes are due to some positive fallout from this change: we
were using the body parameters as labels in code completions for
subscript operations, which was annoying and wrong.
Fixes rdar://problem/17237268.
Swift SVN r24525
When dealing with multiple levels of generic parameters, the mapping
from potential archetypes down to actual archetypes did not have
access to the archetypes for outer generic parameters. When same-type
requirements equated a type from the inner generic parameter list with
one from the outer generic parameter list, the reference to the outer
generic parameter list's type would remain dependent. For example,
given:
struct S<A: P> {
init<Q: P where Q.T == A>(_ q: Q) {}
}
we would end up with the dependent type for A (τ_0_0) in the same-type
constraint in the initializer requirement.
Now, notify the ArchetypeBuilder of outer generic signatures (and,
therefore, outer generic parameters), so that it has knowledge of the
mapping from those generic parameters to the corresponding
archetypes. Use that mapping when translating potential archetypes to
real archetypes. Additionally, when a potential archetype is mapped to
a concrete type (via a same-type constraint to a concrete type),
substitute archetypes for any dependent types within the concrete
type.
Remove a bunch of hacks in the compiler that identified dependent
types in "strange" places and tried to map them back to
archetypes. Those hacks handled some narrow cases we saw in the
standard library and some external code, but papered over the
underlying issue and left major gaps.
Sadly, introduce one hack into the type checker to help with the
matching of generic witnesses to generic requirements that follow the
pattern described above. See ConstraintSystem::SelfTypeVar; the proper
implementation for this matching involves substituting the adoptee
type in for Self within the requirement, and synthesizing new
archetypes from the result.
Fixes rdar://18435371, rdar://18803556, rdar://19082500,
rdar://19245317, rdar://19371678 and a half dozen compiler crashers
from the crash suite. There are a few other radars that I suspect this
fixes, but which require more steps to reproduce.
Swift SVN r24460
Changing the design of this to maintain more local context
information and changing the lookup API.
This reverts commit 4f2ff1819064dc61c20e31c7c308ae6b3e6615d0.
Swift SVN r24432
rdar://problem/18295292
Locally scoped type declarations were previously not serialized into the
module, which meant that the debugger couldn't reason about the
structure of instances of those types.
Introduce a new mangling for local types:
[file basename MD5][counter][identifier]
This allows the demangle node's data to be used directly for lookup
without having to backtrack in the debugger.
Local decls are now serialized into a LOCAL_TYPE_DECLS table in the
module, which acts as the backing hash table for looking up
[file basename MD5][counter][identifier] -> DeclID mappings.
New tests:
* swift-ide-test mode for testing the demangle/lookup/mangle lifecycle
of a module that contains local decls
* mangling
* module merging with local decls
Swift SVN r24426
Change all the existing addressors to the unsafe variant.
Update the addressor mangling to include the variant.
The addressor and mutable-addressor may be any of the
variants, independent of the choice for the other.
SILGen and code synthesis for the new variants is still
untested.
Swift SVN r24387
if-let statements (also while and var, of course) that include multiple bindings
and where clauses.
SILGen support still remains, it currently just asserts on the new constructs.
Swift SVN r24239
optional callback; retrofit existing implementations.
There's a lot of unpleasant traffic in raw pointers here
which I'm going to try to clean up.
Swift SVN r24123
We know we get the archetypes wrong here. Doug is working on fixing this
for the next release, but until then we shouldn't attempt to enforce it
in the verifier.
rdar://problem/18423171
Swift SVN r22249
In particular, observing overrides of Objective-C properties in extensions
were getting non-dynamic accessors synthesized.
rdar://problem/18213447
Swift SVN r22107
The changes to the decl/ext/generic test strip out testing of
extensions of nested generics, a feature whose syntax will change and
is fairly broken already.
Swift SVN r21750
when type checking a reference to an optional requirement (producing
a dynamic_member_ref), downcast the receiver to the protocol in question
instead of to AnyObject. At SILGen time, we do an unchecked_ref_cast anyway,
and this is a more general solution to the problem it is trying to solve.
Swift SVN r21515
Previously, we were just storing setter accessibility via the accessibility
level on the setter function. However, some Stored properties never actually
have a setter synthesized, which led to the compiler dropping the setter
accessibility at serialization time. Rather than try to hack up something
clever, just store the setter accessibility explicitly in every
AbstractStorageDecl. (We still only serialize it for VarDecls, because
settable SubscriptDecls always have setter functions.)
<rdar://problem/17816530>
Swift SVN r20598
