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.
We haven't quite got the semantics we want implemented
for `discard` aka `_forget` statements. Allowing people
to use `_forget` in noncopyable types that have stored
properties that require destruction will not let us
implement it the way we'd like in the future without
source break. But, if the type only has "trivial" stored
properties with a no-op destruction, like `Int`, then we
can still provide utility for users like FileDescriptor
who just want to disable the deinit and have nothing
fancy stored in the type itself.
rdar://108877261
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
When `-unavailable-decl-optimization=stub` is specified, insert a call to
`_diagnoseUnavailableCodeReached()` at the beginning of the function to cause
it to trap if executed at run time.
Part of rdar://107388493
There is a strong desire for "no-implicit-copy" semantics to be
applied to Copyable values marked with the newer `borrowing` and
`consuming` ownership specifiers. If we lock ourselves into what
SE-390 specifies now for Copyable types in the implementation, then
we'll have to introduce a source break when we want such values to
have the desired semantics.
Before there's wider adoption, I'm making it an error to use those
newer names. If for some reason this is enabling a critical
optimization for your use case, please use the old names instead:
- `__owned` for `consuming` parameters
- `__consuming` for `consuming` methods
- `__shared` for `borrowing` parameters
NOTE: the older names have their ownership attribute mangled into
the name of the function itself, so there's a possibility of ABI
breaks in the future if you move from the old name to the new one.
There is some consideration being made to allow for a migration to
the new names in the future without breaking ABI, so do reach out if
this is an issue for you.
resolves rdar://108538971
Does not fix the fix-it. The current fix it will be left as a stop-gap solution and we can hopefully update this fix it in the near future to actually plop in a for loop (too much work for this PR though).
Diagnose situation when a single argument to tuple type is passed to
a value pack expansion parameter that expects distinct N elements:
```swift
struct S<each T> {
func test(x: Int, _: repeat each T) {}
}
S<Int, String>().test(x: 42, (2, "b"))
```
This could cause us to double up on the same note
for nested macro expansions, as we'd generate the
note, then when recursing back through the function
we'd compute the same note again. Also remove the
seemingly unused `lastBufferID` param.
We need to teach code completion how to invoke the type checker for attached macro attributes. After that, everything started working.
rdar://105232015
We parse `~Copyable` in an inheritance clause of enum and
struct decls as a synonym for the `@_moveOnly` attribute
being added to that decl. This completely side-steps the
additional infrastructure for generalized suppressed
conformances in favor of a minimal solution. One benefit of
this minimal solution is that it doesn't risk introducing
any back-compat issues with older compilers or stdlibs.
The trade-off is that we're more committed to supporting
`@_moveOnly` in compiled modules in the future. In fact,
this change does not deprecate `@_moveOnly` in any way.
resolves rdar://106775103
We were not type checking the default argument initializer because `MacroDecl` is not an `AbstractFucntionDecl`. Add `MacroDecl` to the list of nodes we know how to get parameters from.
rdar://108163564
