[lldb][Expression] Emit a 'Note' diagnostic that indicates the language used for expression evaluation #11618
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ge used for expression evaluation (llvm#161688) Depends on: * llvm#162050 Since it's a 'Note' diagnostic it would only show up when expression evaluation actually failed. This helps with expression evaluation failure reports in mixed language environments where it's not quite clear what language the expression ran as. It may also reduce confusion around why the expression evaluator ran an expression in a language it wasn't asked to run (a softer alternative to what I attempted in llvm#156648). Here are some example outputs: ``` # Without target (lldb) expr blah note: Falling back to default language. Ran expression as 'Objective C++'. # Stopped in target (lldb) expr blah note: Ran expression as 'C++14'. (lldb) expr -l objc -- blah note: Expression evaluation in pure Objective-C not supported. Ran expression as 'Objective C++'. (lldb) expr -l c -- blah note: Expression evaluation in pure C not supported. Ran expression as 'ISO C++'. (lldb) expr -l c++14 -- blah note: Ran expression as 'C++14' (lldb) expr -l c++20 -- blah note: Ran expression as 'C++20' (lldb) expr -l objective-c++ -- blah note: Ran expression as 'Objective C++' (lldb) expr -l D -- blah note: Expression evaluation in D not supported. Falling back to default language. Ran expression as 'Objective C++'. ``` I didn't put the diagnostic on the same line as the inline diagnostic for now because of implementation convenience, but if reviewers deem that a blocker I can take a stab at that again. Also, other language plugins (namely Swift), won't immediately benefit from this and will have to emit their own diagnistc. I played around with having a virtual API on `UserExpression` or `ExpressionParser` that will be called consistently, but by the time we're about to parse the expression we are already several frames deep into the plugin. Before (and at the beginning of) the generic `UserExpression::Parse` call we don't have enough information to notify which language we're going to parse in (at least for the C++ plugin). rdar://160297649 rdar://159669244 (cherry picked from commit e3620fe)
|
@swift-ci test |
…lvm#162048) Currently `llvm::dwarf::LanguageDescription` returns a stringified `DW_LNAME`. It would be useful to have an API that returns the language name for a particular `DW_LNAME_`/version pair. LLDB's use case is that it wants to emit diagnostics with human readable descriptions of the language we got from debug-info (see llvm#161688). We could maintain a side-table in LLDB but thought this might be generally useful and should live next to the existing `LanguageDescription` API. (cherry picked from commit 030d8e6)
…m#161803) The intention for this API is to be used when presenting language names to the user, e.g., in expression evaluation diagnostics or LLDB errors. Most uses of `GetNameForLanguageType` can be probably replaced with `GetDisplayNameForLanguageType`, but that's out of scope of this PR. This uses `llvm::dwarf::LanguageDescription` under the hood, so we would lose the version numbers in the names. If we deem those to be important, we could switch to an implementation that hardcodes a list of user-friendly names with version numbers included. The intention is to use it from llvm#161688 Depends on llvm#161804 (cherry picked from commit 2c37244)
Currently we don't benefit from the user-friendly names that `LanguageDescription` returns because we would always use `Language::GetNameForLanguageType`. I'm not aware of a situation where `GetDescription` should prefer the non-human readable form of the name with. This patch removes the call to `GetNameForLanguageType`. `LanguageDescription` already handles languages that it doesn't know about. For those it would return `Unknown`. The LLDB language types should all be available via DWARF. If there are languages that don't map cleanly between `lldb::LanguageType` and `DW_LANG`, then we should add explicit support for that in the `SourceLanguage::SourceLanguage` constructor. (cherry picked from commit 7f51a2a)
The LLDB test-suite compiles the tests on Windows with 'C++14' by default: https://github.com/llvm/llvm-project/blob/3bfb5b0e7ccbcb9f127f5b9c958e6499ba9c0523/lldb/packages/Python/lldbsuite/test/make/Makefile.rules#L357-L360 This fixes Windows buildbot failures.
|
@swift-ci test |
…lvm#150132) LanguageType has two kinds of enumerators in it. The first is DWARF-assigned enumerators which must be consecutive and match DW_LANG values. The second is the vendor-assigned enumerators which must be unique and must follow on from the DWARF-assigned values (i.e. the first one is currently eLanguageTypeMojo + 1) even if that collides with DWARF-assigned values that lldb is not yet aware of Only the DWARF-assigned enumerators may be static_cast from DW_LANG since their values match. The vendor-assigned enumerators must be explicitly converted since their values do not match. This needs to handle new languages added to DWARF and not yet implemented in lldb. This fixes a crash when encountering a DW_LANG value >= eNumLanguageTypes and wrong behaviour when encountering DW_LANG values that have not yet been added to LanguageType but happen to coincide with a vendor-assigned enumerator due to the consecutive values requirement described above. Another way to fix the crash is to add the language to LanguageType (and fill any preceeding gaps in the number space) so that the DW_LANG being encountered is correctly handled but this just moves the problem to a new subset of DW_LANG values. Also fix an unnecessary static-cast from LanguageType to LanguageType. (cherry picked from commit 726502d)
The ToDwarfSourceLanguage function incorrectly excluded languages that equal eLanguageTypeLastStandardLanguage. The comparison used `<` instead of `<=`, causing the last standard language to fall through to the default case and return std::nullopt. This broke language plugins that use eLanguageTypeLastStandardLanguage (currently Mojo at 0x0033) as their language code, preventing proper DWARF language conversion and breaking REPL functionality. The fix changes the comparison from `<` to `<=` to include the last standard language in the automatic conversion to DWARF source language. This is a regression from commit 7f51a2a which introduced the ToDwarfSourceLanguage function. (cherry picked from commit 8e3eeb8)
…sion (llvm#162050) Depends on llvm#162048 This makes sure we also include the version number in the description. For `C++17`, this would, e.g., now return `"C++17"` instead of `"ISO C++"`. (cherry picked from commit 992cf9a)
|
@swift-ci test |
This still fails on Windows because the default language for the C++ frame is not the same as on Unix. Also remove the LLD requirement, since we're not relying on DWARF here. (cherry picked from commit fc22b58)
|
@swift-ci test |
|
@swift-ci test Windows |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Depends on:
Since it's a 'Note' diagnostic it would only show up when expression evaluation actually failed. This helps with expression evaluation failure reports in mixed language environments where it's not quite clear what language the expression ran as. It may also reduce confusion around why the expression evaluator ran an expression in a language it wasn't asked to run (a softer alternative to what I attempted in llvm#156648).
Here are some example outputs:
I didn't put the diagnostic on the same line as the inline diagnostic for now because of implementation convenience, but if reviewers deem that a blocker I can take a stab at that again.
Also, other language plugins (namely Swift), won't immediately benefit from this and will have to emit their own diagnistc. I played around with having a virtual API on
UserExpressionorExpressionParserthat will be called consistently, but by the time we're about to parse the expression we are already several frames deep into the plugin. Before (and at the beginning of) the genericUserExpression::Parsecall we don't have enough information to notify which language we're going to parse in (at least for the C++ plugin).rdar://160297649
rdar://159669244
(cherry picked from commit e3620fe)