The old TypeAttributes reprsentation wasn't too bad for a small number of
simple attributes. Unfortunately, the number of attributes has grown over
the years by quite a bit, which makes TypeAttributes fairly bulky even at
just a single SourceLoc per attribute. The bigger problem is that we want
to carry more information than that on some of these attributes, which is
all super ad hoc and awkward. And given that we want to do some things
for each attribute we see, like diagnosing unapplied attributes, the linear
data structure does require a fair amount of extra work.
I switched around the checking logic quite a bit in order to try to fit in
with the new representation better. The most significant change here is the
change to how we handle implicit noescape, where now we're passing the
escaping attribute's presence down in the context instead of resetting the
context anytime we see any attributes at all. This should be cleaner overall.
The source range changes around some of the @escaping checking is really a
sort of bugfix --- the existing code was really jumping from the @ sign
all the way past the autoclosure keyword in a way that I'm not sure always
works and is definitely a little unintentional-feeling.
I tried to make the parser logic more consistent around recognizing these
parameter specifiers; it seems better now, at least.
It's not clear that its worth keeping this as a
base class for SerializedAbstractClosure and
SerializedTopLevelCodeDecl, most clients are
interested in the concrete kinds, not only whether
the context is serialized.
The `NameMatcher` implemented in swift-syntax as slightly different semantics because it consideres `(callable.|callAsFunction)(x: 78)` as a reference to `callAsFunction` instead of a call with argument labels `(x: 78)`, which means that one test needs to be updated.
Refactor `addSyntacticRenameRanges`, adding comments to make it easier to follow and remove its dependency on the `IsFunctionLike` parameter in `RenameLoc`.
https://github.com/apple/swift/pull/70174 change swift-refactor and sourcekitd to not use `NameMatcher` from swift-syntax but it did not remove the link dependency from swiftRefactoring on `swiftIDEUtilsBridging` if `SWIFT_BUILD_SWIFT_SYNTAX` is false. Do so now.
This allows building sourcekitd and swift-refactor with `SWIFT_BUILD_SWIFT_SYNTAX=NO`. In these builds, the `relatedidents` and `find-syntactic-rename-ranges` requests will always return an error.
Function body macros allow one to introduce a function body for a
particular function, either providing a body for a function that
doesn't have one, or wholesale replacing the body of a function that
was written with a new one.
With the local refactoring being removed, all production refactoring paths return a set of ranges to rename and don’t apply edits to the file. Thus, the `syntactic-rename` action also doesn’t make sense anymore.
We can’t represent the parent node when rewriting `NameMatcher` using swift-syntax. Replace it by two boolean fields `IsComment` and `IsInStringLiteral` that can be bridged.
We should (and do) have one new name for the entire rename operation, not a separate new name for different positions at which the renamed symbol occurs.
