[llvm-bugs] [Bug 49618] New: Invalid templates aren't marked as invalid on Windows

via llvm-bugs llvm-bugs at lists.llvm.org
Wed Mar 17 10:54:42 PDT 2021


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

            Bug ID: 49618
           Summary: Invalid templates aren't marked as invalid on Windows
           Product: clang
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: z.zoelec2 at gmail.com
                CC: blitzrakete at gmail.com, dgregor at apple.com,
                    erik.pilkington at gmail.com, llvm-bugs at lists.llvm.org,
                    richard-llvm at metafoo.co.uk

I think this Godbolt demonstrates the problem pretty clearly:
https://godbolt.org/z/Mv5osj

Basically, if there's an invalid decl (such as the var decl shown in the
Godbolt), neither the decl nor its parent will be marked invalid on Windows.
But, on all other platforms, they will (properly?) be marked as invalid. I ran
into this problem while testing Swift's C++ interop; it was causing crashes
because we had no way to differentiate valid and invalid decls on Windows, so
invalid decls were slipping through. 

I thought the MS compatibility features might have been the cause of this
issue, but the problem persists when I pass -fno-delayed-template-parsing and
-fno-ms-compatibility. 

I'd like to understand why this is happening and if it's the intended behavior.
I'd also like to find a good short-term solution so that I can stop Swift's C++
interop from crashing. (Whether that's a flag to disable it or another API that
I can use to find out if the decl is actually invalid. Right now, I'm using
"isInvalidDecl.")

-- 
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/20210317/9a0f24a4/attachment.html>


More information about the llvm-bugs mailing list