[llvm-bugs] [Bug 41604] New: [msvc compat] clang++ assertion in MergeAccess when using __super

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=41604

            Bug ID: 41604
           Summary: [msvc compat] clang++ assertion in MergeAccess when
                    using __super
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: mike.winterberg at gmail.com
                CC: llvm-bugs at lists.llvm.org, neeilans at live.com,
                    richard-llvm at metafoo.co.uk

Note: I'm compiling with clang++ from the daily-ish
LLVM-9.0.0-r358402-win64.exe. Perhaps notably, from the nightly .deb
svn359077-1~exp1+0~20190424091502.2471~gbpac4d8e, the assertion isn't hit, but
I'm uncertain if those are compiled with assertions enabled.

When using the __super extension to access a function that is overloaded and
has different access specifiers from a super-super class, the assertion 
Assertion failed: DeclAccess != AS_none, file
C:\src\llvm_package_358402\llvm\tools\clang\include\clang/AST/DeclCXX.h, line
1873
is hit.

$ clang++ -fms-extensions super_test.cc

struct A
{
    int get_val(int index) const;
private:
    int get_val() const;
};

struct B : A
{
};

struct C : B
{
    int bob() const;
};

int C::bob() const
{
    return __super::get_val(1) + 1;
}


In real life, both get_val's are virtual and get_val(int) is overridden by C so
using __super is "necessary", but that isn't strictly necessary to trigger the
assertion.
Changing C to directly inherit from A instead of B avoids the assertion.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190425/7101ca76/attachment.html>