https://github.com/swiftlang/swift/pull/72659 turned out to have some
source compatibility fallout that we need to fix. Instead of introducing
yet another brittle compatibility hack, stop emitting errors about a
missing `any` altogether until a future language mode.
Besides resolving the compatibility issue, this will encourage
developers to adopt any sooner and grant us ample time to gracefully
address any remaining bugs before the source compatibility burden
resurfaces.
A subsequent commit adds a diagnostic group that will allow users to
escalate these warnings to errors with `-Werror ExistentialAny`.
- Don't pass 'verify' since it's now the default
- Update tests where diagnostics changed in a correct way to pass 'on' instead
- Delete compiler_scale/explicit_requirements_perf.swift since it's not testing anything with the requirement machine
The previous warning "must be explicitly marked as 'any'" isn't clear if
you don't already know the feature, this new phrasing should make it
clearer by including the correct spelling of the type as an example.
Fixes rdar://90384448
The following regression test added for this feature is not passing:
Swift(linux-x86_64) :: decl/protocol/protocols_with_self_or_assoc_reqs_executable.swift
with a compiler crash happening during SILFunctionTransform "Devirtualizer".
Reverting to unblock CI.
This reverts commit f96057e260, reversing
changes made to 3fc18f3603.
Use the FullyQualified<Type> abstraction from the prior commit plus DescriptiveDeclKind to give a bit more information when issuing a missing member type diagnostic during type resolution.
The type checker shouldn’t know about potential archetypes. Use
GenericSignatureBuilder::resolveEquivalenceClass() and perform the lookup
into that instead.
The test case change highlights an existing problem with generic signature
minimization.
The type checker shouldn’t know about potential archetypes. Use
GenericSignatureBuilder::resolveEquivalenceClass() and perform the lookup
into that instead.
The test case change highlights an existing problem with generic signature
minimization.
This reverts commit afbdbae9d9.
Commit ded45a6e1c more than triples the
type checking time when building Swift.o, so I am going to revert that ,
and it looks like this needs to be reverted as well if that commit is
reverted.
Recursive protocol conformances still aren't functional, so reinstate
some checking for recursive protocol conformances. It doesn't catch
everything that the previous version did---but we don't crash on such
cases anymore, either.
Move the storage for the protocols to which a particular potential
archetype conforms into EquivalenceClass, so that it is more easily
shared. More importantly, keep track of *all* of the constraint
sources that produced a particular conformance requirement, so we can
revisit them later, which provides a number of improvements:
* We can drop self-derived requirements at the end, once we've
established all of the equivalence classes
* We diagnose redundant conformance requirements, e.g., "T: Sequence"
is redundant if "T: Collection" is already specified.
* We can choose the best path when forming the conformance access
path.
The canonicalization of dependent member types had some
nondeterminism. The root of the problem was that we couldn't
round-trip dependent member types through the archetype
builder---resolving them to a potential archetype lost the specific
associated type that was recorded in the dependent member type, which
affected canonicalization. Maintain that information, make sure that
we always get the right archetype anchor, and tighten up the
canonicalization logic within a generic signature.
Fixes rdar://problem/30274260 and should unblock some other work
that depends on sanity from the archetype builder and generic
signature canonicalization.
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 '>'.
This exposes some wierdness with while_parsing_as_left_angle_bracket where
one case the note is being is when resolveType returns a failure. However,
resolveType can produce a failure without emitting a diagnostic, and this
can lead to us generating a note unattached to an error. Just remove this
case.
Set type repr's as invalid after diagnosing an unsupported protocol
to stop duplicate diagnoses.
There were two causes here. First, top-level variable
declarations were being checked once by the Decl checker, and then
again by the Stmt checker. (This caused SR-38.)
Second, the Stmt checker is called by an AST visitor itself, which
already calls it once per statement. Using the
UnsupportedProtocolVisitor here meant that each interior sub statement
would get visited multiple times. Added a setRecurseIntoSubstatements()
on the visitor, and set it to false for the Stmt checker. This keeps
from revisiting statements multiple times.
The idea here is to do more marking of the generic parts of the
protocol as being invalid as soon as the recursiveness is diagnosed in
order to simplify checking (and avoid infinite loops) down the line.
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.
Having bound types in TypeReprs causes trouble in several places
(mostly involving type-checking of generics), and doesn't really fit
with TypeReprs being a mostly syntactic construct. Eliminate some code
paths using getBoundType(), and make the others do the same thing for
getBoundDecl() and getBoundType(). As part of the latter, provide
TypeBase::getDirectlyReferencedTypeDecl() to more easily map from type
to the named declaration.
Swift SVN r32018
We have to check for cycles of length > 1 here. Also, add a bit to the
AssociatedTypeDecl to ensure the recursive requirement diagnostic is
only emitted once.
Fixes <rdar://problem/17986597>.
Swift SVN r30678
Reduces the number of duplicate diagnostics down to 2. Which is still
lame, but it's due to a different underlying issue. Finishes
rdar://problem/20682090.
Swift SVN r30043
Replace some dodgy recursion-breaking code in the archetype builder
that was meant to deal with recursive associated type requirements
(which our model does not currently support) with a more robust
approach. Fixes rdar://problem/20682090 and rdar://problem/21738889.
Swift SVN r30039
var/let bindings to _ when they are never used, and use some values that
are only written. This is a testsuite cleanup, NFC. More to come.
Swift SVN r28406
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
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
This can only occur when validating mutually recursive existentials in type reference expressions, so it's "safe" to avoid validating member value decls in this case. There are still potential holes in our mechanism for checking for unsupported existentials, but at least this will eliminate another common crasher. (Crash suite scenario 010.)
Swift SVN r22035
