Add a defensive nullptr check. #37422
Conversation
ASTContext::get##NAME##Type() can return an empty type and we have LLDB crash logs that show this can really happen. rdar://74503567 (cherry picked from commit 9c8f325)
|
@swift-ci test |
|
You shouldn't get the null type period from these functions. This usually indicates the standard library is not being loaded. |
|
... which is something that can happen in LLDB. |
|
I only have a crashlog and no reproducer, so I don't know if the root cause was that the stdlib wasn't loaded (which can happen if we reconstruct the triple wrong, or debug a binary built with a different toolchain, or ...) but if a function can return a nullptr the result needs to be checked so the error can be bubbled up and diagnosed. |
|
I want to have these functions crash on null. If LLDB doesn't have stdlib loaded, it should not be allowed to make semantic queries into the compiler. Anything that can go wrong, will go wrong. |
|
That said, my opposition here is philosophical in nature. We should still take this check. |
|
It feels like you are hiding the real problem and it may deserve a log message. |
This is very understandable from a compiler developer's point of view, but long-lived tools like the Swift REPL or LLDB that embed the Swift compiler as a library you generally want to always report or log errors and avoid crashing at all costs. Crashing the debugger is always a terrible user experience. It's fine if evaluating an expression is returning an error, and there are lots of useful things you can do in the debugger even if the Swift AST context is broken. As for this specific case, I don't have any data about the root cause here. Generally, LLDB avoids using a Swift AST context once it went into a fatal error state, but for that to work reliably we need to make sure to actually bubble up all errors. |
ASTContext::get##NAME##Type() can return an empty type and we have LLDB crash
logs that show this can really happen.
rdar://74503567
(cherry picked from commit 9c8f325)