With `ARCMigrate` and `arcmt-test` removed from clang in
https://github.com/llvm/llvm-project/pull/119269 and the new code
migration experience under way (see
https://github.com/swiftlang/swift-evolution/pull/2673), these options
are no longer relevant nor known to be in use. They were introduced
long ago to support fix-it application in Xcode.
For now, turn them into a no-op and emit a obsoletion warning.
In this PR i worked on replacing the word accessor in diagnostics with more user-facing terminologies like setter, getter, didSet Observer, and members based on the context of the message.
in some messages i didn't need to pass DescriptiveDeclKind instead i just changed the text copy itself.
i also updated tests, so you might find it easier to check my changes this way.
Please let me know if there's something i should've done in a better way, and request changes if needed. !
i can squash my commits after reviewing getting the PR Reviewed, just to make it easier to be checked commit by commit
Resolves#55887
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
Stored `let` properties of a struct, class, or actor permit
'inout' modification within the constructor body after they have been
initialized. Tentatively remove this rule, only allowing such `let`
properties to be initialized (assigned to) and not treated as `inout`.
Fixes rdar://127258363.
Detect and diagnose a problem when explicitly specified closure
result type doesn't match what is expected by the context:
Example:
```swift
func foo(_: () -> Int) {}
foo { () -> String in "" } // `Int` vs. `String`
```
- When parsing a type or extension declaration, attempt to parse a function or property declaration when meeting an identifier, an operator or a paren (for tuple declarations).
- Produce the diagnostic with a fix-it suggesting to insert the needed keyword
- Recover parsing as if the declaration with the missing keyword is a function/property declaration
Resolves https://bugs.swift.org/browse/SR-10477
We still had unavailable versions of these for floating-point types
only. We shouldn't need to keep these around, and can instead just
emit a helpful diagnostic for anyone that attempts to use them.
Unfortunately I don't see any way for the diagnostic to produce an
actual fix-it, so it just suggests '+= 1' or '-= 1' without actually
producing a fix.
Allow witnesses to protocols in a copyable context to elide explicit
ownership conventions. This allows clients like the standard library to
standardize on one ownership convention without an ABI or API breaking
change in 3rd party code.
In the future, moveonly contexts must disallow this default behavior
else the witness thunks could silently transfer ownership.
rdar://40774922
protocol P {
__consuming func implicit(x: __shared String)
__consuming func explicit(x: __owned String)
__consuming func mismatch(x: __shared String)
}
class C : P {
// C.implicit(x:) takes self and x '@guaranteed' thru the witness thunk
func implicit(x: String) {}
// C.explicit(x:) takes self and x @owned with no convention changes
__consuming func explicit(x: __owned String) {}
// Would inherit __consuming, but x has been spelled __owned so the requirement match fails.
func mismatch(x: __owned String) {}
}
* [Diagnostics] SR-7445 Improve diagnostics for assignment failures
* modified messages for assignments to function calls,
modified messages for assignments to methods.
removed comment for resolved radar.
* removed extra line and braces
* added tests for assignment_lhs_is_apply_expression
eliminated redundant literal check which is always invoked before call
reverted 'cannot assign to value' for literal assignments in subexpressions
* Complemented assigning to literal tests & reverted to 'cannot asign to value' for methods (was 'cannot assign to member')
* removed extra tabs
* eliminated one more accidental spacing
* Update CSDiag.cpp
* added highlighting, fixed & rechecked tests
* added highlighting for complex expressions involving assigning to literals
Resolves: [SR-7445](https://bugs.swift.org/browse/SR-7445)
Currently edge related to the parameter bindings is contracted
without properly checking if newly created equivalence class has
the same inout & l-value requirements. This patch improves the
situation by disallowing contraction of the edges related to parameter
binding constraint where left-hand side has `inout` attribute set.
Such guarantees that parameter can get `inout` type assigned when
argument gets `l-value` type.
Resolves: rdar://problem/33429010
Pushes __consuming through the frontend and extends existing
attribute-based diagnsotics to cover it. Unlike `nonmutating`,
__consuming is allowed in class methods, though it makes little
sense to put it there.
1) Move the "both" check up and don't prematurely return because there
may be more errors.
2) Remove fix-it when both attributes exist. We simply don't know which
attribute the programmer wants to keep.
Using the attribute in this position is a relic from the Swift 2
days, and fixing it required letting invalid code fall through to
Sema instead of being diagnosed in Parse proper. Treat 'var'
in this position like 'let' by simply offering to remove it
instead of extracting it into a separate variable.
- Subscripts parameter lists may not contain inout arguments, but we
were rejecting this at the call site. Teach the type checker to reject
them during type resolution instead.
- We assumed a syntactic check for inout/var parameters would suffice
given that a parameter unified to an InoutType. However, closures
passed to function parameters with inout parameters in their parameter
lists can also cause this case to appear, and we would emit a
SourceLoc-less diagnostic. Instead, do not attempt this recovery path
if the user did not actually write ‘var’ or ‘inout’ on the parameter
type.
`1 { }` was parsed as a call expression with a trailing closure. This made the diagnostics for `var x = 1 { get { ... } }` extremely bad. Resolves SR-3671.
If we found any error in a list, in most cases, we cannot expect that the
following tokens could construct a valid element. Skip them, instead of trying
to parse them as the next element. This significally reduces bogus diagnostics.
Bailout if seeing tok::eof or token that can never start a element, after
parsing an element. This silences superfluous "expected ',' separator" error,
or misleading expected declaration error. What we should emit is
"expected ')' in expression list, or "expected '}' in struct".
Previously, we would skip validating the type (and checking var/inout)
on parameters that didn't have an explicit type. Instead, teach
validateParameterType how to handle an elided type.
We previously said:
x.method = 1 // error: cannot assign to property: 'x' is immutable
we now say:
error: cannot assign to property: 'method' is a method
