Updates the message to use the type or ValueDecl instead of this on previous 'Found this candidate' messages
Note: doees not yet change all test cases so more tests are failing
Improve Diagnostic message on overload ambiguitiy
Remove messages that say 'found this candidate' in favour of providing the type for the candidate to aid in selection when the candidates are presented in a dialogue window.
Fix more tests
The problem detection logic currently expects `generic argument #<N>`
location to always be associated with two generic types, but that
is not always the case, this locator element is sometimes used for
i.e. optional object types and pointer `Pointee` type when types
appear in argument positions. This needs to be handled specifically.
Resolves: rdar://82971941
We can't unconditionally skip the conformance check if the type contains type
parameters; instead, we only want to skip it in the structural resolution
stage. In interface resolution stage, we proceed by mapping the type into
the generic environment first.
Use the `%target-swift-5.1-abi-triple` substitution to compile the tests for
deployment to the minimum OS versions required for use of _Concurrency APIs,
instead of disabling availability checking.
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
Member operators of concrete nominal types must declare at least
one parameter with that type, like
```
struct S {
static func +(lhs: S, rhs: Int) -> S {}
}
```
For protocol member operators, we would look for a parameter of type
`Self`, or an existential type `any P`. While the latter was
consistent with the concrete nominal type case, it was actually
wrong because then the resulting interface type does not give the
type checker any way to bind the `Self` type parameter.
There were two existing test cases that now produce errors, which I
believe is now correct. While this is technically a source break,
because these bogus operators seemingly cannot be witnessed or called,
such a protocol probably had no conforming types.
Fixes https://github.com/apple/swift/issues/73201.
We now compute captures of functions and default arguments
lazily, instead of as a side effect of primary file checking.
Captures of closures are computed as part of the enclosing
context, not lazily, because the type checking of a single
closure body is not lazy.
This fixes a specific issue with the `-experimental-skip-*` flags,
where functions declared after a top-level `guard` statement are
considered to have local captures, but nothing was forcing these
captures to be computed.
Fixes rdar://problem/125981663.
This addresses a source compatibility issue with the introduction of
typed throws into the standard library.
Fixes https://github.com/apple/swift/issues/70970 / rdar://121149479.
We accepted unnamed closure parameters if the type was an array literal, dictionary literal, tuple or function (because the `[` or `(` starting the type was sufficient to disambiguate the type from the parameter’s name). This was never an accepted syntax and we should disallow it.
Rethrows checking is based on the interface type of the parameter, with
substitutions applied only when we need to figure out the thrown error
type. Fixes a regression caused by my attempt at dealing with parameter
packs in rethrows functions.
Effects checking for rethrowing functions was using unsubstituted
interface types for the parameter list. When a rethrows function has
parameter pack arguments, the interface type may have a different
number of parameters from the resulting argument list, causing the
effects checking to bail out early.
This has been wrong since the introduction of parameter packs, but
recent refactoring of effects checking ended up promoting this bug to
a compiler crash. Fix the bug, and make sure we don't crash if the
effects checker hits an issue here.
Fixes rdar://116740385.
When substitution into a function type with `throws(E)` produces either
`throws(any Error)` or `throws(Never)`, adjust the resulting function
type to the equivalent `throws` or non-throwing.
Allow a rethrows function to call a typed-throws function that has a
specific form that looks like it only rethrows, i.e., it is generic
over its thrown error type and carries the thrown error type from its
closure parameters to itself. This is a compatibility carve-out to
allow existing rethrows functions to move to typed throws without
breaking their clients.
Note that it is possible to write a sneaky function that passes this
check but throws when it shouldn't, so this compatibility carve-out is
phased out with the upcoming feature FullTypedThrows.
Rethrows functions only throw when their closure arguments throw.
However, they are free to translate the errors thrown from the closure
arguments in any way they want, and are therefore untyped.
Ensure that calls to `rethrows` functions are always treated as
throwing `any Error` if their closure arguments throw anything.
When providing a key-path literal for a parameter of function type
where that function type has a generic parameter for its thrown error
type, infer `Never` for the generic argument because key paths don't
throw.
Thanks to @xedin for realizing that this would be an issue.
Allow one to throw a type that is convertible to `any Error` even if it
doesn't conform to the `Error` protocol, e.g., an existential type like
`any Codable & Error`.
The type that occurs as the thrown error type must conform to the
`Error` protocol. Infer this conformance when the type is a type
parameter in the signature of a function.
Lift the subtyping check for thrown error types out of the constraint
solver, so we can re-use it elsewhere.
There is a minor diagnostic change, from one that is actively
misleading (it shows a legitimate conversion that's wrong) to one that
is correct, which comes from us not treating "dropping throws" as a
legitimate way to handle equality of function types.
Teach the constraint solver about the subtyping rule that permits
converting one function type to another when the effective thrown error
type of one is a subtype of the effective thrown error type of the
other, using `any Error` for untyped throws and `Never` for
non-throwing.
With minor other fixes, this allows us to use typed throws for generic
functions that carry a typed error from their arguments through to
themselves, which is in effect a typed `rethrows`:
```swift
func mapArray<T, U, E: Error>(_ array: [T], body: (T) throws(E) -> U)
throws(E) -> [U] {
var resultArray: [U] = .init()
for value in array {
resultArray.append(try body(value))
}
return resultArray
}
```
Add the thrown type into the AST representation of function types,
mapping from function type representations and declarations into the
appropriate thrown type. Add tests for serialization, printing, and
basic equivalence of function types that have thrown errors.
This commit changes fixit messages from a question/suggestion to an
imperative message for protocol conformances and switch-case. Addresses
https://github.com/apple/swift/issues/67510.
The restriction that default arguments be disallowed from accessing
`@usableFromInline` decls is overbearing for library developers who need to
write non-trivial code to compute a default value, since it forces them to
either write a verbose closure inline in the function signature or expose a
`public` helper function which unnecessarily expands API surface. A
`@usableFromInline` function a more reasonable way to encapsulate a verbose
default value computation.
This reverses the semantic changes included in https://github.com/apple/swift/pull/15666.
Resolves rdar://112093794.
And adjust contextual parameter modifier parsing in general to be more
properly contextual, so we don't have to reserve `__shared` or `__owned`,
or their successor spellings, as argument labels anymore.
Introduce a `getTopmostDeclarationDeclContext`
utility to ensure we ensure we don't visit a
`nullptr` DeclContext for an erroneous module
under `-experimental-allow-module-with-compiler-errors`.
Additionally, tweak the insertion location such
that we insert at the start of any attributes
present.
rdar://97267326
Instead of failing constraint generation by returning `nullptr` for an `ErrorExpr` or returning a null type when a type fails to be resolved, return a fresh type variable. This allows the constraint solver to continue further and produce more meaningful diagnostics.
Most importantly, it allows us to produce a solution where previously constraint generation for a syntactic element had failed, which is required to type check multi-statement closures in result builders inside the constraint system.
Tweaked usable check:
* Local type/func decls are usable even before declaration
* Outer nominal Instance member are not usable
* Type context cannot close over values in outer type contexts
Added shadowing rule by the base name:
* Type members don't shadow each other as long as they are in the
same type context.
* Local values shadow everything in outer scope
* Except that 'func' decl doesn't shadow 'var' decl if they are in the
same scope.
rdar://86285396
