This was reported as PR45231 but occurs even without cmath in C++17
mode if we have an expression involving unsupported types outside of a
function. For now we just avoid to create a diagnose builder in this
case as it might be valid anyway. A proper solution to handle
unsupported types has to be found. Discussion is ongoing in D74387.
Details
- Reviewers
hfinkel ABataev JonChesterfield
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Time | Test | |
---|---|---|
170 ms | lldb-unit.Host/_/HostTests::Unknown Unit Message ("") |
Event Timeline
clang/lib/Sema/SemaOpenMP.cpp | ||
---|---|---|
1831 | Please ignore my comment if it says nonsense. It actually can since I don't know a lot about OpenMP but, |
clang/lib/Sema/SemaOpenMP.cpp | ||
---|---|---|
1831 | It's not nonsense. I think the current system is not meant for non-function diagnostics. That said, I could probably bail later in the call chain, e.g. in diagIfOpenMPDeviceCode. Later we should rethink how this is done as we adopt to a more user-friendly model. |
D74387 includes a test case with expression involving unsupported types outside of a function (at the end of in nvptx_unsupported_type_messages.cpp).
Please ignore my comment if it says nonsense. It actually can since I don't know a lot about OpenMP but,
looking into targetDiag, I would say that underlying function (diagIfOpenMPDeviceCode in case of OpenMP device mode) should check that we actually have current function because it does getCurFunctionDecl() call.
Otherwise any attempt to emit diagnostic in OpenMP device mode using targetDiag or diagIfOpenMPDeviceCode will fail outside of functions.