[libcxx-commits] [clang] [libcxx] Reapply "[Clang] Implement resolution for CWG1835 (#92957, #98547)" (PR #100425)

[Krystian Stasiowski via libcxx-commits]

sdkrystian wrote:

@cor3ntin This wouldn't fix [the case that abseil users complained about](https://github.com/llvm/llvm-project/pull/98547#issuecomment-2224998395) (example reduced from [the source](https://github.com/abseil/abseil-cpp/blob/master/absl/container/internal/compressed_tuple.h#L256)):
```cpp
template <typename... Ts>
class CompressedTuple
    : private internal_compressed_tuple::CompressedTupleImpl<
          CompressedTuple<Ts...>, absl::index_sequence_for<Ts...>,
          internal_compressed_tuple::ShouldAnyUseBase<Ts...>()> {

  template <int I>
  using StorageT = internal_compressed_tuple::Storage<ElemT<I>, I>;

 public:
  template <int I>
  constexpr ElemT<I>&& get() && {
    return std::move(*this).StorageT<I>::get();
  }
};
```

Moreover, this fails to address cases where the base class declares a non-static data member with the same name as the class template:
```cpp
template<typename T>
struct A
{
    int A;
};

template<typename T>
struct B : A<T>
{
    bool f()
    {
        return this->A < 1; // '<' would be interpreted as the start of a template argument list
    }
};
```

I think that implementing CWG1835's resolution as it stands is our best option. Doing so results in the most consistent behavior (e.g. 'use template when the object expression is dependent'), the most obvious fixes to achieve the intended interpretation (i.e. 'add `template` prior to the intended template name' [as opposed to surrounding the class member access expression in parentheses]). Given that we can now identify _almost_ all cases where `template` is missing with this patch and issue a warning, and that these cases wouldn't be resolved by any of the proposed compromises, I think our best option is to simply implement the resolution with enhanced recovery/  

https://github.com/llvm/llvm-project/pull/100425