debug: support location references for variable values #225546
Merged
Conversation
This file contains 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
Adopts microsoft/debug-adapter-protocol#343 Also tackles some debt around debug linkification, resolving an issue where links had native hovers that conflicted with the rich hovers added a few iterations ago. It still uses native hovers for links in some contexts (plain text output in the debug console) because we don't pass through element disposables there, but it uses workbench hovers when there's not another rich hover being used (rich debug console output).  Closes #225425
DonJayamanne
approved these changes
Aug 13, 2024
|
|
||
| const location = await this.raw.locations({ locationReference }); | ||
| if (!location?.body) { | ||
| throw new Error(localize('noDebugAdapter', "No debugger available, can not send '{0}'", 'locations')); |
|
Could it be that this does not work for remote debugging sessions (using the Remote SSH extension), yet? I am currently trying to implement this in the 
Towards the bottom of the screenshot, you can see the reply of the debug adapter. Note how it refers to the file as In a couple of other requests, I am seeing VS-Code to refer to this path as |
vogelsgesang
added a commit
to vogelsgesang/llvm-project
that referenced
this pull request
Aug 16, 2024
This commit implements support for the "declaration location" recently added by microsoft/debug-adapter-protocol#494 to the debug adapter protocol. For the `declarationLocationReference` we need a variable ID similar to the the `variablesReference`. I decided to simply reuse the `variablesReference` here and renamed `Variables::expandable_variables` and friends accordingly. Given that almost all variables have a declaration location, we now assign those variable ids to all variables. While `declarationLocationReference` effectively supersedes `$__lldb_extensions.declaration`, I did not remove this extension, yet, since I assume that there are some closed-source extensions which rely on it. I tested this against VS-Code Insiders. However, VS-Code Insiders currently only supports `valueLoctionReference` and not `declarationLocationReference`, yet. Locally, I hence tried to publish the declaration locations as value locations. However, it seems that VS-Code still has issues with correctly resolving file paths, as reported in microsoft/vscode#225546 (comment)
vogelsgesang
added a commit
to vogelsgesang/llvm-project
that referenced
this pull request
Aug 16, 2024
This commit implements support for the "declaration location" recently added by microsoft/debug-adapter-protocol#494 to the debug adapter protocol. For the `declarationLocationReference` we need a variable ID similar to the the `variablesReference`. I decided to simply reuse the `variablesReference` here and renamed `Variables::expandable_variables` and friends accordingly. Given that almost all variables have a declaration location, we now assign those variable ids to all variables. While `declarationLocationReference` effectively supersedes `$__lldb_extensions.declaration`, I did not remove this extension, yet, since I assume that there are some closed-source extensions which rely on it. I tested this against VS-Code Insiders. However, VS-Code Insiders currently only supports `valueLoctionReference` and not `declarationLocationReference`, yet. Locally, I hence tried to publish the declaration locations as value locations. However, it seems that VS-Code still has issues with correctly resolving file paths, as reported in microsoft/vscode#225546 (comment)
vogelsgesang
added a commit
to vogelsgesang/llvm-project
that referenced
this pull request
Aug 16, 2024
This commit implements support for the "declaration location" recently added by microsoft/debug-adapter-protocol#494 to the debug adapter protocol. For the `declarationLocationReference` we need a variable ID similar to the the `variablesReference`. I decided to simply reuse the `variablesReference` here and renamed `Variables::expandable_variables` and friends accordingly. Given that almost all variables have a declaration location, we now assign those variable ids to all variables. While `declarationLocationReference` effectively supersedes `$__lldb_extensions.declaration`, I did not remove this extension, yet, since I assume that there are some closed-source extensions which rely on it. I tested this against VS-Code Insiders. However, VS-Code Insiders currently only supports `valueLoctionReference` and not `declarationLocationReference`, yet. Locally, I hence tried to publish the declaration locations as value locations. However, it seems that VS-Code still has issues with correctly resolving file paths, as reported in microsoft/vscode#225546 (comment)
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Adopts microsoft/debug-adapter-protocol#343
Also tackles some debt around debug linkification, resolving an issue
where links had native hovers that conflicted with the rich hovers added
a few iterations ago. It still uses native hovers for links in some
contexts (plain text output in the debug console) because we don't pass
through element disposables there, but it uses workbench hovers when
there's not another rich hover being used (rich debug console output).
Closes #225425