This is an archive of the discontinued LLVM Phabricator instance.

[clang-tidy] Use globs in HeaderFilter
AbandonedPublic

Authored by carlosgalvezp on Oct 28 2021, 7:37 AM.

Details

Summary

Instead of regex, to allow for negative globs.

Rename HeaderFilterRegex to HeaderFilter,
to keep it consistent.

Fix existing usage of HeaderFilter in the codebase.

Add unit test excluding one directory.

Diff Detail

Event Timeline

carlosgalvezp created this revision.Oct 28 2021, 7:37 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 28 2021, 7:37 AM
carlosgalvezp requested review of this revision.Oct 28 2021, 7:37 AM

Not in favor of general directions like this.
Does it not break the existing uses (existing .clang-tidy's e.g.)

Fixed formatting of release notes

Not in favor of general directions like this.
Does it not break the existing uses (existing .clang-tidy's e.g.)

Yep, it's a breaking change. The purpose of this patch is mostly to show how it would look like and see if that would be the desired result. There's 2 aspects of it:

  • Rename of HeaderFilterRegex to HeaderFilter, to be consistent with --header-filter. If this is too much breakage, I'm OK with reverting.
  • Replace regex with globs. Won't break the use of .*. It will break for the use case of having a parent .clang-tidy with .* and a child .clang-tidy with my_folder/*\.h. I personally always found the current interface confusing as a user. What regex should I write? Should I consider full paths, relative paths, does it matter?

I suppose I can keep the exact same behavior as master, but that will add additional tweaks and complexity to the GlobList class.

Just to clarify, this patch is the solution proposed by @alexfh here: https://reviews.llvm.org/D34654#3022728

lebedev.ri requested changes to this revision.Oct 28 2021, 10:45 AM

As long as this blankedly breaks/regresses existing configs it's a non-starter i think.

This revision now requires changes to proceed.Oct 28 2021, 10:45 AM

As long as this blankedly breaks/regresses existing configs it's a non-starter i think.

I see, thanks for the input!

I'm curious if there are any deprecation mechanisms for clang-tidy? Or can it only be updated in a backwards-compatible way? As seen in the other referenced patch, the backwards-compatible solution is to add yet another configurable parameter - ExcludedHeaderFilterRegex, which only contributes to more user confusion. Or keep calling the parameter HeaderFilterRegex and switch the implementation to something that is not a regex - even more confusion to the users.

Personally I think it would be good to have such mechanisms to be able to improve on existing design (not just add more functionality). It's impossible to predict the future so decisions that made total sense in the past might need to be revised later to adapt to user needs.

Assuming this is the change we want,
i would imagine the viable enablement path is to introduce some option "filters are regexes and not globs",
that defaults to false, and use it. Then some time later (2 releases?), flip the default and remove said option.
My main concern is that it should be possible to use the same config with clang-tidy from both trunk and last release.

Makes total sense, thanks for the suggestion!

I'll wait for more reviewers to see if this behavior is what we want at all. If so I can revert the breaking changes and introduce that option.

So after some thoughts, I came up with the following plan:

  • This patch adds: HeaderFilter, HeaderFilterMode. HeaderFilter is intended to replace HeaderFilterRegex and we inform that HeaderFilterRegex is deprecated and will be removed in 2 releases. However during the transition period, both HeaderFilter and HeaderFilterRegex are accepted. HeaderFilterMode can take values: regex (default) or glob, and describes the behavior of HeaderFilter or HeaderFilterRegex. This allows people to use globs, while not breaking existing functionality.
  • After 2 releases, we remove HeaderFilterRegex and set HeaderFilterMode as default to glob. We communicate that HeaderFilterMode is deprecated and will be removed in 2 releases.
  • After (another) 2 releases, we remove HeaderFilterMode. The result is then what this patch looks like it is right now. Do we need to wait 2 more releases to remove HeaderFilterMode or can we do it already in the above step?

Does that sound good? Looking forward to your feedback.

carlosgalvezp abandoned this revision.Jan 25 2022, 9:41 AM