- Many tests got broken because of two things:
- AST dump now outputs to stdout, but many tests expected stderr. This was a straightforward fix.
- Many tests call swift with specific parameters; specifically, many call `swift frontend` directly. This makes them go through the compiler in unexpected ways, and specifically it makes them not have primary files, which breaks the new AST dump implementation. This commit adds the old implementation as a fallback for those cases, except it dumps to `stdout` to maintain some consistence.
Finally, the `/test/Driver/filelists.swift` failed for unknown reasons. It seems its output now had some lines out of order, and fixing the order made the test pass. However, as the reasons why it failed are unknown, this fix might not have been a good idea. Corrections are welcome.
This makes diagnostics more verbose and accurate, because
it's possible to distinguish how many parameters there are
based on the message itself.
Also there are multiple diagnostic messages in a format of
`<descriptive-kind> <decl-name> ...` that get printed as
e.g. `subscript 'subscript'` if empty labels are omitted.
Whenever we visit a declaration via the DeclChecker, add it to the
list of declarations to finalize. This makes sure that we can centralize
the notion of “finalize for SILGen” and that it will be called for
everything in the source file being processed.
That is, if there's a problem with a witness, and the witness comes
from a different extension from the conformance (or the original type,
when the conformance is on an extension), put the main diagnostic on
the conformance, with a note on the witness. This involves some
shuffling and rephrasing of existing diagnostics too.
There's a few reasons for this change:
- More context. It may not be obvious why a declaration in file
A.swift needs to be marked 'public' if you can't see the conformance
in B.swift.
- Better locations for imported declarations. If you're checking a
conformance in a source file but the witness came from an imported
module, it's better to put the diagnostic on the part you have
control over. (This is especially true in Xcode, which can't display
diagnostics on imported declarations in the source editor.)
- Plays better with batch mode. Without this change, you can have
diagnostics being reported in file A.swift that are tied to a
conformance declared in file B.swift. Of course the contents of
A.swift also affect the diagnostic, but compiling A.swift on its
own wouldn't produce the diagnostic, and so putting it there is
problematic.
The change does in some cases make for a worse user experience,
though; if you just want to apply the changes and move on, the main
diagnostic isn't in the "right place". It's the note that has the info
and possible fix-it. It's also a slightly more complicated
implementation.
We don't allow things like
extension Type: P where Param: P {}
extension Type: P where Param: Q {}
or
extension Type: P where Param == Int {}
extension Type: P where Param == Float {}
or
extension Type: P where Param: P {}
extension Type: P where Param == SomethingThatIsntP {}
and the default error message "redundant conformance" message doesn't convey
this very well.
Fixes rdar://problem/36262409.
The fix for <https://bugs.swift.org/browse/SR-617> introduced
a new kind of requirement environment where 'Self' remains a
generic parameter, but receives a class constraint, instead of
becoming fully concrete.
As before, we would form the synthetic signature by taking
the generic signature of the requirement, and substituting it
the new 'Self' type.
However, whereas previously the 'Self' type was always concrete
and any DependentMemberTypes in the requirement's signature
would become concrete type references, with a class-constrained
'Self' the DependentMemberTypes remain.
Apparently, the GSB cannot handle DependentMemberTypes where
the base is class-constrained.
Work around this by ensuring that we add a conformance constraint
for the 'Self' parameter to the protocol in question, which
allows the DependentMemberTypes to be correctly resolves once
the conformance is made concrete by a superclass constraint.
The FIXME comment being removed here references crashes which
no longer seem to reproduce, so I'm assuming some underlying
GSB issues got fixed and the FIXME is clearly no longer necessary.
However, I still consider this fix somewhat unsatisfying, because
it is not clear if there's some deeper flaw in how the GSB
models superclass constraints. It might resurface again in the
future.
Fixes <rdar://problem/39419121>, <https://bugs.swift.org/browse/SR-7428>.
A protocol extension of a private protocol can define internal
or public members. We should not be able to find these members
from another file or module if an internal or public type
conforms to the protocol.
Fixes <rdar://problem/21380336>.
Rather than relying on the NameAliasType we get by default for references
to non-generic typealiases, use BoundNameAliasType consistently to handle
references to typealiases that are formed by the type checker.
Extend protocol conformance checking to allow a requirement with an
escaping parameter (of function type) to be satisfied by a witness
with a corresponding non-escaping parameter. This limited form of
covariance was already supported by SILGen and is needed to address
the source-compatibility "regression" introduced by inferring escaping
function types for associated type witnesses. It's also obviously a
good idea :)
Fixes rdar://problem/35297911.
When inferring an associated type witness by matching a function signature,
adjust non-escaping function types to escaping function types, because only
escaping function types could be written as explicit witnesses and
non-escaping function types are not permitted outside of function
parameters.
Addresses the first part of rdar://problem/35297911, eliminating the
type-soundness issue.
Extend protocol conformance checking to allow a requirement with an
escaping parameter (of function type) to be satisfied by a witness
with a corresponding non-escaping parameter. This limited form of
covariance was already supported by SILGen and is needed to address
the source-compatibility "regression" introduced by inferring escaping
function types for associated type witnesses. It's also obviously a
good idea :)
Fixes rdar://problem/35297911.
When inferring an associated type witness by matching a function signature,
adjust non-escaping function types to escaping function types, because only
escaping function types could be written as explicit witnesses and
non-escaping function types are not permitted outside of function
parameters.
Addresses the first part of rdar://problem/35297911, eliminating the
type-soundness issue.
This converts the instances of the pattern for which we have a proper
substitution in lit. This will make it easier to replace it
appropriately with Windows equivalents.
Move associated type inference into its own class, to make this
code easier to understand/maintain/improve. Minor diagnostics changes
because we're properly passing uninference associated type declarations
to the "group" checker.
We allow definitions like this:
struct G<T> {}
typealias A = G
As a shorthand for
typealias A<T> = G<T>
A typealias like this cannot satisfy an associated type requirement
for the same reason that a generic typealias cannot satisfy an
associated type requirement, which was already handled.
Previously this would crash in the type checker or in IRGen.
This fixes a weird regression in a fixed compiler crasher from the
next patch.
If a class was introduced in an OS newer than the deployment target,
suppress the inference of @_staticInitializeObjCMetadata, because
the resulting eager initialization will crash when run on older OS's.
This is a stop-gap solution; we want the eager initialization code to
check availability before registering the class, but that requires more
effort.
Fixes the main part of SR-6203 / rdar://problem/35161939.
Now that we pass in the correct type metadata for 'Self', it is
sound for a class to conform to a protocol with a default implementation
for a method returning 'Self'.
Fixes <rdar://problem/23671426>.
Now that we pass in the correct type metadata for 'Self', it is
sound for a class to conform to a protocol with a default implementation
for a method returning 'Self'.
Fixes <rdar://problem/23671426>.
Replace a where Type-pointer-equality check with what it intended,
i.e., match up ParenTypes at the top level and perform a deeper
equality comparison of the underlying types.
Fixes SR-5166 / rdar://problem/32666189.
