[all-commits] [llvm/llvm-project] 67e229: [clang] use getCommonSugar in an assortment of places

[Matheus Izvekov via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 67e22983115451ef5512ad2813dd337762c52da3
      https://github.com/llvm/llvm-project/commit/67e22983115451ef5512ad2813dd337762c52da3
  Author: Matheus Izvekov <mizvekov at gmail.com>
  Date:   2022-09-16 (Fri, 16 Sep 2022)

  Changed paths:
    M clang-tools-extra/clangd/unittests/tweaks/ExtractVariableTests.cpp
    M clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/narrowing-conversions-ignoreconversionfromtypes-option.cpp
    M clang/lib/CodeGen/CGExprComplex.cpp
    M clang/lib/Sema/SemaExpr.cpp
    M clang/lib/Sema/SemaExprCXX.cpp
    M clang/test/AST/ast-dump-fpfeatures.cpp
    M clang/test/CodeGen/complex-math.c
    M clang/test/CodeGen/compound-assign-overflow.c
    M clang/test/Sema/complex-int.c
    M clang/test/Sema/matrix-type-operators.c
    M clang/test/Sema/nullability.c
    A clang/test/Sema/sugar-common-types.c
    M clang/test/SemaCXX/complex-conversion.cpp
    M clang/test/SemaCXX/matrix-type-operators.cpp
    A clang/test/SemaCXX/sugar-common-types.cpp
    M clang/test/SemaCXX/sugared-auto.cpp
    M clang/test/SemaObjC/format-strings-objc.m
    M compiler-rt/test/ubsan/TestCases/Integer/add-overflow.cpp
    M compiler-rt/test/ubsan/TestCases/Integer/no-recover.cpp
    M compiler-rt/test/ubsan/TestCases/Integer/sub-overflow.cpp
    M compiler-rt/test/ubsan/TestCases/Integer/uadd-overflow.cpp
    M compiler-rt/test/ubsan/TestCases/Integer/umul-overflow.cpp
    M compiler-rt/test/ubsan/TestCases/Integer/usub-overflow.cpp
    M lldb/test/API/commands/expression/rdar42038760/main.c
    M lldb/test/API/commands/expression/rdar44436068/main.c

  Log Message:
  -----------
  [clang] use getCommonSugar in an assortment of places

For this patch, a simple search was performed for patterns where there are
two types (usually an LHS and an RHS) which are structurally the same, and there
is some result type which is resolved as either one of them (typically LHS for
consistency).

We change those cases to resolve as the common sugared type between those two,
utilizing the new infrastructure created for this purpose.

Signed-off-by: Matheus Izvekov <mizvekov at gmail.com>

Differential Revision: https://reviews.llvm.org/D111509