Don’t lookupOverrides of special names. #25584
Conversation
|
@swift-ci please smoke test |
|
@jimingham, @adrian-prantl, any idea how to write a test case for this in the Swift repo? |
I don't know how to trigger this code path, but to get a special name, all that should be necessary is to compile with |
|
A "special name" is |
|
The DebuggerClient is a pretty simple interface, maybe you could have a no-op one in the frontend that you activate when passed some obscure option? It should be good enough to return false from all the lookups. Most of lldb's special behavior when parsing expressions happens because we give the LLDBDebuggerFunction attribute to the wrapper functions, and then various things in swift check for that. So just having a trivial DebuggerClient present shouldn't trigger any special compilation. Then you just have to get to this code path. BTW, the DebuggerClient interface was designed before I started working on lldb's swift expression parser, so I don't know what the original rational for it was, but lookupOverrides has returned false for all inputs for as far back as I can find sources for it. Maybe the intent was to use it to redefine entities in the REPL? But it isn't used for that. |
|
That's to say: I don't know how to trigger this code because from our perspective it's never done anything we would care about... |
Per SR-10949 , fixes a compiler crash. When the base name is computed for the debug client and the name is special, the getBaseName function fails. So, don't try to compute an override for a special name.