In the PR, Clang ended up in a situation where it tried to mangle the __float128 type, which isn't supported when targetingt MSVC, because it instantiated a variable template with that type when searching for a conversion to use in an arithmetic expression.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
lib/Sema/SemaOverload.cpp | ||
---|---|---|
7669 ↗ | (On Diff #121409) | Spurious trailing slash. |
7731–7746 ↗ | (On Diff #121409) | I don't think these asserts are particularly worthwhile now we're not hardcoding the indices. |
test/CodeGenCXX/microsoft-cannot-mangle-float128.cpp | ||
3–11 ↗ | (On Diff #121409) | This seems like a fragile way of checking for the bug; I'd prefer a test that tests Sema rather than code generation. For instance, how about a class with a conversion operator that converts to T with an enable_if disabling it for float, double, and long double, and a check that an instance of such a class can't be used in floating-point arithmetic? |
test/CodeGenCXX/microsoft-cannot-mangle-float128.cpp | ||
---|---|---|
3–11 ↗ | (On Diff #121409) | Thanks! That sounds like a good plan. |
Addressing comments and changing the test to exercise Sema more directly.
Please take another look.
lib/Sema/SemaOverload.cpp | ||
---|---|---|
7618 ↗ | (On Diff #121824) | Can we do better than a magic number here? I don't like that getting this wrong will lead to a silent performance change. (Can we at least assert isSmall() below or something?) |
lib/Sema/SemaOverload.cpp | ||
---|---|---|
7618 ↗ | (On Diff #121824) | It turns out isSmall() isn't public, so I can't use that directly, but I've added a constant for the capacity and an assert against that. I don't actually know if there's any good reason for isSmall() to not be public. If you agree, I can follow up and just use that. |