jimingham wrote: > > I'm not sure what you mean by "mixed language expressions". > > I was thinking about the case where a user attempts `p $some_c_var + 1` in > Swift frame – which is valid swift as far as the debugger is concerned. I > said mixed because it's got a C var inside a Swift expression.
The important thing is not whether this is abstractly a valid swift expression, but rather that is an expression that would execute correctly in the Swift Expression parser. That won't happen with this expression because the swift compiler can't find `$some_c_var` and and even if it could it wouldn't know how to use it. My take is that if I do `p some_var` and you return `some_var` successfully, then when I do `p some_var->some_method()` you will use the language in which you found that symbol to evaluate that expression that uses it. I don't see how you will know that directly, I think the best you can do is try them all in some reasonable order. `dwim-print` has a language option because it's really trying to be the expression parser but done as efficiently as possible. Having it just sometimes ignore whatever that language option is supposed to instruct it to do seems wrong, and having it sometimes ignore the language and other times not is even more wrong, IMO. https://github.com/llvm/llvm-project/pull/85152 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
