Rework the representation and handling of type attributes #71208
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rjmccall
requested review from
kavon,
QuietMisdreavus,
AnthonyLatsis,
hborla,
slavapestov,
xedin,
ahoppen,
bnbarham,
hamishknight,
rintaro,
CodaFi and
DougGregor
as code owners
|
@swift-ci Please test |
keys, especially enumerated keys.
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.
rjmccall
force-pushed
the
type-attributes
branch
from
c2c0c2d to
41cdfb0
Compare
|
@swift-ci Please test |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Introduce a proper
TypeAttributeclass hierarchy.The old
TypeAttributesrepresentation 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 madeTypeAttributesfairly bulky even at just a singleSourceLocper attribute; that's okay as a temporary thing, butTypeAttributeswas being stored as a whole inAttributedTypeRepr. The bigger problem is that we do need to carry more information than just the presence and location of the attribute for 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
@escapingchecking is really a sort of bugfix --- the existing code was really jumping from the@sign all the way past theautoclosurekeyword 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.
Philosophically, there are some things that feel a little incomplete here, but this is a good stopping place.