[clang] Correctly compute conversion seq for args to fn with reversed param order (PR #68999)

usx95 wrote: I think this is important that clang chooses not to error but only warn here as a clang extension (it already chooses to do so in cases when it the can match the function params([1](https://github.com/llvm/llvm-project/blob/main/clang/lib/Sema/SemaOverload.cpp#L10274-L10290) and

[clang] Correctly compute conversion seq for args to fn with reversed param order (PR #68999)

usx95 wrote: Ah. I see, this is because this is not a warning but hard errors in C++20. https://github.com/llvm/llvm-project/pull/68999 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Correctly compute conversion seq for args to fn with reversed param order (PR #68999)

usx95 wrote: This breaks new code (expected) but does not respect `-Wno-ambiguous-reversed-operator`. https://godbolt.org/z/oMsGeK1nc @zygoloid IIUC this should be silenced by this warning but somehow does not. Will investigate further. Reverting to put out large unsuppresable breakages

[clang] Correctly compute conversion seq for args to fn with reversed param order (PR #68999)

https://github.com/usx95 closed https://github.com/llvm/llvm-project/pull/68999 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Correctly compute conversion seq for args to fn with reversed param order (PR #68999)

usx95 wrote: +1 I agree that this is confusing and error prone. https://github.com/llvm/llvm-project/pull/68999 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Correctly compute conversion seq for args to fn with reversed param order (PR #68999)

https://github.com/zygoloid approved this pull request. Thanks, looks good. Our overall approach here seems error-prone, and I wonder if there's a better way to model the reversal of the conversion sequence. For example, perhaps we could change `ConversionSequenceList` into a class that

[clang] Correctly compute conversion seq for args to fn with reversed param order (PR #68999)

usx95 wrote: Friendly ping. https://github.com/llvm/llvm-project/pull/68999 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Correctly compute conversion seq for args to fn with reversed param order (PR #68999)

github-actions[bot] wrote: :warning: C/C++ code formatter, clang-format found issues in your code. :warning: You can test this locally with the following command: ``bash git-clang-format --diff ba79fb2e1ff7130cde02fbbd325f0f96f8a522ca 74712023035fe4d670306776d9808bed91fe4ba3 --

[clang] Correctly compute conversion seq for args to fn with reversed param order (PR #68999)

https://github.com/usx95 updated https://github.com/llvm/llvm-project/pull/68999 >From 01ba05ec9349c7b93239b7e6196e3fa6c7fc1f82 Mon Sep 17 00:00:00 2001 From: Utkarsh Saxena Date: Fri, 13 Oct 2023 17:17:32 +0200 Subject: [PATCH 1/3] Correctly compute conversion seq for args to fn with

[clang] Correctly compute conversion seq for args to fn with reversed param order (PR #68999)

https://github.com/usx95 updated https://github.com/llvm/llvm-project/pull/68999 >From 01ba05ec9349c7b93239b7e6196e3fa6c7fc1f82 Mon Sep 17 00:00:00 2001 From: Utkarsh Saxena Date: Fri, 13 Oct 2023 17:17:32 +0200 Subject: [PATCH 1/2] Correctly compute conversion seq for args to fn with

[clang] Correctly compute conversion seq for args to fn with reversed param order (PR #68999)

llvmbot wrote: @llvm/pr-subscribers-clang Author: Utkarsh Saxena (usx95) Changes We associated conversion seq for args (when reversed) to the wrong index. This lead to clang believing reversed `operator==` a worse overload candidate than the `operator==` without reversed args when both

[clang] Correctly compute conversion seq for args to fn with reversed param order (PR #68999)

https://github.com/usx95 created https://github.com/llvm/llvm-project/pull/68999 We associated conversion seq for args (when reversed) to the wrong index. This lead to clang believing reversed `operator==` a worse overload candidate than the `operator==` without reversed args when both these