A bug was preventing you from writing `discard self`
in a consuming method of a generic noncopyable type.
The main cause was the `isPureMoveOnly` ignored
unbound generic types, claiming none of them are
noncopyable. Then I also needed to pass the contextual
type with the vars bound to the type checker.
rdar://108975216
You can overload a function based on its `async`-ness, and
resolution is carried out based on async-ness of calling
context.
But during protocol conformance checking, for an `async`
requirement we were accidentally choosing the non-`async
overload instead of the `async` one. The `async` one is
the choice people would expect, since the `async` requirement
is in essence the "context" that forwards to the underlying
witness. This intended behavior is also inferred from:
https://github.com/apple/swift/pull/40088
The problem boiled down to a bad check when categorizing the
witness matches prior to ranking them.
Resolves rdar://109135488 / https://github.com/apple/swift/issues/60318
* Parse `#<identifier>` attribute list as a `MacroExpansionDecl`
regardless of the position
* Diagnose whitespaces between `#` and the macro name.
* Correctly attach attributes to `MacroExpansionDecl`
* Fix `OrigDeclAttributes` to handle modifiers (use `getLocation()`
instead of `AtLoc`.)
Type checking is a TODO
rdar://107386648
Don't attempt to wrap `Any` into a single-element tuple to match
against a tuple with pack expansions, this conversion would be
handled by existential promotion if it's allowed, otherwise it
would produce an error.
Resolves: rdar://109160060
SE-390 concluded with choosing the keyword discard rather than forget for
the statement that disables the deinit of a noncopyable type. This commit
adds parsing support for `discard self` and adds a deprecation warning for
`_forget self`.
rdar://108859077
Failure of an argument to AnyHashable parameter to conform to Hashable
protocol should be detected in `simplifyConformsToConstraint` and fixed
there.
Doing so requires impact assessment adjustment because regular conformance
requirements have default impact of 1, this is going to have argument
impact of 2 not avoid clashing with other failures.
Follow up to https://github.com/apple/swift/pull/61481.
There is already a test case exercising this case but there happens to be no
observable difference in the compiler output because `noasync` diagnostics
already gracefully fall back to looking up the diagnostic `SourceLoc` another
way.
Resolves rdar://100883622.
Suggesting the addition of an `@available` attribute on Linux and Windows is
inapprorpriate given that Swift is not ABI stable on those platforms.
Resolves rdar://107387133
Diagnose situations where value pack is referenced without an explicit 'each':
```
func compute<each T>(_: repeat each T) {}
func test<each T>(v: repeat each T) {
repeat compute(v) // should be `repeat compute(each v)`
}
```
[interop][SwiftToCxx] avoid emitting ambiguous C++ overloads and emit unavailable type stubs for top level types that could not be emitted in the C++ section of the generated header
We shouldn't be allocating placeholders for type
variables in the permanent arena, and we should be
caching them such that equality works.
To achieve this, we need to introduce a new
"solver allocated" type property. This is required
because we don't want to mark placeholder types
with type variable originators as themselves having
type variables, as it's not part of their structural
type. Also update ErrorType to use this bit, though
I don't believe we currently create ErrorTypes
with type variable originators.
According to SE-377:
consuming cannot be applied to parameters of nonescaping closure type, which by their nature are always borrowed:
// ERROR: cannot `consume` a nonescaping closure
func foo(f: consuming () -> ()) {
}
This commit implements the error message.
rdar://108388132
We can't assume that we will always find a viable witness for a protocol
requirement when typechecking a `.swiftinterface` file. The assert that assumed
there would be a match could fail when building a broken interface or building
a valid interface with a broken SDK, causing crashes instead of emitting
diagnostics.
Resolves rdar://108688535
If we don't split up the tuple into individual constraints,
we end up spending more time querying whether a tuple is
Copyable in `lookupConformance`, because it will naively
check the types of all elements of the tuple recursively
with `lookupConformance`.
This is inefficient because if we know some of the elements
of the tuple are fixed types, we don't need to keep checking
those again. For example, if we have `($T, Int, $U)`, and
then try a binding for `$T`, we might ask again if the whole
tuple conforms. Leading to `lookupConformance` to check
whether `Int` (and all other elements of the tuple) conforms
to Copyable, when we either already know that, or can't
answer it yet because it's still a type variable.
By splitting up a Copyable constraint on a tuple into
invidivual constraints on each of its type elements,
we can avoid this redundant work by `lookupConformance`.
While today we could short-cut this even further to say
that _all_ tuples are Copyable, since we emit an error if
a noncopyable type appears in one, that won't be true in
the near future. This is the nicer solution we'll want to
keep around long-term.
After discussing this with Pavel, we don't think there's a
good way to add a regression test for this, because the
performance issue primarily comes up in specific example
programs that aren't amenable to scale tests.
resolves rdar://107536402
Previously, the compiler fails to read the result from 'getCapability'
IPC message, it used to just emit a fatalError and crashed.
Instead, propagate the error status and diagnose it.
rdar://108022847
Rather than eagerly binding them to holes if the
sequence element type ends up being Any, let's
record the CollectionElementContextualMismatch fix,
and then if the patterns end up becoming holes,
skip penalizing them if we know the fix was
recorded. This avoids prematurely turning type
variables for ExprPatterns into holes, which
should be able to get better bindings from the
expression provided. Also this means we'll apply
the logic to non-Any sequence types, which
previously we would give a confusing diagnostic
to.
We no longer need to check for a type variable
here, it no longer regresses diagnostics. Also,
while here, let's bump the impact for an
Any/AnyObject missing conformance, as that's
unlikely going to be helpful since they cannot
conform to protocols even if the user wanted them
to.
- Simplify the fix locator when looking for a
fix already present in a pattern match, this
avoids us emitting both a diagnostic for the
argument conversion, and for a conformance failure.
- Include tuples in the diagnostic logic where
we emit a generic "operator cannot be applied"
diagnostic, as a conformance diagnostic is
unlikely to be helpful in that case.
