[flang-commits] [PATCH] D86410: [flang][msvc] Avoid ambiguous overload from base class. NFC.

Mon Aug 24 10:11:46 PDT 2020

klausler added a comment.

In D86410#2234030 <https://reviews.llvm.org/D86410#2234030>, @Meinersbur wrote:

> In D86410#2233901 <https://reviews.llvm.org/D86410#2233901>, @klausler wrote:
>
>> Is the MSVC bug peculiar to template member functions like `template <int K> operator()(const TypeParamInquiry<K> &) const`?  If so, is it peculiar to *just* `TypeParamInquiry`, or does it affect other templatized expression nodes as well?
>
> The error happens with hidden methods with non-type templated method in templated base classes. The smallest reproducer I could create is this: https://godbolt.org/z/59ar5d. It does not occur when the template parameter is a class type: https://godbolt.org/z/1xo8jh. Thus, I think TypeParamInquiry is the only one affected.
>
>> If that turns out to be the case, there's some changes to the expression representation that could be tried that would avoid the use of a template in that case.
>
> Could you elaborate?
>
>> Another possible work-around, if the problem is specific to this one expression representation class: specialize the member function in the general `Traverse` class for each of the integer kinds.
>
> Which specializations for KIND do we need? 8,16,32,64, any other?

`class TypeParameterInquiry` could be redefined as an operation that always returned the same kind of INTEGER result, and explicit conversions to other kinds would be wrapped around its usage.  It would become an operation allowed only in one instantiation of `Expr<Type<TypeCategory::Integer, KIND>>`.  This change would be big enough to have some ripple effects, but I'd be happy to do it for you as an experiment that you could try with your MSVC environment.

The second work-around would use specializations for KIND values of 1, 2, 4, and 8.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D86410/new/

https://reviews.llvm.org/D86410