In MSVC compatibility mode, handle unqualified templated base class initialization

[frederic-tingaud-sonarsource]

Summary

Before C++20, MSVC was supporting not mentioning the template argument of the base class when initializing a class inheriting a templated base class.
So the following code compiled correctly:

template <class T>
class Base {
};

template <class T>
class Derived : public Base<T> {
public:
  Derived() : Base() {}
};

void test() {
    Derived<int> d;
}

See https://godbolt.org/z/Pxxe7nccx for a conformance view.

This patch adds support for such construct when in MSVC compatibility mode.

[rnk]

clang/lib/Sema/SemaDeclCXX.cpp

4319–4320

We have to make sure our MS compatibility logic fires *before* we try to correct typos. It's currently a big issue that we don't. You can try adjusting your test case by adding a similarly named class like Baze and see if you still get the desired behavior.

See this old issue from 2014:
https://github.com/llvm/llvm-project/issues/20623

[frederic-tingaud-sonarsource]

Added two similar names in the tests, to try to trick the typo correction.

[rnk]

clang/lib/Sema/SemaDeclCXX.cpp

4319–4320

What I'd like to see is just to move the MSVCCompat check up before the typo correction. Basically, once we start typo correction, we *must* emit an error diagnostic. We may attempt to recover by returning a recovery AST node, but the compilation should fail overall.

I think in practice, we only do typo correction if lookup is empty, and your code only fires if name lookup returns a single result, so it's functionally equivalent to reorder these codepaths. I'd prefer that structure, mostly for readability.

[frederic-tingaud-sonarsource]

Sorry about the confusion, it makes sense. Fixed.

[frederic-tingaud-sonarsource]

By the way, in the current state of the code, there is no risk of such conflict between typo correction and UnqualifiedBase, because when an unqualified base exists the lookup result will not be empty.
That's why the test was not failing even without moving the compatibility first.

[rnk]

lgtm, thanks!

In D124666#3490871, @frederic-tingaud-sonarsource wrote:

By the way, in the current state of the code, there is no risk of such conflict between typo correction and UnqualifiedBase, because when an unqualified base exists the lookup result will not be empty.
That's why the test was not failing even without moving the compatibility first.

Yep, that's exactly it, but with the reordering it's somewhat clearer that, if we make this work for MS compat purposes, typo correction will not occur.