This PR migrates instance member on type and type member on instance diagnostics handling to use the new diagnostics framework (fixes) and create more reliable and accurate diagnostics in such scenarios.
Diagnose redundant same-type constraints using most of the same
machinery for diagnosing other redundant constraints. However,
same-type constraints are particularly interesting because
redundancies can be spelled in a number of different ways. Address
this using the connected components of the subgraph involving only
derived requirements (which is already used for the minimized generic
signature). Then, separate all of the non-derived requirements into
the intracomponent requirements and intercomponent requirements:
* All of the intracomponent requirements are redundant by definition,
because the components are defined by derived constraints.
* For the intercomponent requirements, form a spanning tree among the
various components and diagnose as redundant any edges that do not
extend the spanning tree.
This was necessary when we would 'adopt' archetypes from outer
contexts, but that is long gone, and the only thing it accomplished
was emitting duplicate diagnostics.
ArchetypeBuilder::finalize() is needed to tie up any loose ends before
requesting a generic signature or generic environment. Make sure it
gets called consistently.
We would falsely diagnose the occurrence of the protocol
_in the inheritance clause_ as a "bad" usage of an
existential type, because the UnsupportedProtocolVisitor
was too eager in walking into nested Decls and Stmts.
Note that in one case we don't emit a diagnostic where we
did before, but this doesn't matter; the VarDecl in
question becomes invalid later, and only the order in
which the decls are visited changes.
and provide a fix-it to move it to the new location as referenced
in SE-0081.
Fix up a few stray places in the standard library that is still using
the old syntax.
Update any ./test files that aren't expecting the new warning/fix-it
in -verify mode.
While investigating what I thought was a new crash due to this new
diagnostic, I discovered two sources of quite a few compiler crashers
related to unterminated generic parameter lists, where the right
angle bracket source location was getting unconditionally set to
the current token, even though it wasn't actually a '>'.
- All parts of the compiler now use ‘P1 & P2’ syntax
- The demangler and AST printer wrap the composition in parens if it is
in a metatype lookup
- IRGen mangles compositions differently
- “protocol<>” is now “swift.Any”
- “protocol<_TP1P,_TP1Q>” is now “_TP1P&_TP1Q”
- Tests cases are updated and added to test the new syntax and mangling
This commit defines the ‘Any’ keyword, implements parsing for composing
types with an infix ‘&’, and provides a fixit to convert ‘protocol<>’
- Updated tests & stdlib for new composition syntax
- Provide errors when compositions used in inheritance.
Any is treated as a contextual keyword. The name ‘Any’
is used emit the empty composition type. We have to
stop user declaring top level types spelled ‘Any’ too.
Allow 'static' (or, in classes, final 'class') operators to be
declared within types and extensions thereof. Within protocols,
require operators to be marked 'static'. Use a warning with a Fix-It
to stage this in, so we don't break the world's code.
Protocol conformance checking already seems to work, so add some tests
for that. Update a pile of tests and the standard library to include
the required 'static' keywords.
There is an amusing name-mangling change here. Global operators were
getting marked as 'static' (for silly reasons), so their mangled names
had the 'Z' modifier for static methods, even though this doesn't make
sense. Now, operators within types and extensions need to be 'static'
as written.
This patch includes testsuite changes to show each of the decls supported.
Next step is to migrate the stdlib + testsuite + corelibs: I'd would *greatly* appreciate help with this.
After that is done, deprecation + migration of the old form can happen.
Straightforward extension of the previous work here to handle callees
with multiple generic parameters. Same type requirements are already
handled by the ArchetypeBuilder, and protocol conformance is handled
explicitly. This is still bailing on nested archetypes.
Pre-existing tests updated that now give better diagnoses.
Correctly determine callee closeness for func/ops that include generics
as part of more complicated parameters, i.e. tuple or closure args
containing generics as elements or args/results. Still only handling
single archetypes.
Also added code to check generic substitutions already made in the callee
parameters, which further helps diagnosis.
- Improve the specific cases of nil and empty collection literals.
- Improve cases of contextual member lookup where the result type of the looked up member disagrees with context.
- Add some fixme's to the testsuite for cases of this diagnostic that should be diagnosed in other ways.
In the specific case of sr-69, and in a bunch of other code where
errors arise involving generic function application, better type
constraint failure diagnoses are being masked by the overly
conservative implementation in evaluateCloseness(). If the actual arg
types didn’t exactly match the parameter types, we’d always diagnose a
non-specific arguments-don’t-match error instead of allowing discovery
of better errors from the constraint system.
This commit adds more cases where evaluateCloseness will return
CC_ExactMatch, specifically in application of functions with one or
more arguments of a single archetype, like `func min<T: Comparable>(T,
T) -> T`. It verifies that the actual argument type
isSubstitutableFor() the archetype, and that all such arguments are of
the same type. Anything more complicated than that still has the
previous behavior of not matching at all.
I think the final answer here ought to be to make a constraint system
with type variables for any archetypes, add appropriate constraints to
the actual args and then see if the system can solve all the argument
constraints at once. That’s because the next most complicated set of
things to handle in the stdlib are things like `func -<T:
Strideable>(lhs: T, rhs: T.Stride)` where generic argument types depend
on each other. I tried attacking that, but it was too big of a bite for
me to manage all at once. But there are FIXME’s here to try that again
at some point.
New tests for SR-69 are at the end of deduction.swift, and the rest of
the test changes are generally improved deduced diagnoses. I think the
changed diagnoses in materializable_restrictions.swift is the only one
which is worse instead of better, and that’s just because the previous
general message mentioned `inout` basically accidentally. Opportunity
for further improvement (a new diagnosis maybe) there.
Validation tests run and passed.
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.
Previously we erroneously complained:
error: cannot invoke 'contains' with an argument list of type '(String)'
now we correctly complain:
error: unexpected non-void return value in void function
This enhances CSDiags to use "getTypeOfMember" when analyzing method
candidates that are applied to a known base type. Using it allows us to
substitute information about the base, resolving archetypes that exist in
subsequent argument positions. In the testcase, this means that we use
information about Set<String> to know that the argument to "contains" is a
String.
This allows us to generate much better diagnostics in some cases, and works
around some limitations in the existing stuff for handling unresolved
archetypes. One unfortunate change is the notes in Misc/misc_diagnostics.swift.
Because we don't track argument lists very well, we are flattening an argument
list that is actually ((Int,Int)) into (Int, Int) so we get a bogus looking
diagnostic. This was possible before this patch though, it is just one
more case that triggers the issue.
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
machinery, instead of in multiple places in CSSolver and CSDiags. This leads
to more predictable behavior (e.g. by removing the UnboundGenericParameter
failure kind) and eliminates a class of "'_' is not convertible to 'FooType'"
diagnostics.
Swift SVN r30923
other constraints intentionally ripped off, tell the recursive solution that
we can tolerate an ambiguous result. The point of this walk is not to
produce a concrete type for the subexpression, it is to expose any structural
errors within that subsystem that don't depend on the contextual constraints.
Swift SVN r30917
fixing <rdar://problem/22020088> QoI: missing member diagnostic on optional gives worse error message than existential/bound generic/etc
Swift SVN r30844
- 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
detailed analysis of callees, which give us overload sets in more cases,
producing notes more consistently, and producing much better diagnostics
for the curried cases in test/Constraints/diagnostics.swift.
This also allows us to eliminate getCalleeName, which simplifies things
in CSDiags.
Swift SVN r30491
return statements, or a return statement with no operand.
Also, fix a special-case diagnostic about converting a return
expression to (1) only apply to converting the actual return
expression, not an arbitrary sub-expression, and (2) use the
actual operand and return types, not the drilled-down types
that caused the failure.
Swift SVN r30420
1) Teach resolveImmutableBase about SubscriptExprs that have
resolved the decl that they are referring to. This fixes case where we'd
generate an imprecise diagnostic because we weren't able to find the
result in the ResolvedOverloadSet list (which is because CSApply rewrite
it to a different expr node and the locator can't find it).
2) Change FailureDiagnosis::typeCheckIndependentSubExpression to have a
blacklist of expressions that aren't recursed into, along with rationale
for each node kind, instead of a short white list. This produces more
predictable results, e.g. producing the right diagnostic in
ClangModules/objc_parse.swift
Swift SVN r30118
argument list for a CallExpr instead of matching a gang of typevartypes against them.
This allows us to produce better matches in some cases.
Swift SVN r30065
facilities used by operators etc. This required a bunch of changes to make
the diagnostics changes strictly an improvement:
- Teach the new path about calls to TypeExprs.
- Teach evaluateCloseness some simple things about varargs.
- Make the generic diagnosis logic produce a better error when there is
exactly one match.
Overall, the resultant diagnostics are a step forward: we now produce candidate
set notes more uniformly, and the messages about some existing ones are
more specific. This is just another stepping stone towards progress though.
Swift SVN r30057
