If there was any requirements in the @objc protocol, the user got an error in
some form (a complaint about those requirements), but giving the direct error is
better, and handles @objc protocol with no requirements.
Also, fix a hole in that existing @objc method check: in `class Outer<T> { class
Inner {} }`, Inner should be considered generic, but the loop that was checking
for this didn't consider it.
Fixes https://bugs.swift.org/browse/SR-7370 and rdar://problem/39239512.
When generating a compiler invocation in driver::createCompilerInvocation()
we end up using filelists if the number of inputs is > 128 (to work around
command line arg limits). We never actually write them out though, and so
fail when parsing the frontend arguments that reference them.
As this function is called frequently by SourceKit and command line limits
aren't a concern here, this patch makes the 128 threshold value configurable
via a new -driver-filelist-threshold option. This is set to its maximum value
in driver::createCompilerInvocation() to ensure filelists aren't used. This
new option makes the existing -driver-use-filelists (that forces filelists to
be used) redundant as it's now equivalent to -driver-filelist-threshold=0.
Resolves rdar://problem/38231888
This is a "no functionality change" commit because this isn't
/invoked/ on accessors yet; that's the next commit. I wanted to
separate out the mechanical part, though.
- Narrow the fix to classes with @objc ancestry only
- Pass -enable-class-resilience in class resilience executable test so that
we exercise resilience there
- Only enable fragile layout if the class has @objc ancestry
- Add an IRGen test
Continue to emit notes for the candidates, but use different text.
Note that we can emit a typo correction fix-it even if there are
multiple candidates with the same name.
Also, disable typo correction in the migrator, since the operation
is quite expensive, the notes are never presented to the user, and
the fix-its can interfere with the migrator's own edits.
Our general guidance is that fix-its should be added on the main
diagnostic only when the fix-it is highly likely to be correct.
The exact threshold is debateable. Typo correction is certainly
capable of making mistakes, but most of its edits are right, and
when it's wrong it's usually obviously wrong. On balance, I think
this is the right thing to do. For what it's worth, it's also
what we do in Clang.
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>.
- Must be a single pattern
- Must be last in the switch
- Must not have a 'where' clause
- Must specifically be the "any" pattern if using 'case'
We may lift some of these restrictions in the future, but that would
need a new proposal.
The other half of '@unknown' in Sema. Again, the diagnostics here
could be improved; rather than a generic "switch must be exhaustive",
it could say something about unknown case handling known cases.
One interesting detail here: '@unknown' is only supposed to match
/fully/ missing cases. If a case is /partly/ accounted for, not
handling the rest is still an error, even if an unknown case is
present.
This only works with switches over single enum values, not values that
contain an enum with unknown cases. That's coming in a later commit.
(It was easier to get this part working first.)
The first half of Sema support for '@unknown'. The other part is
handling when the user /does/ write '@unknown', which results in
/other/ things being downgraded to warnings.
The diagnostics here are still pretty minimal; they should explain
what's going on with '@unknown' to someone who hasn't read the Swift 5
release notes.
This is our first statement attribute, made more complicated by the
fact that a 'case'/'default' isn't really a normal statement. I've
chosen /not/ to implement a general statement attribute logic like we
have for types and decls at this time, but I did get the compiler
parsing arbitrary attributes before 'case' and 'default'. As a bonus,
we now treat all cases within functions as being switch-like rather
than enum-like, which is better for recovery when not in a switch.
Also, make ExistentialLayout non-self-referential, by moving that logic to the
point where it is used. The construction of the one-element-ArrayRef is so cheap
that it doesn't need to be cached.
Many uses of conditional conformance to protocols with super-protocols
are for wrappers, where the conformances to those super-protocols
usually ends up using weaker bounds, such as:
struct MyWrapper<Wrapped: Sequence> {}
extension Wrapped: Sequence {} // Wrapped: Sequence
extension Wrapped: Collection where Wrapped: Collection {} // *
extension Wrapped: BidirectionalCollection where Wrapped: BidirectionalCollection {}
If this code was instead written:
struct MyWrapper<Wrapped: Sequence> {}
extension Wrapped: Sequence {} // Wrapped: Sequence
extension Wrapped: BidirectionalCollection where Wrapped: BidirectionalCollection {}
Inferring a Collection conformance would have to mean
extension Wrapped: Collection where Wrapped: BidirectionalCollection {}
which is unnecessarily strong.
It is a breaking change to change a protocol bound, and so we're
thinking we'd prefer that the compiler didn't magic up that incorrect
conformance. It also only is a small change (and the compiler even
suggests it, with a fixit) to explicitly get the implying behaviour:
declare the conformance explicitly.
extension Wrapped: Collection, BidirectionalCollection where Wrapped: BidirectionalCollection {}
Fixes rdar://problem/36499373.
We need to be able to find which conformances need to be
declared/constructed without forcing extensions to be completely
validated. This is important for both SR-6569 and
rdar://problem/36499373. The former due to the source-level recursion,
and the latter because implied conformances weren't always
constructed (but are needed for good diagnostics).
They weren't always constructed because:
1. ConformanceLookupTable's updateLookupTable on an early stage (before
implied conformances are found) triggers extension
validation *before* constructing any conformances, but *after*
updating the stage state
2. extension validation validates the conditional requirements
3. validating the conditional requirements requires setting up generic
signatures
4. setting up generic signatures forces the types conformances and so
ends up in updateLookupTable on the same nominal again, skipping over
the earlier stages that are complete/in progress
5. we expand the conformances that are implied by all the conformances we
know about... But we don't know any, because we haven't finished the
first updateLookupTable.
This breaks the loop at step 2: we instead do the minimal work needed to
know what conformances an extension (might) declare, which is connect
the extension to a type, and then resolve the inherited TypeReprs to
Types.
With the previous changes, validating a property while
type checking its initializer is no longer a fatal error.
This means we don't have to do anything special when
validating typo correction candidates, so we can get rid
of the TypoCorrectionResolver. This means there is now
only one subclass of LazyResolver, the TypeChecker itself.
We can use the existing logic for checking recursion in
declaration validation. This eliminates some bogus
diagnostics and allows some weird logic to be removed
from typo correction.
Builds on 36eae9d4f6 to emit a message instead of just trapping
when a switch over a non-frozen enum ends up not matching anything.
If the enum is known to be an @objc enum, the message is
unexpected enum case 'MyEnum(rawValue: -42)'
and if it's anything else (a Swift enum, a tuple containing enums,
whatever), it's a more opaque
unexpected enum case while switching on value of type 'MyEnum'
The reason for this is to avoid calling String(describing:) or
String(reflecting:) an arbitrary value when the enum might conform to
CustomStringConvertible and therefore /itself/ have a switch that's
going to fall off the end. By handling plain @objc enums (using a
bitcast), we've at least covered the 90% case.
rdar://problem/37728359
The amp_prefix token is currently tolerated in any unary expression
context and then diagnosed later by Sema. This patch changes parsing to
only accept tok::amp_prefix in its allowed position: parameter lists.
This also fixes two "compiler crasher" tests.
Code may end up indirectly using a witness table for a Clang-imported type by inlining code that used the conformance from another module, in which case we need to ensure we have a local definition at hand in the inlining module so we can have something to link against independently. This needs to be fixed from both sides:
- During serialization, serialize not only witness tables from the current module, but from Clang-imported modules too, so that their definitions can be used by other modules that inline code from the current module
- During IRGen, when we emit a reference to a SILWitnessTable or SILFunction declaration with shared linkage, attempt to deserialize the definition on demand
Fixes rdar://problem/38687726.
