Adds an associatedtype keyword to the parser tokens, and accepts either
typealias or associatedtype to create an AssociatedTypeDecl, warning
that the former is deprecated. The ASTPrinter now emits associatedtype
for AssociatedTypeDecls.
Separated AssociatedType from TypeAlias as two different kinds of
CodeCompletionDeclKinds. This part probably doesn’t turn out to be
absolutely necessary currently, but it is nice cleanup from formerly
specifically glomming the two together.
And then many, many changes to tests. The actual new tests for the fixits
is at the end of Generics/associated_types.swift.
the code to be actually readable since it unnests it greatly), and call it
both before and after argument type validation. This allows us to capture
many more structural errors than before, leading to much better diagnostics
in a lot of cases. This also fixes the specific regressions introduced by
96a1e96.
This reflects the fact that the attribute's only for compiler-internal use, and isn't really equivalent to C's asm attribute, since it doesn't change the calling convention to be C-compatible.
where we type check the destination first, then apply its type to the source.
This allows us to get diagnostics for assignments that are as good as PBD
initializers and other cases.
Swift SVN r31404
- Produce more specific diagnostics relating to different kinds of invalid
- add a testcase, nfc
- Reimplement FailureDiagnosis::diagnoseGeneralMemberFailure in terms of
Not including r30787 means that we still generate bogus diagnostics like:
[1, 2, 3].doesntExist(0) // expected-error {{type 'Int2048' does not conform to protocol 'IntegerLiteralConvertible'}}
But it is an existing and separable problem from the issues addressed here.
Swift SVN r30819
r30787 causes our tests to time out; the other commits depend on r30787.
Revert "revert part of my previous patch."
Revert "Produce more specific diagnostics relating to different kinds of invalid"
Revert "add a testcase, nfc"
Revert "- Reimplement FailureDiagnosis::diagnoseGeneralMemberFailure in terms of"
Revert "Fix places in the constraint solver where it would give up once a single "
Swift SVN r30805
member references:
- Use of instance members from types
- Use of type members from instances
- Use of mutating getters.
This surely resolves some radars, but I'll have to dig them out later.
Swift SVN r30796
"unavoidable failure" path, along with Failure::DoesNotHaveNonMutatingMember and
just doing some basic disambiguation in CSDiags.
This provides some benefits:
- Allows us to plug in much more specific diagnostics for the existing "only has
mutating members" diagnostic, including producing notes for why the base expr
isn't mutable (see e.g. test/Sema/immutability.swift diffs).
- Corrects issues where we'd drop full decl name info for selector references.
- Wordsmiths diagnostics to not complain about "values of type Foo.Type" instead
complaining about "type Foo"
- Where before we would diagnose all failures with "has no member named", we now
distinguish between when there is no member, and when you can't use it. When you
can't use it, you get a vauge "cannot use it" diagnostic, but...
- This provides an infrastructure for diagnosing other kinds of problems (e.g.
trying to use a private member or a static member from an instance).
- Improves a number of cases where failed type member constraints would produce uglier
diagnostics than a different constraint failure would.
- Resolves a number of rdars, e.g. (and probably others):
<rdar://problem/20294245> QoI: Error message mentions value rather than key for subscript
Swift SVN r30715
get the same wording, fixing <rdar://problem/21964599> Different diagnostics for the same issue
While I'm in the area, remove some dead code.
Swift SVN r30713
version of the new CTP_ReturnStmt conversion, used to generate return-specific
diagnostics. Now that we have a general solution, we can just use that.
This improves diagnostics in returns for accessors, since they were apparently
not getting the bit set.
Swift SVN r30665
we can start taking advantage of ambiguously typed subexpressions in CSDiags. We
start by validating the callee function of ApplyExprs, which substantially improves
our abilities to generate precise diagnostics about malformed calls.
This is the minimal introduction of this concept to CSDiags, a lot of refactoring
is yet to come, however, this is enough to resolve:
<rdar://problem/21080030> Bad diagnostic for invalid method call in boolean expression
<rdar://problem/21784170> Incongruous `unexpected trailing closure` error in `init` function which is cast and called without trailing closure.
one of the testcases from:
<rdar://problem/20789423> Unclear diagnostic for multi-statement closure with no return type
and a bunch of other places where we got weird "unexpected trailing closure"
diagnostics that made no sense. As usual, it is two steps forward and one step back,
as this exposed some other weird latent issues like:
<rdar://problem/21900971> QoI: Bogus conversion error in generics case
Swift SVN r30429
Unlike trivial stored properties, observed properties get their accessors
created early on for some reason, before we have a type for the property.
If the type of the property was inferred and it was in a generic context,
we would then try to validate the generic signature before setting the
type of the setter's newValue parameter. Change the order to fix this.
Fixes <rdar://problem/21476759>.
Swift SVN r30381
done, the rest of the infrastructure is all common and can be simplified. This
leaves us with a quite small and maintainable subsystem for diagnosing these
kinds of problems.
include/swift/AST/DiagnosticsSema.def | 28 ++-----
lib/Sema/CSDiag.cpp | 132 ++++++++++------------------------
2 files changed, 48 insertions(+), 112 deletions(-)
Swift SVN r28957
this is neutral w.r.t. diagnostics quality, but deletes a ton
of code:
include/swift/AST/DiagnosticsSema.def | 21 ++---------
lib/Sema/CSDiag.cpp | 64 ++--------------------------------
2 files changed, 9 insertions(+), 76 deletions(-)
Swift SVN r28956
that make vardecls and subscripts immutable. This makes the indirect cases
a lot more specific ("this is a get-only property" instead of "this is
immutable") and allows us to consolidate a bunch of code:
2 files changed, 45 insertions(+), 119 deletions(-)
Swift SVN r28954
which tell you what the problem is, not just that you have one.
- Enhance diagnostics to be more specific about function calls producing
rvalues.
Swift SVN r28939
if it has already resolved a member binding of an UnresolvedDotExpr. This allows
us to give tailored diagnostics to indicate whether the destination is not an lvalue
because the property itself was immutable or when the base is immutable.
In addition to improved diagnostics, this allows us to fixit hint "let" to "var" on
property definitions, and we can even go so far as to fixit hint insert 'mutating' on
the enclosing func decl when self is the problem.
This fixes the non-subscript cases of:
<rdar://problem/17632908> QoI: Modifying struct member in non-mutating function produces difficult to understand error message
<rdar://problem/19370429> QoI: fixit to add "mutating" when assigning to a member of self in a struct
<rdar://problem/20234955> QoI: Error message for assigning to 'let' fields should say that the error is due to a 'let' binding
Subscript cases to follow.
Swift SVN r28854
<rdar://problem/15975935> warning that you can use 'let' not 'var'
<rdar://problem/18876585> Compiler should warn me if I set a parameter as 'var' but never modify it
<rdar://problem/17224539> QoI: warn about unused variables
This uses a simple pass in MiscDiagnostics that walks the body of an
AbstractFunctionDecl. This means that it doesn't warn about unused properties (etc),
but it captures a vast majority of the cases.
It also does not warn about unused parameters (as a policy decision) because it is too noisy,
there are a variety of other refinements that could be done as well, thoughts welcome.
Swift SVN r28412
- <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
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
requires pushing the types out. The only interesting one is this diff:
- var (e,f,g:(),h) = MRV()
+ var (e,f,g,h) : (Int, Float, (), Double) = MRV()
... where the type annotation is required to silence the warning about "void type
may be unexpected". This seems perfectly reasonable to me.
Swift SVN r26161
If a non-static 'let' field in a struct has an initializer, its implicitly generated
memberwise initializer should not override that. Handle this by having the memberwise initializer
and default initializer use the initial value of the property instead of an argument to the init.
This would have been a lot easier if sema was synthesizing the ctor bodies instead of SILGen,
but here it is. The missing case is narrow (let (x,y) = (1,2)) and for now we just disable
implicit synthesization of the incorrect case.
Swift SVN r25424
Previously, adding observing accessors to a variable caused it to require
an explicit type /and/ an initializer. Now you just need one or the other;
the type of the accessors is drawn from the type of the VarDecl, whether
inferred or explicitly written.
rdar://problem/18148072
Swift SVN r24664
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
Append "did you mean 'static'?" when hitting the unimplemented class
stored properties diagnostic in a class context.
Provide a fix-it for typing "static final" in a class, which is
redundant.
Swift SVN r24358
The previous patch to allow static class stored properties
inadvertently allowed 'class final' spellings for static
stored properties in classes. This patch only allows 'static'
spellings to create the global storage.
Swift SVN r24323
rdar://problem/17198298
- Allow 'static' in protocol property and func requirements, but not 'class'.
- Allow 'static' methods in classes - they are 'class final'.
- Only allow 'class' methods in classes (or extensions of classes)
- Remove now unneeded diagnostics related to finding 'static' in previously banned places.
- Update relevant diagnostics to make the new rules clear.
Swift SVN r24260
