These are tests that fail in the next commit without this flag. This
does not add -verify-ignore-unrelated to all tests with -verify, only
the ones that would fail without it. This is NFC since this flag is
currently a no-op.
Some editors use diagnostics from SourceKit to replace build issues. This causes issues if the diagnostics from SourceKit are formatted differently than the build issues. Make sure they are rendered the same way, removing most uses of `DiagnosticsEditorMode`.
To do so, always emit the `add stubs for conformance` note (which previously was only emitted in editor mode) and remove all `; add <something>` suffixes from notes that state which requirements are missing.
rdar://129283608
Compute a slice of ambiguous overload choices related to an aggregated fix
and if such a slice points to a single overload diagnose it as non-ambiguous.
Sema can infer type witnesses for a small set of known conformances, to
RawRepresentable, CaseIterable, and Differentiable.
Previously, we would try to compute the type witness in this order:
1) First, via name lookup, to find an explicit nested type with the
same name as an associated type.
2) Second, we would attempt inference.
3) Third, we would attempt derivation.
Instead, let's do 3) before 2). This avoids circularity errors in
situations where the witness can be derived, but inference fails.
This breaks source compatibility with enum declarations where the raw
type in the inheritance clause is a lie, and the user defines their
own witnesses with mismatched types. However, I suspect this does not
come up in practice, because if you don't synthesize witnesses, there
is no way to access the actual raw literal values of the enum cases.
Introduce `repairByUsingRawValueOfRawRepresentableType` which is used for
assignment, argument-to-parameter conversions and contextual mismatches.
It checks whether `from` side is a raw representable type and tries
to match `to` side to its `rawValue`.
Also extract logic common for `repairByUsingRawValueOfRawRepresentableType`
and `repairByExplicitRawRepresentativeUse` into `isValueOfRawRepresentable`.
Introduce `repairByExplicitRawRepresentativeUse` which is used for
assignment, argument-to-parameter conversions and contextual mismatches.
It checks whether `to` side is a raw representable type and tries
to match `from` side to its `rawValue`.
* In the DeclChecker, duplicate the check that we have a reasonable
RawValue type so we do not attempt to form an invalid key. The interface
to the autoincrementer has this as invariant, but it was not previously
checked as a precondition.
* In the deriver, try to check for the case where the user has written
a mismatched explicit declaration of RawValue, or a type sharing that
name, and check type equality with the declared raw type to make this
pass resilient to mismatches as well.
Resolves rdar://57072148, rdar://59703784
The error recovery logic around derived conformances is a little bit
tricky. Make sure we don't crash if a type explicitly provides a
RawValue type witness that is not equatable, but omits the witnesses
for init(rawValue:) and the rawValue property.
Fixes <rdar://problem/58127114>.
* [TypeChecker] Enclosing stubs protocol note within editor mode
* [test] Removing note from test where there is no -diagnostics-editor-mode flag
* Formatting modified code
* [tests] Fixing tests under validation-tests
In preparation for checkEnumRawValues being turned into a request, move the common diagnostics to the decl checker so they're always emitted at the right time.
Under non-editor mode, the fixit for inserting protocol stubs is associated with a note
pointing to the missing protocol member declaration which could stay in a separate file from
the conforming type, leading to the behavior of rdar://51534405. This change checks if
the fixit is in a separate file and issues another note to carry the fixit if so.
rdar://51534405
When there are multiple possible overloads for a call, the partially-
type-checked argument expression might end up with a LoadExpr outside
of the call ParenExpr instead of inside it. Account for this in a one-
off way for the 'rawValue' / 'init(rawValue:)' fix-its.
Yet more https://bugs.swift.org/browse/SR-8150
That is, if a type has a raw value of Int, and the function being
called has overloads for both Int and UInt, we always want to offer a
fix-it that leads to the 'Int' overload, not insert a conversion to
UInt that might be incorrect.
More https://bugs.swift.org/browse/SR-8150.
They were being put outside the call parentheses instead of inside.
We even had tests for this; I just got them wrong.
https://bugs.swift.org/browse/SR-8150
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.
Part of the fix-it for conversion from optional to raw representable
was inserted at the incorrect position which produces invalid expression.
Resolves: rdar://problem/32431736
Covers some common situations when switching from literal types e.g.
string or int to more Swift Way of raw representable enum of choices.
Resolves: rdar://problem/32431165, rdar://problem/31977537, rdar://problem/32432253
Situations where there is a contextual RawRepresentable type is
used incorrectly would produce `<Type>(rawValue: )` fix-it only
in cases where neither or both sides of the expression are optional.
Let's fix that by adding a fix-it for optional to contextual raw
value type conversion.
Resolves: rdar://problem/32431736
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
Per API review with Ali. While we're here, give the initializer a corresponding 'rawValue' argument label, and change the associated type name to RawValue to match.
Swift SVN r21888
Redefine the RawRepresentable protocol to use an 'init?' method instead of 'fromRaw(Raw)', and a 'raw' get-only property instead of 'toRaw()'. Update the compiler to support deriving conformances for enums and option sets with the new protocol. rdar://problem/18216832
Swift SVN r21762
Mechanically add "Type" to the end of any protocol names that don't end
in "Type," "ible," or "able." Also, drop "Type" from the end of any
associated type names, except for those of the *LiteralConvertible
protocols.
There are obvious improvements to make in some of these names, which can
be handled with separate commits.
Fixes <rdar://problem/17165920> Protocols `Integer` etc should get
uglier names.
Swift SVN r19883
We haven't been advertising this syntax much, and it's closure form
was completely broken anyway, so don't jump through hoops to provide
great Fix-Its here.
Swift SVN r19277
This is motivated by <rdar://problem/17051606>.
This ends up renaming variables as well, which seems right for
consistency since we use "predicate" as variable name.
Swift SVN r19135
Normally, protocol conformances are only checked for types and extensions
declared in the current file. However, for protocols that can derive their
conformances (like RawRepresentable), other files in the target might
expect to be able to use the protocol members (like toRaw), which aren't
written in the source. Force the derivation if this is the case.
Also, move the /other/ set of RawRepresentable tests from test/Parse to
test/Sema.
<rdar://problem/15936403>
Swift SVN r14162
