Details
- Reviewers
njames93 aaron.ballman lebedev.ri
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
The llvm::StringRef::split function can take multiple split characters, So it would be best to split on both for the time being but mark cases where , is used as deprecated. This way we keep the options in line with other clang-tidy checks but keep some backwards compatibility but in future change it to just using ;
Preserve backwards compatibility of ',' as a delimiter (for now).
The llvm::StringRef::split function can take multiple split characters,
AFAIU, that's for multi-character delimiters, not multiple delimiters.
Yeah just checked it out my bad.
clang-tools-extra/clang-tidy/utils/FileExtensionsUtils.cpp | ||
---|---|---|
40 | if (AllFileExtensions.contains(Delimeter)) { |
LGTM with a minor nit.
clang-tools-extra/clang-tidy/utils/FileExtensionsUtils.cpp | ||
---|---|---|
39–45 | Can drop the top-level const here. |
FWIW i'm personally still unconvinced this is fixing a real problem
clang-tools-extra/clang-tidy/utils/FileExtensionsUtils.cpp | ||
---|---|---|
42–44 | Can this spam be avoided? |
clang-tools-extra/clang-tidy/utils/FileExtensionsUtils.cpp | ||
---|---|---|
42–44 | That seems like a good idea. Would take a good many versions before the comma could safely be removed without fallout so people would get the warning too often and not be able to change it |
clang-tools-extra/clang-tidy/utils/FileExtensionsUtils.cpp | ||
---|---|---|
42–44 | FWIW, I was on the fence about this being a chatty diagnostic as well. I eventually figured that it was fine because it's going to stderr and it definitely gets the job done of letting people know. Most folks don't read release notes, so putting the information there is a good idea, but not really sufficient for warning about deprecation. I don't think we have a better solution at hand and the point @lebedev.ri brings up about older versions is a valid one, so I agree, let's move this into the release notes rather than spamming the command line. |
- Don't spam the deprecation message. Move that to release notes.
- Drop unnecessary const.
LGTM
clang-tools-extra/clang-tidy/utils/FileExtensionsUtils.h | ||
---|---|---|
44–46 | Doesn't belong in this patch, but this function should be changed in a follow up to return an Optional<FileExtensionSet>. |
clang-tools-extra/clang-tidy/utils/FileExtensionsUtils.h | ||
---|---|---|
44–46 | Looking at the uses, I'm not convinced this would be better in this specific case. Compare: if (Optional<FileExtensionSet> HFE = parseFileExtensions(Extensions, Delimiters)) { HeaderFileExtensions = *HFE; } else { errs() << "Invalid extensions: " << Extensions; } With the status quo: if (!parseFileExtensions(Extensions, HeaderFileExtensions, Delimiters)) { errs() << "Invalid extensions: " << Extensions; } Optional's explicit operator bool is great for when you want to guard on the presence of the thing, but not so great when you want to check for it not being there. I feel like we'd need some new utility to go with Optional to make this nice: if (not(HeaderFileExtensions) = parseFileExtensions(Extensions, Delimiters)) { errs() << "Invalid extensions: " << Extensions; } |
clang-tools-extra/clang-tidy/utils/FileExtensionsUtils.h | ||
---|---|---|
44–46 | To be honest it should probably be Expected rather than Optional, but that still doesn't help solve the cleanliness issue. |
clang-tools-extra/clang-tidy/utils/FileExtensionsUtils.h | ||
---|---|---|
44–46 | Implementation of the not idea here: |
Doesn't belong in this patch, but this function should be changed in a follow up to return an Optional<FileExtensionSet>.