[APINotes] Preserve attributes from inactive versions. #53
Conversation
|
Also cherry-pick a fix that accidentally went into 'stable' instead of upstream-with-swift. @hughbe, can you cherry-pick that to swift-3.1-branch too? |
jrose-apple
force-pushed
the
SwiftVersionedAttr
branch
from
071cb40 to
76b091f
Compare
|
Factored that out into #54. |
DougGregor
left a comment
DougGregor
left a comment
There was a problem hiding this comment.
This is simpler than I'd expected, which is fantastic. LGTM!
|
@jrose-apple I'm fairly sure these changes went into swift-3.1-branch... see: #45 Also, the apple/swift-3.1-branch seems up to date with my changes |
|
Ah, strange. I guess I checked the wrong thing with git. We did miss upstream-with-swift, though—oops! |
jrose-apple
force-pushed
the
SwiftVersionedAttr
branch
3 times, most recently
from
2347d96 to
037afa9
Compare
jrose-apple
force-pushed
the
SwiftVersionedAttr
branch
from
037afa9 to
5be8c87
Compare
...by wrapping them in another (new) attribute, SwiftVersionedAttr, or by noting their deletion in a SwiftVersionedRemovalAttr. This doesn't support other kinds of changes that can be made via API notes, such as nullability or wholesale type changes, but it's a place to start, and possibly sufficient for our goals. Part of rdar://problem/28618121.
jrose-apple
force-pushed
the
SwiftVersionedAttr
branch
from
5be8c87 to
e48aabf
Compare
| *existing); | ||
|
|
||
| D->getAttrs().erase(existing.getCurrent()); | ||
| D->addAttr(versioned); |
There was a problem hiding this comment.
@DougGregor: This part is new since last time. Do you see any issues with this version?
There was a problem hiding this comment.
I guess an empty VersionTuple is code for "latest version". That seems fine to me, and this looks like the right way to maintain the attribute that was present in the source code without the rest of Clang (or other tools that only care about the API-note-adjusted view) seeing it.
|
@fredriss, what do you think about this? This particular PR is going to 'upstream-with-swift', but I'd like to land the corresponding Swift changes soon after. Is it worth cherry-picking to Clang's 'swift-3.1-branch', or should I limit it to the 'stable' branch and let it get picked up in the next Clang rebranch (presumably for Swift 4)? |
| *existing); | ||
|
|
||
| D->getAttrs().erase(existing.getCurrent()); | ||
| D->addAttr(versioned); |
There was a problem hiding this comment.
I guess an empty VersionTuple is code for "latest version". That seems fine to me, and this looks like the right way to maintain the attribute that was present in the source code without the rest of Clang (or other tools that only care about the API-note-adjusted view) seeing it.
...by wrapping them in another (new) attribute, SwiftVersionedAttr, or by noting their deletion in a SwiftVersionedRemovalAttr. This doesn't support other kinds of changes that can be made via API notes, such as nullability or wholesale type changes, but it's a place to start, and possibly sufficient for our goals. Part of rdar://problem/28618121.
3 participants
...by wrapping them in another (new) attribute, SwiftVersionedAttr. This can track both attributes that would be added and those that would be removed.
This doesn't support other kinds of changes that can be made via API notes, such as nullability or wholesale type changes, but it's a place to start, and possibly sufficient for our goals.
Part of rdar://problem/28618121.