[all-commits] [llvm/llvm-project] b1bc1d: [clang-tidy] Refactor how NamedDecl are renamed (#...

[Edwin Vane via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: b1bc1dbea6d0423813bb73d625c6eedc040007ed
      https://github.com/llvm/llvm-project/commit/b1bc1dbea6d0423813bb73d625c6eedc040007ed
  Author: Edwin Vane <revane at google.com>
  Date:   2024-05-07 (Tue, 07 May 2024)

  Changed paths:
    M clang-tools-extra/clang-tidy/bugprone/ReservedIdentifierCheck.cpp
    M clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp
    M clang-tools-extra/clang-tidy/utils/RenamerClangTidyCheck.cpp
    M clang-tools-extra/clang-tidy/utils/RenamerClangTidyCheck.h

  Log Message:
  -----------
  [clang-tidy] Refactor how NamedDecl are renamed (#88735)

The handling of renaming failures and multiple usages related to those
failures is currently spread over several functions. Identifying the
failure NamedDecl for a given usage is also duplicated, once when
creating failures and again when identify usages. There are currently
two ways to a failed NamedDecl from a usage: use the canonical decl or
use the overridden method. With new methods about to be added, a cleanup
was in order.

The data flow is simplified as follows:
* The visitor always forwards NamedDecls to addUsage(NamedDecl).
* addUsage(NamedDecl) determines the failed NamedDecl and determines
potential new names based on that failure. Usages are registered using
addUsage(NamingCheckId).
* addUsage(NamingCheckId) is now protected and its single responsibility
is maintaining the integrity of the failure/usage map.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications