Change availability Fix-It notes to use a DescriptiveDeclKind so that the notes are
more precise in their description of where an availability attribute will be added.
So, for example, the note will now say "add @availability attribute to enclosing class"
instead of "add @availability attribute to enclosing type".
In these Fix-Its, I have special-cased the descriptive kind for PatternBindingDecls to
instead use the description for an associated VarDecl to avoid describing property
declarations as "pattern bindings" to the user.
Swift SVN r26420
This warning is temporarily going being a flag so that, once it is safe to place generic parameters on extensions of generic types, we can opt-in to update our code when it is convenient.
Swift SVN r26416
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 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
Minor tweaks to availability diagnostic text based on feedback from Chris, Ted, and Doug.
This changees "'foo' is only available on OS X version 10.10 or greater" to
"'foo' is only available on OS X 10.10 or newer".
This change also updates the deprecation and obsoleted diagnostics to be consistent with
the new text.
Swift SVN r26344
This simplifies and isolates the "deep conformance checking" behavior
of LazyResolver::checkConformance (renamed from
LazyResolver::resolveConformance). We actually don't want to be
triggering this from lookup, because it's exceedingly non-lazy, but
our lazy resolution of witnesses isn't good enough to support that
just yet. NFC
Swift SVN r26319
Replace the loop over all known protocols with a query into the
actual conformance lookup table, which more properly deals with
out-of-order conformance queries, inheritance of protocol
conformances, and conformance queries in multi-file situtations.
The SILGen test change is because we're no longer emitting redundant
conformances, while the slight diagnostic regression in
circular-inheritance cases is because we handle circular inheritance
very poorly throughout the compiler.
While not the end, this is a major step toward finishing
rdar://problem/18448811.
Swift SVN r26299
This lets us tag imported declarations with arbitrary synthesized
protocols. Use it to handle imported raw option sets as well as the
RawRepresentable conformances of enums that come in as structs.
Swift SVN r26298
Fixes a crash when the user uses such a type. (Which is probably a
mistake--they probably meant to make the whole closure optional--but
that's another issue.)
rdar://problem/20163908
Swift SVN r26274
This commit suppresses errors for references to unavailable symbols inside
implicit functions.
This is a quick hack to fix a hit-listed radar <rdar://problem/20007266> where
the compiler was emitting spurious errors for enums explicitly marked
unavailable in Objective-C and whose nil literal conformance is synthesized by
the importer. These errors could occur when user code made no apparent reference
to the enum in question and instead only referred to an imported class that
itself referred to the enum in a method signature.
We will need to do something systematic about availability and deprecation
diagnostics in synthesized code. In particular, we should make sure that:
(1) we never emit code that references explicitly unavailable symbols;
(2) that the user never gets an error about symbol that they did not explicitly type; and
(3) that errors can dealt with via the appropriate availability check or annotation. I'm
tracking this with radar rdar://problem/20024980.
rdar://problem/20007266
Swift SVN r26251
Previously, we would require the type checker to be able to build a
conformance, which meant we would actually have to lie in the AST
about having a conformance (or crash; we did the form). Now, we can
form the conformance in the AST and it will be checked in the type
checker when needed. The intent here is to push conformance creation
into the conformance lookup table.
To get here, we had to stop relying on the broken, awful,
ASTContext-wide conformance "cache". A proper cache can come back once
the model is sorted out.
Swift SVN r26250
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
Both semantic analysis and the AST had logic to determine conformances for archetypes and existentials; the AST version of this logic was better and more centrally used, so kill the AST version.
Swift SVN r26227
Having semantic checking in type validation introduces the potential for more recursion, triggering crashes. By moving this semantic restriction out to a later stage, we make it more robust. Fixes 6 compiler crashers, although it regressed one compiler crasher that hits a different known issue (assertions in addGenericParameters when we have multiple parameters at the same depth).
Swift SVN r26226
Instead of relying on Sema to set the existential-conforms-to-self bit, compute it lazily in the AST. This is far cleaner and more dependable than the previous solution.
Swift SVN r26225
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
If the placeholder is a typed one, parse its type string into a TypeRepr,
resolve it during typechecking and set it as the type for the associated EditorPlaceholderExpr.
Swift SVN r26215
necessary. Wrap forced optional fixit in parens if necessary.
<rdar://problem/20029786> Swift compiler sometimes suggests changing "as!" to "as?!"
Swift SVN r26189
The deallocating parameter convention is a new convention put on a
non-trivial parameter if the caller function guarantees to the callee
that the parameter has the deallocating bit set in its object header.
This means that retains and releases do not need to be emitted on these
parameters even though they are non-trivial. This helps to solve a bug
in +0 self and makes it trivial for the optimizer to perform
optimizations based on this property.
It is not emitted yet by SILGen and will only be put on the self
argument of Deallocator functions.
Swift SVN r26179
- Rename getParentPattern() -> getParentPatternBinding(), since
it returns the pattern binding, not the pattern.
- Introduce new getParentPattern()/getParentInitializer() methods,
covering the most common uses of getParentPatternBinding().
NFC.
Swift SVN r26175
This is still a subject of discussion on swift-dev, but it seems like clearly the right
way to go to me. If it turns out that this isn't a good direction, I'll revert this and
subsequent patches built on top of it.
Swift SVN r26168
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
conformsToProtocol() was doing a confusing double-duty of querying
whether a type conforms to a protocol and initiating a complete check
of the witnesses in a conformance. Split it out: conformsToProtocol()
handles the query, and resolveConformance() does the complete check of
a conformance.
This is still messier than the end result should be. More baby steps.
Swift SVN r26148
conjunction with .fixItInsert(). As such, introduce a helper named
.fixItInsertAfter() that does what we all want. Adopt this in various
places around the compiler. NFC.
Swift SVN r26147
It causes some fails in compiler_crashers:
Swift :: compiler_crashers/0986-swift-unboundgenerictype-get.swift
Swift :: compiler_crashers/1103-swift-unboundgenerictype-get.swift
Swift :: compiler_crashers/1223-swift-lexer-leximpl.swift
Swift :: compiler_crashers/1276-swift-metatypetype-get.swift
Swift :: compiler_crashers/1287-swift-printingdiagnosticconsumer-handlediagnostic.swift
Swift SVN r26136
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
This is effectively NFC, but we had two implementations of "figure out
the protocols that this type should implicitly conform to". The one in
the conformance table is what will matter going forward.
Swift SVN r26115
warning, in the case of an AnyObject or AnyObject? type. Keep it around for ()
and AnyObject.Type.
The rationale for checking this has been reduced as the SDK is getting audited and
improved with generics, and it is problematic in the face of pattern matching, where
there isn't a simple pattern for silencing it.
Swift SVN r26105
This location is used when deciding whether a capture has already been
initialized, and without it the compiler decides that the reference to
a name from the capture list should be rejected.
rdar://problem/19776255&20153574
Swift SVN r26103
For now, we assume that 'while' after the braces starts
a do/while rather than being an independent statement.
We should disambiguate this, or better, remove do/while.
Tests later.
Swift SVN r26079
We now suggest up to three Fix-Its for each reference to a potentially
unavailable symbol: one to wrap the reference in an if #os(...) { ... }
guard (if possible), one to add an @availability attribute to an enclosing
property or method (if possible), and one to add an @availability attribute
to an enclosing class/struct/extension, etc. or global function.
The goal here is not to infer the "best" Fix-It but rather to ensure
discoverability of #os() and @availability attributes. We want the user, when
faced with an availability diagnostic, to be aware of the tools in her toolbox
to deal with it.
This is still missing QoI improvements, including Fix-Its to update
existing @availability attributes and more precise wording in diagnostics
(e.g, "initializer" instead of function, "class" instead of "type"). These
improvements will come in later commits.
Swift SVN r26073
(Note that this registry isn't fully enabled yet; it's built so that
we can test it, but has not yet taken over the primary task of
managing conformances from the existing system).
The conformance registry tracks all of the protocols to which a
particular nominal type conforms, including those for which
conformance was explicitly specified, implied by other explicit
conformances, inherited from a superclass, or synthesized by the
implementation.
The conformance registry is a lazily-built data structure designed for
multi-file support (which has been a problematic area for protocol
conformances). It allows one to query for the conformances of a type
to a particular protocol, enumerate all protocols to which a type
conforms, and enumerate all of the conformances that are associated
with a particular declaration context (important to eliminate
duplicated witness tables).
The conformance registry diagnoses conflicts and ambiguities among
different conformances of the same type to the same protocol. There
are three common cases where we'll see a diagnostic:
1) Redundant explicit conformance of a type to a protocol:
protocol P { }
struct X : P { }
extension X : P { } // error: redundant explicit conformance
2) Explicit conformance to a protocol that collides with an inherited
conformance:
protocol P { }
class Super : P { }
class Sub : Super, P { } // error: redundant explicit conformance
3) Ambiguous placement of an implied conformance:
protocol P1 { }
protocol P2 : P1 { }
protocol P3 : P1 { }
struct Y { }
extension Y : P2 { }
extension Y : P3 { } // error: ambiguous implied conformance to 'P1'
This happens when two different explicit conformances (here, P2 and
P3) placed on different declarations (e.g., two extensions, or the
original definition and other extension) both imply the same
conformance (P1), and neither of the explicit conformances imply
each other. We require the user to explicitly specify the ambiguous
conformance to break the ambiguity and associate the witness table
with a specific context.
Swift SVN r26067
We parse 'try' as if it were a unary operator allowed on an
arbitrary element of an expr-sequence, but sequence-folding
constrains it to never appear on the RHS of most operators.
We do allow it on the RHS of an assignment or conditional
operator, but not if there's anything to the right which
was not parsed within the RHS.
We do this for assignments so that
var x = try whatever
and
x = try whatever
both work as you might expect.
We do this for conditionals because it feels natural to
allow 'try' in the center operand, and then disallowing it
in the right operand feels very strange.
In both case, this works largely because these operators are
assumed to be very low-precedence; there are no standard
operators which would parse outside the RHS. But if you
create one and use 'try' before it, we'll diagnose it.
Swift SVN r26052
???'s stacked on top of each other in patterns. This wraps up:
<rdar://problem/19382878> Introduce new x? pattern
please kick the tires and let me know if you see any problems.
Swift SVN r26002
