Use DebugScope.getName() for language top scope label#13301
Use DebugScope.getName() for language top scope label#13301The-Alchemist wants to merge 2 commits intooracle:masterfrom
Conversation
Signed-off-by: The-Alchemist <karl@digital-alchemy.io>
08c5991 to
4f1f83d
Compare
| if (dscope.isFunctionScope() || dscope.getDeclaredValues().iterator().hasNext()) { | ||
| // provide only scopes that have some variables | ||
| scopes.add(Scope.create("Global", info.getId(dscope), true)); | ||
| scopes.add(Scope.create(topScopeDapName(dscope), info.getId(dscope), true)); |
There was a problem hiding this comment.
🤖 This changes observable DAP output, but the PR does not update the existing regression coverage. SimpleLanguageDAPTest.testScopes() still asserts Global at several scope responses, and there is no new DAP test for a language-defined top-scope display name. Please update that test and add a custom-language regression that asserts a non-default DebugScope.getName() value flows through here, plus the empty/error fallback.
| private static String topScopeDapName(DebugScope dscope) { | ||
| try { | ||
| String name = dscope.getName(); | ||
| if (name != null && !name.isEmpty()) { |
There was a problem hiding this comment.
🤖 This only falls back for null and the empty string. If a guest scope returns whitespace-only text from toDisplayString(), the DAP UI will get a blank label instead of the legacy Global fallback. I would trim here, or otherwise reject blank names before returning them.
I don't mind at all. I used AI to help me with the feature itself and the PR description. I think I can address the comments fairly easily with some additional tests and better verification. |
|
@fniephaus : let me know you think with the latest changes I pushed |
Summary
The Debug Adapter Protocol server always exposed Truffle’s language top scope (from
DebuggerSession.getTopScope) under the fixed name"Global", ignoring each language’s own scope display name.This change uses
DebugScope.getName()(which already reflects the guest scope’stoDisplayStringvia interop) when building the DAPScopeentry. If the name is missing, empty, orgetName()fails withDebugException, the label falls back to"Global", preserving previous behavior when a usable name is not available.Motivation
Guest languages can already provide a human-readable scope name through their scope object, but the DAP layer discarded it. Showing that name in the variables UI (e.g. namespace- or project-specific labels) improves clarity without changing how variables are resolved.
Use Case
For Clojure-on-Truffle–style languages, “globals” are usually namespace def / Var bindings, not Java-style globals. The language already exposes that through
TruffleLanguage.getScope(), and the guest scope object’stoDisplayStringis a natural place to say which namespace you’re looking at (for exampleNamespace: userorNamespace: my.app).Today the DAP server never showed that string: it always labeled that scope Global in the Variables view, so Clojure users saw a generic bucket name even when the implementation already knew the real namespace.
With this change,
DebugScope.getName()(which is driven by that toDisplayString) becomes the DAP scope title when it’s non-empty, so the same breakpoint UI can show a namespace-specific label. If the name can’t be resolved, behavior stays Global, matching the old default.Risk / compatibility
Low. Clients still receive a string scope name; only the default label changes when
getName()returns a non-empty value. Fallback remains"Global"on failure or empty name.B