Find references, and let extensions observe debugging - #79
Merged
Conversation
TS 워커가 getReferencesAtPosition 은 내준다. getNavigateToItems 는 안 내주길래 이것도 없을 줄 알았는데 확인해보니 됨. 이름으로 정의를 잡고 그 자리에서 참조를 묻는다. 이름이 여러 군데 정의돼 있으면 어디를 뜻하는지 되묻고, path 로 좁힐 수 있게 함. 확장 쪽은 vscode.debug 중 관찰과 중단점까지. activeDebugSession, onDidStartDebugSession / onDidTerminate / onDidChangeBreakpoints, breakpoints, addBreakpoints / removeBreakpoints. 앱이 이미 들고 있는 상태를 연결한 것. registerDebugAdapterDescriptorFactory(확장이 디버거를 제공하는 것)와 커스텀 에디터는 아직 없음. 없는 채로 둬서 부르면 TypeError 가 나게 함. 중간에 만든 버그 하나: 확장이 넣은 중단점 키를 uri.path 로 잡아서 절대 경로가 들어갔다. 개수만 늘고 거터에는 아무것도 안 그려짐. uriToRel 로 고침.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Two items: the last entry in the 0.4.0 plan §7, and part of track C-3 from the 0.3.0 plan.
find_references
The plan said to check whether the worker exposes references at all, since
getNavigateToItemsturned out not to exist. It does —getReferencesAtPositionworks and returns both the definition and the call sites.The tool takes a name, locates the definition through the existing symbol search, and asks for references at that position. When a name is defined in several places it says so and asks to narrow with
pathrather than picking one — guessing here would send the model off to the wrong thing.Measured on a small project:
verifyToken→ definition atauth.ts:3plus the call atapp.ts:4;TokenVault→ 3 sites including the import and the construction.vscode.debug, the observing half
Extensions had no way to know whether a debug session was running. This adds what most of them actually use:
activeDebugSession,onDidStartDebugSession,onDidTerminateDebugSession,onDidChangeActiveDebugSessionbreakpoints,onDidChangeBreakpoints,addBreakpoints,removeBreakpointsAll of it is wired to state the app already keeps, so nothing is invented.
registerDebugAdapterDescriptorFactory— an extension providing its own debugger — is still absent, and so are custom editors. Both remain absent from the API object rather than stubbed, so calling one is aTypeErrorinstead of a silent no-op.A bug made and caught here
The breakpoint an extension adds was keyed by
uri.path, which is an absolute path. The count went up and the shim reported it, but the gutter drew nothing — the entry pointed at a key the editor never looks up. Resolved throughuriToRelnow. The probe caught it by checking the red dot rather than trusting the extension's own count.Verification
Real app, 5/5: no session reports no session; the breakpoint list reads; a breakpoint added by an extension lands in the app's own state, fires the change event, and draws in the editor gutter.
Symbol references verified separately against a fresh TypeScript project.
1102 unit tests passing.
npm run typecheckandnpm run buildclean.