The underlying type for a typealias can be an unbound generic type,
replace these with the bound generic equivalent. This avoids crashing
when attempting to compute the type relation (in the future we'll
want to open these type parameters for the comparison).
rdar://147789214
Instead of using the `isolated P` syntax, switch to specifying the
global actor type directly, e.g.,
class MyClass: @MainActor MyProto { ... }
No functionality change at this point
Raw identifiers are backtick-delimited identifiers that can contain any
non-identifier character other than the backtick itself, CR, LF, or other
non-printable ASCII code units, and which are also not composed entirely
of operator characters.
Introduction, deprecation, and obsoleteion ranges should only be returned by
the accessors on `SemanticAvailableAttr` when the attribute actually has an
affect on the corresponding kind of availability.
There actually only appears to be a single place where we were
letting interface types into the expected type for a completion,
fix it up to use a contextual type.
For e.g implicit `buildExpression` calls, we have a location that
matches the argument, but we don't want to consider the result
builder type as the container type.
We allow the unqualifed use of the enclosing nominal type in a where
clause, but only when it isn't a nested type, e.g:
```
struct S<T> {
typealias T = T
struct R<U> {
typealias U = U
}
}
extension S where S.T == Int {} // allowed
extension S.R where R.U == Int {} // not allowed
```
Tweak the completion logic such that we don't suggest the type for
the nested case, instead it must be qualified.
Memory unsafety in the iteration part of the for-in loop (i.e., the part
that works on the iterator) can be covered by the "unsafe" effect on
the for..in loop, before the pattern.
These should have been opened already, and the logic in
simplifyConstraint(), matchTypes(), etc is just going to do
undefined things if they end up there, so let's guard
against it happening.
When a function declaration has a body, its source range ends at the
closing curly brace, so it includes the `throws(E)`. However, a
protocol requirement doesn't have a body, and due to an oversight,
getSourceRange() was never updated to include the extra tokens
that appear after `throws` when the function declares a thrown
error type. As a result, unqualified lookup would fail to find a
generic parameter type, if that happened to be the thrown type.
Fixes rdar://problem/143950572.
Introduce an `unsafe` expression akin to `try` and `await` that notes
that there are unsafe constructs in the expression to the right-hand
side. Extend the effects checker to also check for unsafety along with
throwing and async operations. This will result in diagnostics like
the following:
10 | func sum() -> Int {
11 | withUnsafeBufferPointer { buffer in
12 | let value = buffer[0]
| | `- note: reference to unsafe subscript 'subscript(_:)'
| |- warning: expression uses unsafe constructs but is not marked with 'unsafe'
| `- note: reference to parameter 'buffer' involves unsafe type 'UnsafeBufferPointer<Int>'
13 | tryWithP(X())
14 | return fastAdd(buffer.baseAddress, buffer.count)
These will come with a Fix-It that inserts `unsafe` into the proper
place. There's also a warning that appears when `unsafe` doesn't cover
any unsafe code, making it easier to clean up extraneous `unsafe`.
This approach requires that `@unsafe` be present on any declaration
that involves unsafe constructs within its signature. Outside of the
signature, the `unsafe` expression is used to identify unsafe code.
