Page MenuHomePhabricator

[Driver][NFC] Simplify handling of flags in Options.td
ClosedPublic

Authored by ekieri on Apr 4 2022, 1:10 PM.

Details

Summary

We aim at improving the readability and maintainability of Options.td,
and in particular its handling of 'Flags', by

  • limiting the extent of 'let Flags = [...] in {'s, and
  • adding closing comments to matching '}'s.
  • being more consistent about empty lines around 'let Flags' and '}'.

More concretely,

  • we do not let a 'let Flags' span across several headline comments. When all 'def's in two consecutive headlines share the same flags, we stil close and start a new 'let Flags' at the intermediate headline.
  • when a 'let Flags' span just one or two 'def's, set 'Flags' within the 'def's instead.
  • we remove nested 'let Flags'.

Note that nested 'let Flags' can be quite confusing, especially when
the outer was started long before the inner. Moving a 'def' out of the
inner 'let Flags' and setting 'Flags' within the 'def' will not have the
intended effect, as those flags will be overridden by the outer
'let Flags'.

Diff Detail

Event Timeline

ekieri created this revision.Apr 4 2022, 1:10 PM
Herald added a project: Restricted Project. · View Herald Transcript
ekieri requested review of this revision.Apr 4 2022, 1:10 PM
Herald added a project: Restricted Project. · View Herald Transcript
ekieri edited the summary of this revision. (Show Details)Apr 4 2022, 1:17 PM

This patch is the result of discussions in https://reviews.llvm.org/D122542

There are probably a developer or two on the clang side that ought to have a say on this. I do not know the community that well, could you please help me with adding the appropriate people?

awarzynski accepted this revision.EditedApr 5 2022, 5:15 AM
awarzynski added a subscriber: jansvoboda11.

Thanks for doing this, Emil!

This is a much appreciated clean-up. On quite a few occasions I got confused with the nested let statements. With this change, everyone should find it easier to identify precisely what flags are effectively set for a particular option.

There are probably a developer or two on the clang side that ought to have a say on this.

I agree that we should try to reach as many reviewers as possible. @jansvoboda11 was kind enough to review some changes for me in the past. I'll also ping Discourse (edit: see https://discourse.llvm.org/t/small-clean-up-in-options-td/61489). But I think that you should go ahead with this even there if there are no other active reviewers :) It's an NFC and a clear improvement compared to what we have now, so fairly safe.

This revision is now accepted and ready to land.Apr 5 2022, 5:15 AM
jansvoboda11 accepted this revision.Apr 5 2022, 7:01 AM

Thank you for working on this!

I you haven't already, I suggest you test this change by dumping all TableGen records in the backend and comparing the before and after. When working on Options.td, I found it quite easy to introduce small differences that don't cause test failures on my machine, but may become observable on other configurations.

LGTM!

hans accepted this revision.Apr 5 2022, 7:32 AM
hans added a subscriber: hans.

Looks reasonable to me.

I worry that the closing comments on '}'s might rot since there's no tooling to maintain them though.

Thank you all for the support!

@jansvoboda11 , yes, I did that, and will do it again before pushing.

@hans , thanks, that is a valid concern. I was asked to add closing comments on an earlier patch though, and I find them particularly useful (when accurate...) in this file, which does not use indentation very much. But I am happy to make the change if you insist, and welcome others to fill in with their opinions.

I worry that the closing comments on '}'s might rot since there's no tooling to maintain them though.

I share your concern. However, from my experience these let statements rarely change (i.e. this file is fairly stable), so the risk is not that high. Personally, I find them very helpful.

bjope added a subscriber: bjope.Apr 6 2022, 11:21 PM
hans added a comment.Apr 7 2022, 12:48 AM

@hans , thanks, that is a valid concern. I was asked to add closing comments on an earlier patch though, and I find them particularly useful (when accurate...) in this file, which does not use indentation very much. But I am happy to make the change if you insist, and welcome others to fill in with their opinions.

I also find them useful, so having them seems like a plus.

This revision was automatically updated to reflect the committed changes.