The functionality in MultilibSet for creating it is tied to its current
implementation. Putting that code in a separate class is an enabler for
changing the MultilibSet implementation.
Details
- Reviewers
phosek - Commits
- rG850dab0f2537: [NFC] Class for building MultilibSet
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Looks good so far. Some stylistic suggestions.
clang/include/clang/Driver/Multilib.h | ||
---|---|---|
25 | It took a bit of reading to work out what the relationship between Multilib, MultilibVariant, MultilibSet and MultilibVariantBuilder are and how they are expected to be used. IIUC MultilibVariant and MultilibVariantBuilder are used to construct Multilib and MultilibSet, which are expected to be immutable post construction. Will be worth either a comment describing the relation ship or potentially write up the design in the clang docs and reference it from here. | |
40 | Could be worth documenting the requirement for the strings to start with a / or be empty as the constructor implementation in a different file will assert if they aren't? | |
clang/lib/Driver/ToolChains/BareMetal.cpp | ||
32–33 | Worth making this a lambda in findRISCVMultilibs? Purely subjective opinion here as there could be an attempt to limit changes. | |
44–47 | Wondering if we've lost information here by going to auto. We're really making a MultilibVariant here. Perhaps worth renaming makeMultilib to makeMultilibVariant? | |
clang/lib/Driver/ToolChains/Gnu.cpp | ||
1049–1050 | Similar comment to BareMetal, is it worth renaming to makeMultilibVariant | |
1737–1738 | Although I'm not too bothered myself, some people prefer to keep changes in whitespace to a separate NFC patch for the benefit of git annotate. |
Apply improvements suggested by @peter.smith
clang/include/clang/Driver/Multilib.h | ||
---|---|---|
25 | Yeah the naming was not intuitive, a hangover from one of the previous forms of this change. I've changed it so that MultilibBuilder creates Multilib and MultilibSetBuilder creates MultilibSet. That should make the comments less necessary, but I've added those too. | |
clang/lib/Driver/ToolChains/BareMetal.cpp | ||
32–33 |
Indeed. I'd rather leave this in place for that reason. | |
44–47 | I've gone back to declaring the type explicitly and renamed the function to makeMultilibBuilder since MultilibBuilder is the return type now. | |
clang/lib/Driver/ToolChains/Gnu.cpp | ||
1049–1050 | Renamed to makeMultilibBuilder since MultilibBuilder is the return type now. | |
1737–1738 | git-clang-format insists on changing it. A removed line won't show up in git annotate/blame (unless you're doing some extreme reverse-blaming activity, which mostly people don't) so I think it's best to let git-clang-format do its thing. |
clang/include/clang/Driver/Multilib.h | ||
---|---|---|
33–37 | Since this class is intended to be immutable, we should also consider marking all fields as const. This can be done in a future refactoring, but it might be worth leaving a TODO here. | |
79–80 | Since this class is intended to be immutable, and the number of Multilibs is known at construction time, we could use llvm::TrailingObjects instead of std::vector which would be more efficient. This can be done in a future refactoring, but it might be worth leaving a TODO here. | |
99–100 | I don't think we should expose this method to maintain the invariant that MultilibSet is immutable post construction, instead this method should be provided by MultilibSetBuilder. | |
clang/lib/Driver/ToolChains/BareMetal.cpp | ||
32–33 | I'd suggest adding a single argument constructor to MultilibBuilder since this pattern is replicated across different files and so it makes sense to generalize but I agree that we can do that in a follow up change as a cleanup/refactor. |
Replace makeMultilibBuilder() with a MultilibBuilder constructor that initializes all suffixes to the same value.
In the case of AndroidMipsMultilibs it was apparently intended that only the GCC suffix was set, and the other suffixes were left empty. This is now explicit in the code.
Comments about Multilib being "immutable" were overstated so I've now removed them. The intention is merely to remove the requirement to support mutation. The code is simpler when you don't need to keep checking invariants.
clang/include/clang/Driver/Multilib.h | ||
---|---|---|
33–37 | Immutable was overstating it. I won't rule out that there may be a good reason to mutate it in future, but there's no need to actively support mutation now. I removed "immutable" from the comment. | |
79–80 | Immutable was overstating it, and wasn't intended to apply to this class - a later change adds a parse() method which mutates in-place. I'm also sceptical of TODOs ever getting done - there are over 3,000 of them in llvm/lib alone :( | |
99–100 | Immutable was overstating it, and wasn't intended to apply to this class - a later change adds a parse() method which mutates in-place. I did start off by removing push_back() but found it made the class less convenient to use. | |
clang/lib/Driver/ToolChains/BareMetal.cpp | ||
32–33 | I've gone ahead and added the constructor in this patch. |
Thanks for the updates, I'm happy with the changes and don't have any more comments. Happy to give my implicit approval.
clang/include/clang/Driver/MultilibBuilder.h | ||
---|---|---|
118 | Use camelCase for new function names. |
LGTM
clang/include/clang/Driver/MultilibBuilder.h | ||
---|---|---|
118 | These functions were copies from the existing MultilibSet class so I'm fine keeping the original names to reduce the amount of changes. If we decide to change the names, it would ideally be done in a follow up change. |
It took a bit of reading to work out what the relationship between Multilib, MultilibVariant, MultilibSet and MultilibVariantBuilder are and how they are expected to be used.
IIUC MultilibVariant and MultilibVariantBuilder are used to construct Multilib and MultilibSet, which are expected to be immutable post construction.
Will be worth either a comment describing the relation ship or potentially write up the design in the clang docs and reference it from here.