microsoft / microsoft/debug-adapter-protocol

Non-unique variable names within a container

Open
#141 6 comments 1 reaction 2 assignees View on GitHub

@roblourens is already working on this.

Since Feb 1, 2023.

clarification
Dominant language
HTML
Stars
1.8k
Forks
173
Avg merge
7d 7h
Merged PRs (30d)
2

Description

The Variables type does not specify that its name should be unique within a cotainer, but it seems that DAP assumes that they are in several places:

  • At least some implementations fail to list repeated names in a Variables response. (Related https://github.com/microsoft/vscode/issues/107506)
  • SetVariables request takes a name argument, which produces ambiguity (and leaves some vars inaccessible) if there are multiple variables of that name
  • I'm not using Data Breakpoints yet, but DataBreakpointInfo also seems to use ref+name to identify a variable, with the same problems as SetVariables

This is causing some problems for me, because in Lua it's perfectly valid to do something like this:

local function a()
  local a = 1
  local a = 2
  local a = 3
  local a = 4
  return
end

or

local function a()
  local a = 1
  do
    local a = 2
    print(a) -- uses the second a
  end
  print(a) -- uses the first a again
end

and I've had some complaints from users about getting "the wrong" version of redefined locals.

It seems like the protocol wants me to make a new Scope at every block or something like that, but i don't get enough information from the Lua runtime to do that, and in any case it wouldn't work since redefining within a block is legal anyway.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.