[all-commits] [llvm/llvm-project] d28763: Replace 'AllowExplicit' bool with an enum. No func...

Richard Smith via All-commits all-commits at lists.llvm.org
Thu Jan 30 17:17:11 PST 2020


  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: d28763cad06e66651e1936756d3e28126b055abf
      https://github.com/llvm/llvm-project/commit/d28763cad06e66651e1936756d3e28126b055abf
  Author: Richard Smith <richard at metafoo.co.uk>
  Date:   2020-01-30 (Thu, 30 Jan 2020)

  Changed paths:
    M clang/include/clang/Sema/Sema.h
    M clang/lib/Sema/SemaExpr.cpp
    M clang/lib/Sema/SemaInit.cpp
    M clang/lib/Sema/SemaOpenMP.cpp
    M clang/lib/Sema/SemaOverload.cpp

  Log Message:
  -----------
  Replace 'AllowExplicit' bool with an enum. No functionality change.

In passing, split it up into three values (no explicit functions /
explicit conversion functions only / any explicit functions) in
preparation for using that in a future change.


  Commit: 1f3f8c369a5067a132c871f33a955a7feaea8534
      https://github.com/llvm/llvm-project/commit/1f3f8c369a5067a132c871f33a955a7feaea8534
  Author: Richard Smith <richard at metafoo.co.uk>
  Date:   2020-01-30 (Thu, 30 Jan 2020)

  Changed paths:
    M clang/lib/Sema/SemaDeclCXX.cpp
    M clang/test/CXX/class/class.compare/class.compare.default/p3.cpp

  Log Message:
  -----------
  PR44721: Don't consider overloaded operators for built-in comparisons
when building a defaulted comparison.

As a convenient way of asking whether `x @ y` is valid and building it,
we previouly always performed overload resolution and built an
overloaded expression, which would both end up picking a builtin
operator candidate when given a non-overloadable type. But that's not
quite right, because it can result in our finding a user-declared
operator overload, which we should never do when applying operators
non-overloadable types.

Handle this more correctly: skip overload resolution when building
`x @ y` if the operands are not overloadable. But still perform overload
resolution (considering only builtin candidates) when checking validity,
as we don't have any other good way to ask whether a binary operator
expression would be valid.


Compare: https://github.com/llvm/llvm-project/compare/2d3174c4df6b...1f3f8c369a50


More information about the All-commits mailing list