This is an archive of the discontinued LLVM Phabricator instance.

[Sema] Tweak merging of availability attributes
ClosedPublic

Authored by aaron.ballman on Apr 5 2023, 2:32 PM.

Details

Summary

Two calls to mergeAvailabilityAttr dropped the original
AttributeCommonInfo and created a new one from just the range.
This new attribute would have a 0 kind (rather than AT_Availability)
and a 0 syntax (GNU). I don't have any proof that this makes a
difference in practice.

Noticed while doing some changes to the attribute handling.

Diff Detail

Event Timeline

rsandifo-arm created this revision.Apr 5 2023, 2:32 PM
Herald added a project: Restricted Project. · View Herald Transcript
rsandifo-arm requested review of this revision.Apr 5 2023, 2:32 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 5 2023, 2:32 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript

I think the change is probably fine, but can you add an AST-dump test for this one?

Add AST dump test

I think the change is probably fine,

Thanks!

but can you add an AST-dump test for this one?

Sure. How does this look?

This test doesn't show a change in behavior. See:

https://godbolt.org/z/vrWM1bTPE

|-FunctionDecl 0x5555dbfa5a20 <<source>:3:1, col:60> col:6 foo 'void (void)'
| |-AvailabilityAttr 0x5555dbfa5ac8 <col:27, col:58> ios 2.0 0 0 "" "" 0
| `-AvailabilityAttr 0x5555dbfa5b80 <col:27, col:58> Implicit maccatalyst 13.1 0 0 "" "" 2
`-FunctionDecl 0x5555dbfa5c80 <line:4:1, col:55> col:6 bar 'void (void)'
  |-AvailabilityAttr 0x5555dbfa5d28 <col:19, col:50> ios 2.0 0 0 "" "" 0
  `-AvailabilityAttr 0x5555dbfa5de0 <col:19, col:50> Implicit maccatalyst 13.1 0 0 "" "" 2

This test doesn't show a change in behavior.

Yeah. Is there a way to force the syntax and spelling fields to be dumped, even for implicit attributes? I was struggling to find one, which is why I wasn't sure this made a difference in practice.

The patch is supposed to be a minor clean-up, since similar calls in surrounding code uses AL rather than AL.getRange(). The reason I originally hit this was that the series I'm working on removes the:

AttributeCommonInfo(SourceRange)
AttributeCommonInfo(SourceLocation)

constructors (but keeps the ability to use FooAttr::CreateImplicit without more than a source range). It might be easier to explain why that seemed a good idea alongside the patches themselves.

The two main uses of these constructors outside tablegen-generated code were the two in this patch and the one in https://reviews.llvm.org/D147657.

This test doesn't show a change in behavior.

Yeah. Is there a way to force the syntax and spelling fields to be dumped, even for implicit attributes? I was struggling to find one, which is why I wasn't sure this made a difference in practice.

The patch is supposed to be a minor clean-up, since similar calls in surrounding code uses AL rather than AL.getRange(). The reason I originally hit this was that the series I'm working on removes the:

AttributeCommonInfo(SourceRange)
AttributeCommonInfo(SourceLocation)

constructors (but keeps the ability to use FooAttr::CreateImplicit without more than a source range). It might be easier to explain why that seemed a good idea alongside the patches themselves.

The two main uses of these constructors outside tablegen-generated code were the two in this patch and the one in https://reviews.llvm.org/D147657.

Ah, hrm... I don't have a really good idea of how to test this now then. Typically you'd have to do manual dump logic for an attribute like this i think? Perhaps @aaron.ballman knows better. I see the value to this, but I guess I want to see if we can capture the change somehow in a test.

I don't think there's a way to test this change, unfortunately. However, I think this exposed a bigger concern, which is that AttributeCommonInfo has some single-argument constructors that are not explicit so that we don't run into this issue again. However, fixing that entails changing clang's tablegen, so I don't think it should block these changes.

I don't think there's a way to test this change, unfortunately. However, I think this exposed a bigger concern, which is that AttributeCommonInfo has some single-argument constructors that are not explicit so that we don't run into this issue again. However, fixing that entails changing clang's tablegen, so I don't think it should block these changes.

I threw together a patch to make the constructors explicit and the only two compile failures I have are with what you're fixing in this patch. If you'd like, I can commandeer this patch and subsume it with the larger refactor. Alternatively, we can land this (I'd drop the test though) and I can rebase on top of your changes. Either is fine by me.

I threw together a patch to make the constructors explicit and the only two compile failures I have are with what you're fixing in this patch. If you'd like, I can commandeer this patch and subsume it with the larger refactor. Alternatively, we can land this (I'd drop the test though) and I can rebase on top of your changes. Either is fine by me.

Yeah, please feel free to commandeer it. My original motivation for doing this was to remove the single-argument constructors rather than keep them. However, I agree that making them explicit in the meantime would ensure forward progress, if what I'm doing in the follow-on patches turns out not to be acceptable.

aaron.ballman commandeered this revision.Apr 10 2023, 4:50 AM
aaron.ballman edited reviewers, added: rsandifo-arm; removed: aaron.ballman.

I threw together a patch to make the constructors explicit and the only two compile failures I have are with what you're fixing in this patch. If you'd like, I can commandeer this patch and subsume it with the larger refactor. Alternatively, we can land this (I'd drop the test though) and I can rebase on top of your changes. Either is fine by me.

Yeah, please feel free to commandeer it. My original motivation for doing this was to remove the single-argument constructors rather than keep them. However, I agree that making them explicit in the meantime would ensure forward progress, if what I'm doing in the follow-on patches turns out not to be acceptable.

Okay, thanks! I think getting rid of these constructors will be a bit of a challenge because of how many implicit attributes are created internally, but at the same time, I would not be sad if they disappeared either.

I'm commandeering this revision and will cite it in the commit message when I land the patch so there's a paper trail explaining how we got to those changes.

This revision was not accepted when it landed; it landed in state Needs Review.Apr 10 2023, 5:29 AM
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.