Fix incorrect error location when a spread overrides an explicit property (#51376) - #64480
Open
Alok Sharma (im-alok74) wants to merge 1 commit into
Open
Alok Sharma (im-alok74) wants to merge 1 commit into
Alok Sharma (im-alok74) wants to merge 1 commit into
Conversation
… shadowed property When a later spread in an object literal overwrites an earlier explicit property of the same name in the merged type, elaborateObjectLiteral was still elaborating the assignability error against the earlier property's initializer. This pointed diagnostics at the wrong source location, since the spread - not the shadowed property - determines the property's final type. Fixes microsoft#51376
Author
|
@microsoft-github-policy-service agree |
This branch has not been deployed
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
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.
Fixes #51376
Problem
When an object literal has an explicit property later overwritten by a
spread (e.g.
{ attribute: "", ...result }), and the merged type causesan assignability error, the checker's object literal elaboration
(
elaborateObjectLiteralinrelater.go) always attributed thediagnostic to the first node it found with that property name — the
earlier explicit property — even when a later spread in the same
literal also contributes (and overrides) that property in the merged
type. This pointed the error at code that was actually fine, while the
real source of the type mismatch (the spread) went unmarked.
Fix
elaborateObjectLiteralnow precomputes, for each spread in the objectliteral, the set of property names it contributes to the merged type.
When elaborating an explicit property, it checks whether any later
spread also declares that property name; if so, the diagnostic is
anchored to that spread's expression instead of the (now shadowed)
property, and the property's own initializer is no longer recursed
into for elaboration purposes.
Testing
spreadOverridingPropertyElaboratesOnSpread.tswith threecases: the fixed case (spread after property), a control where the
property comes after the spread (no error), and a control with no
spread at all (error still on the property).
the original report's
Partial<Record<'attribute', string | null>>case, and the later "clearer" repro (
const result = { attribute: 0 })— both now report
TS2322on the spread expression, not on theexplicit property.
go test ./internal/testrunner/... -run TestLocalsuite passeswith no regressions.