NFC *except* that I noticed a bug by inspection where we suppress
`@escaping` when print enum element types. Since this affects
recursive positions, we end up suppressing `@escaping` in places
we shouldn't. This is unlikely to affect much real code, but should
still obviously be fixed.
The new design is a little sketchy in that we're using `const` to
prevent direct use (and allow initialization of `const &` parameters)
but still relying on modification of the actual object. Essentially,
we are treating the `const`-ness of the reference as a promise to leave
the original value in the object after computation rather than a
guarantee of not modifying the object. This is okay --- a temporary
bound to a `const` reference is still a non-`const` object formally
and can be modified without invoking UB --- but makes me a little
uncomfortable.
`getSemanticAttrs` runs a couple queries that we don’t actually need to run to get all the custom attributes, such as getting the actor isolation of the declaration. Running these things can amount to 5%-7% of the index-while-building overhead. Just running `getExpandedAttrs` should be sufficient here.
Most `SemaAnnotator`s don’t actually care about the char source range. Instead, they only care about the start location of the reference, which is also included in `SourceRange`. Computing a `CharSourceRange` from a `SourceRange` is kind of expensive because it needs to start a new lexer.
To avoid this overhead, pass `SourceRange` to `SemaAnnotator::passReference` and related functions and let the clients compute the `CharSourceRange` when needed.
This reduces the overhead of index-while-building by about 10%.
By default (currently) the closure passed to a parameter with `@_inheritActorContext`
would only inherit isolation from `nonisolated`, global actor isolated or actor
context when "self" is captured by the closure. `always` changes this behavior to
always inherit actor isolation from context regardless of whether it's captured
or not.
Previously we could end up in cases where we pick the wrong
DeclContext in `TypeCheckASTNodeAtLocRequest` since we previously
weren't checking source ranges, which could result in skipping the
type-checking of an outer closure. Now that we correctly pick the
DeclContext, we should no longer hit that case, so we should be able
to fall into `getTypeForCompletion` and assert that the solution has
a type. Also while here let's upgrade that assert to a
`CONDITIONAL_ASSERT`.
If a module has the same `public-module-name` as the module being
generated and its import is exported, merge it into the same generated
interface.
Fix various always-imported modules from being printed while here and
update all the tests that checked for them.
Resolves rdar://137887712.
Importing C++ class templates in symbolic mode has proven to be problematic in interaction with other compiler features, and it isn't used widely. This change removes the feature.
rdar://150528798
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.
