I missed this in my previous patch that moved extension binding until
after we've mutated the AST for IDE inspection, this ad-hoc extension
binding logic is no longer necessary.
This generalization enables curried functions with generic parameters coming from the initial declaration to be printed with the archetype's upperbound rather than '_' unresolved type.
As an added benefit, T.self and T.Type for generic parameters now get shown as the upperbound of the generic parameter provided
We set an original expression on ErrorExpr for cases where we have
something semantically invalid that doesn't fit into the AST, but is
still something that the user has explicitly written. For example
this is how we represent unresolved dots without member names (`x.`).
We still want to type-check the underlying expression though since
it can provide useful diagnostics and allows semantic functionality
such as completion and cursor info to work correctly.
rdar://130771574
[IDE] Move primitive completion function label into CodeCompletionStringBuilder
[IDE] NFC: Remove unneeded string builder methods on CodeCompletionResultBuilder
[IDE] Move addValueBaseName into CodeCompletionStringBuilder
[IDE] Make CodeCompletionResultBuilder a CodeCompletionStringBuilder
[IDE] Explicitly pass DeclContext in CodeCompletionStringBuilder
[IDE] Reduce includes in CodeCompletionStringBuilder.h
This is unnecessary since the local conformances for a protocol
can only contain self-conformances, which we don't want to visit
anyway. This can just be a straightforward loop over the local
conformances.
The extension may have requirements stating new conformance requirements
that aren't present in the underlying substitution map for the
conforming type.
rdar://152164768
Switch to using `hasAppliedSelf` to match the constraint system, and
flip the check to more accurately describe what we're checking which
is really "is application fully applied"?
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
