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
The test/Parse/enum.swift test was only enabled for Intel platforms because a
few of the contained test cases relied on floating point literal parsing and
were not portable as a result. Subset out the non-portable test cases into a
new test so that more general enum parsing tests can run on all platforms.
Enums with raw type `: String ` use the case name as the raw
value. So, two identical case names cause an identical raw value
error. Also, identical case names cause a separate redeclaration
error. The second error is diagnosed in a separate request in the
DeclVisitor. We may need a special case for this situation to
ignore the first error and defer diagnosing to the
CheckRedeclarationRequest. For now we will diagnose both errors.
`enum Foo : String {
case Bar
case Bar = "FooBar" // redclaration error only
case Bar // redeclaration and raw value error
}`
This meant we weren't producing sema diagnostics for the case, and it didn’t
get full syntactic/semantic highlighting or indentation.
enum CasesWithMissingElement {
case a(Int, String),
case b(Int, String),
}
Resolves rdar://problem/61476844
`_` or discard assignment expression should only be used on the left-hand
side of the assignment expression. Incorrect uses are easy to detect during
constraint generation which also allows us to avoid complications related
to other diagnostics when `_` is used incorrectly.
* [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
* Fixes SR-11261
* Improving diagnostics for multi-case declaration that uses a keyword
* Only doing pattern matching if token is not a keywork or if is a possible identifier
* Using BacktrackingScope to fix expected pattern
* Updating NameLoc with the token consumed.
* Updating Name with the consumed token
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
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.
SE-0155 makes an empty associated value list in an enum element
declaration illegal. Warn about this in legacy Swift mode, and reject
it otherwise. This offers two fixes:
1) Remove the empty associated value list
2) Insert a 'Void' associated value
From the perspective of the compiler implementation, they're elements. But users will think of these as cases—and many diagnostics already refer to these as enum cases.
And provide better semantic background by surrounding 'nil' in ticks when it is referred to as a value
Added missing tests for certain cases involving nil capitalization
The user experience with extended grapheme literals is currently:
1. Strict: we hard error on "invalid" grapheme literals.
2. Complete: we validate all literals to either be
known-single-grapheme or not.
3. Incorrect: we have Unicode 8 semantics implemented but applications
will have some other version of Unicode as dictated by the OS they are
running on.
In Swift 4.0, this incorrectness mostly crops up in obscure corner
case areas, where we are overly restrictive in some ways and overly
relaxed in others. But, there is one particularly embarrassing area
where it does come up: we reject emoji introduced after Unicode 8 as
grapheme literals, counter to common user expectations.
In a future (sub-)version of Swift we should completely re-evaluate
this user story, but doing so in time for Swift 4.0 is untenable. This
patch attempts to tweak the way in which we are incorrect in the most
minimally invasive way possible to preserve the same user experience
while permitting many post-Unicode-8 emoji as valid grapheme literals.
This change overrides processing of ZWJ and emoji modifiers to not
declare a grapheme break after/before, respectively.
Instead of the simple "expected identifier in declaration", the error will now read "keyword '%' cannot be used as an identifier here", and will be accompanied by a note suggesting escaping the keyword with backticks, as well as a fixit.
https://bugs.swift.org/browse/SR-3167
The problem here is that we would just emit 'invalid pattern'
instead of digging deeper, which meant that the fix-it for
qualified enum element access wasn't getting inserted for
more complex patterns, such as 'case X(let x)'.
Unfortunately, in the matching_patterns.swift test, we emit
too many diagnostics that are not really useful to figuring
out the problem, and the old 'invalid pattern' made more
sense. I'll work on some CSDiag tweaks to address this --
I think it makes more sense to dig there than just emit a
general 'invalid pattern' diagnostic anyway.
Fixes <rdar://problem/27684266>.
Suggest a fix-it for unqualified references to all static members
from instance context, not just enum elements.
Also, fix a small problem with the fix-it for replacing protocol
names with 'Self' inside extension bodies -- we didn't handle nested
functions properly.
This removes the logic which issued warnings when accessing enum
elements as instance members (SE-0036), making room for a new
implementation that will issue errors instead.
This reverts commit ae1058a39a.
change includes both the necessary protocol updates and the deprecation
warnings
suitable for migration. A future patch will remove the renamings and
make this
a hard error.
Make the following illegal:
switch thing {
case .A(var x):
modify(x0
}
And provide a replacement 'var' -> 'let' fix-it.
rdar://problem/23172698
Swift SVN r32883
