When reading the generic parameters of a constrained protocol
extension, cross-refencing an associated type would perform name
lookup into the protocol extension itself, causing fatal recursion
during deserialization. Fixed by avoiding additional deserialization
when looking for an associated type. Fixes rdar://problem/20812303.
Swift SVN r28228
Within the where clause of a constrained (protocol) extension, allow
us to find associated types of that protocol and anything it inherits
via unqualified lookup, e.g.,
extension SequenceType where Generator.Element : Equatable { }
rather than
extension SequenceType where Self.Generator.Element : Equatable { }
Implements rdar://problem/20722467.
Swift SVN r28208
Currently GenericSignature::getCanonicalSignature isn't able to canonicalize the set of requirements due to fragile dependencies on generic signatures matching AllArchetypes order of their originating GenericParamLists. However, we shouldn't let that stop us from getting the mangling right, so implement a "getCanonicalManglingSignature" that builds the true canonical signature by feeding it into an ArchetypeBuilder and shedding unnecessary constraints. For now, just handle conformance and base class constraints; still to do are same-type constraints.
Swift SVN r28191
There was a fair amount of code duplication in handling the various
places where @objc could either be explictly specified or be inferred;
centralize these in a new shouldMarkAsObjC() function. NFC
Swift SVN r28125
When deserializing a protocol, the conformance lookup table would not
contain entries for the inherited protocols of that protocol. They
were stashed in the "Protocols" array in TypeDecl (which will
eventually go away), but since there are no conformances for a
protocol, the conformance lookup table never got updated.
Nothing important seems to query this now; that will change soon.
Swift SVN r27967
Extensions cannot be uniquely cross-referenced, so cross-references to
extensions are serialized with the extended nominal type name and the
module in which the extension resides. This is not sufficient when
cross-referencing the generic type parameters of a constrained
protocol extension, because we don't know whether to get the
archetypes of the nominal type or some extension thereof. Serialize
the canonical generic signature so that we can pick an extension with
the same generic signature; it doesn't matter which we pick, so long
as we're consistent.
Fixes rdar://problem/20680169. Triggering this involves some
interesting interactions between the optimizer and standard library;
the standard library updates in the radar will test this.
Swift SVN r27825
- <rdar://problem/16306600> QoI: passing a 'let' value as an inout results in an unfriendly diagnostic
- <rdar://problem/16927246> provide a fixit to change "let" to "var" if needing to mutate a variable
We now refer to an inout argument as such, e.g.:
t.swift:7:9: error: cannot pass 'let' value 'a' as inout argument
swap(&a, &b)
^
we also produce a note with a fixit to rewrite let->var in trivial cases where mutation is
being assed for, e.g.:
t.swift:3:3: note: change 'let' to 'var' to make it mutable
let a = 42
^~~
var
The note is produced by both Sema and DI.
Swift SVN r27774
the printed interface.
Previously we printed the typechecked and uniqued requirements and the result was non-sensical.
Long-term the requirements will be preserved in a better form but for now print the requirements
and serialize them.
rdar://19963093
Swift SVN r27680
Add syntax "[#Color(...)#]" for object literals, to be used by
Playgrounds for inline color wells etc. The arguments are forwarded to
the relevant constructor (although we will probably change this soon,
since (colorLiteralRed:... blue:... green:... alpha) is kind of
verbose). Add _ColorLiteralConvertible and _ImageLiteralConvertible
protocols, and link them to the new expressions in the type checker.
CSApply replaces the object literal expressions with a call to the
appropriate protocol witness.
Swift SVN r27479
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
Refactor the Objective-C selector computation code for all forms of
methods, collapsing it into a single routine to eliminate
duplication. Test that we're computing Objective-C selectors for
throwing initializers correctly, as well as that we're printing the
appropriate Objective-C method declarations for throwing
initializers.
Swift SVN r27293
Introduce basic validation for throwing @objc initializers, e.g., a
failable @objc initializer cannot also be throwing. However,
Objective-C selector computation is broken.
Swift SVN r27292
FuncDecl::throws() is misleading because it only tells us whether the
'throws' keyword was present on the declaration. Since source
locations are lost during deserialization, it would give the wrong
result. Nobody was making this mistake now, but it's better not to
leave this trap in the ASTs.
Use AbstractFuncitonDecl::isBodyThrowing() to determine whether a
particular function (or initializer, eventually) can throw.
Swift SVN r27257
and refutable pattern bindings without an initializer.
- Enhance ASTDumper to dump where/else clauses on PBDs.
- Merge if/let conditional PBD logic into the mainline logic now that they are all
potentially conditional (more simplifications coming for this)
add tests for the fixits, which exercise the earlier SourceRange enhancments, e.g.:
x.swift:3:5: error: refutable pattern match can fail; add an else {} to handle this condition
let o? = a
^~
else {}
Swift SVN r26751
Add an isRefutable() predicate to a PBD overall, which is true
iff the PBD has any refutable patterns in it or has a where clause.
NFC, not used yet.
Swift SVN r26708
- Enhance PBD with a whereExpr/elseStmt field to hold this.
- Start parsing the pattern of let/var decls as a potentially refutable pattern. It becomes
a semantic error to use a refutable pattern without an 'else' (diagnostics not in place yet).
- Change validatePatternBindingDecl to use 'defer' instead of a goto to ensure cleanups on exit.
- Have it resolve the pattern in a PBD, rewriting it from expressions into pattern nodes when valid.
- Teach resolvePattern to handle TypedPatterns now that they can appear (wrapping) refutable patterns.
- Teach resolvePattern to handle refutable patterns in PBD's without initializers by emitting a diagnostic
instead of by barfing, fixing regressions on validation tests my previous patch caused, and fixing
two existing validation test crashers.
Sema, silgen, and more tests coming later.
Swift SVN r26706
Start parsing a "trailing" where clause for extension declarations, which follows the extended type name and (optional) inheritance clause. Such a where clause is only currently permitted for protocol extensions right now.
When used on a protocol extension, it allows one to create a more-constrained protocol extension, e.g.,
extension CollectionType where Self.Generator.Element : Equatable { ... }
which appears to be working, at least in the obvious cases I've tried.
More cleanup, tests, and penance for the previous commit's "--crash" introductions still to come.
Swift SVN r26689
Remove the semantic restrictions that prohibited extensions of
protocol types, and start making some systematic changes so that
protocol extensions start to make sense:
- Replace a lot of occurrences of isa<ProtocolDecl> and
dyn_cast<ProtocolDecl> on DeclContexts to use the new
DeclContext::isProtocolOrProtocolExtensionContext(), where we want
that behavior to apply equally to protocols and protocol extensions.
- Eliminate ProtocolDecl::getSelf() in favor of
DeclContext::getProtocolSelf(), which produces the appropriate
generic type parameter for the 'Self' of a protocol or protocol
extension. Update all of the callers of ProtocolDecl::getSelf()
appropriately.
- Update extension validation to appropriately form generic
parameter lists for protocol extensions.
- Methods in protocol extensions always use the witnesscc calling
convention.
At this point, we can type check and SILGen very basic definitions of
protocol extensions with methods that can call protocol requirements,
generic free functions, and other methods within the same protocol
extension.
Regresses four compiler crashers but improves three compiler
crashers... we'll call that "progress"; the four regressions all hit
the same assertion in the constraint system that will likely be
addressed as protocol extensions starts working.
Swift SVN r26579
Rename 'assignment' attribute of infix operators to 'mutating'. Add
'has_assignment' attribute, which results in an implicit declaration of
the assignment version of the same operator. Parse "func =foo"
declaration and "foo.=bar" expression. Validate some basic properties of
in-place methods.
Not yet implemented: automatic generation of wrapper for =foo() if foo()
is implemented, or vice versa; likewise for operators.
Swift SVN r26508
SIL seems to be doing the right thing here already, which is great!
Part of rdar://problem/17732115. We'll be able to really see this working
with the next change: allowing references to testable things when using
"@testable import".
Swift SVN r26473
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
Getting the protocols of an arbitrary type doesn't make sense, so start phasing this out by introducing specialized entry points that do make sense:
- get the inherited protocols of a ProtocolDecl
- get the conforming protocols for an associated type or generic
type parameter
- (already present) ask for the protocols to which a nominal type conforms
Swift SVN r26411
The commit fixes availability Fix-Its on enum elements to suggest a new availability
attribute on the enum case (which is where attributes live in concrete syntax) rather than
on the enum element (which is where they are attached in the abstract syntax tree).
Swift SVN r26401
We explicitly whitelist these "stdlib private" decls in interface
generation, because they may contain methods that users are required to
implement. But in code-completion, there's no good reason to show them.
We still show completions for the methods themselves if you complete on
a public protocol that inherits from the private protocol. So,
<complete> => doesn't show _CollectionType
let a: CollectionType = ...
a.<complete> => *does* show startIndex, which comes from _CollectionType
rdar://problem/20086106
Swift SVN r26355
We now access the conformances of a nominal type through the
conformance lookup table, so there is no reason to continue storing
conformances directly on the nominal type declaration, which was
error-prone regardless. This mirrors the change to ExtensionDecl from
my previous commit.
Swift SVN r26354
Stop storing a conformances array on ExtensionDecls. Instead, always use the conformance lookup table to retrieve conformances (which is lazy and supports multi-file, among other benefits).
As part of this, space-optimize ExtensionDecl's handling of conformance loaders. When one registers a conformance loader, it goes into a DenseMap on ASTContext and gets erased once we've loaded that data, so we get two words worth of space back in each ExtensionDecl.
Swift SVN r26353
