language-tools

Problem For every `.valueasserts__VLS_withDotValue.valuefoo.value()TS2339: Property 'value' does not exist on type '() => void'&&??v-elsefor...ofv-forvalueexactType(box2.value)number`).

Problem Source mappings are closed intervals: when two mapped chunks are adjacent in the source, the shared source offset is claimed by both the preceding chunk's end and the following chunk's start. As long as the two chunks are also adjacent in the generated code, both claims resolve to the same generated position and the double-claim is harmless. But when unmapped text is injected between the two chunks in the generated code, the shared boundary resolves to two disjoint generated positions. Rename (and similar position-driven features) then executes at both positions — and the first one lands on whatever the injected text contains. Concrete case (surfaced by #6184) #6184 emits setup-binding reads as — an unmapped prefix immediately before the mapped chunk: Renaming at its left boundary () resolves the source offset at two generated positions: 1. the end of the preceding chunk → lands on the identifier, 2. the start of the binding chunk → lands on (the intended one). Since is declared in a real file (), the rename produces an edit that renames the helper declaration itself — user code ends up rewriting library internals. This already exists on master — it is just invisible The same double-claim mechanism exists on master via the path (options API / undeclared bindings), where generated code is e.g. . Renaming at the same boundary position additionally targets — but is a virtual-unmapped synthetic variable, so its edits cannot map back to the source and are silently dropped. Verified locally: on an options-API component produces clean rename locations only because the extra edits are discarded. On master, setup bindings are emitted as / bare with no injected text between adjacent chunks, so the double-claim resolves to a single position there as well. Where the fix belongs Not in codegen. Any codegen-side workaround (detaching boundary characters, reshaping chunks) trades one mapping ambiguity for another. The fix belongs at the position-translation / rename layer: when a source position maps to multiple generated positions because of a boundary double-claim, rename should recognize that the extra positions come from the same shared boundary — or simply not execute rename at a generated position that the user could not have intended (e.g. positions claimed only via the end edge of a mapping while another claim via the start edge exists). Upstream Volar.js may be the right place. Reproduction 1. Check out #6184. 2. Open a `const foo = 1{{ foo +foo }}foofoopackages/language-core/types/template-helpers.d.ts__VLS_unwrap` declaration).

Vue - Official extension or vue-tsc version 3.3.11 VSCode version 1.127.0 Vue version 3.5.27 TypeScript version 5.9.3 Steps to reproduce Create a simple file with a generic declaration. Notice the default value for , which is the important part. What is expected? When using the component, it is expected that vscode would suggest or as valid values for the prop when autocompleting. What is actually happening? When using the component, it only suggests the default for the prop. Link to minimal reproduction _No response_ Any additional comments? I think it is important to mention that it no longer happens using Typescript 6.x.x. I haven't updated my project to TS 6.x.x because of some other issues. If you tell me that this is due to a TS limitation and not due to any internal issue, please disregard this bug.