Skip to content

Better assignability errors to never-producing vacuous intersections #37618

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
wants to merge 3 commits into from
Closed

Better assignability errors to never-producing vacuous intersections #37618

wants to merge 3 commits into from

Conversation

DanielRosenwasser
Copy link
Member

@DanielRosenwasser DanielRosenwasser commented Mar 26, 2020 •
edited
Loading

This was a naive first pass at something that I realized would be nice as I wrote up the breaking change section.

I couldn't do a fix everywhere because it became pretty impractical - for example, by the time we do the checks in some places, assignability, I guess we're given never instead of the original intersection.

const x1 = { a: 'foo', b: 42 };
const x2 = { a: 'foo', b: true };

declare let k: 'a' | 'b';

x1[k] = 42;

Things I'd like some guidance on:

  1. Uh, I just hit 1 << 29 on NodeBuilderFlags. I've forgotten if that means I get a prize or a scolding for hitting the max unboxed value on a flag. (thanks @yuit) image
  2. Error message phrasing.

@DanielRosenwasser DanielRosenwasser changed the title Better assignability errors to never-produced vacuous intersections Better assignability errors to never-producing vacuous intersections Mar 26, 2020
weswigham
weswigham reviewed Mar 27, 2020
View reviewed changes
tests/baselines/reference/intersectionReduction.errors.txt
@@ -44,6 +47,11 @@ tests/cases/conformance/types/intersection/intersectionReduction.ts(81,1): error
ab.kind; // Error
~~~~
!!! error TS2339: Property 'kind' does not exist on type 'never'.
!!! error TS2339: The type 'never' was reduced from the intersection 'A & B'. Each type of that intersection has properties that conflict, so values of that type can never exist.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should probably search for and report the properties that conflict and their respective types, no? So the error is somewhat more actionable?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Definitely seems doable, but only if the approach in this PR seems reasonable.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems OK. We could probably consider leaving behind more "breadcrumbs" like this in the future to explain how a specific type came about; but it's always about striking that balance between useful explaianation and terseness.

sandersn
sandersn reviewed Apr 1, 2020
View reviewed changes
Copy link
Member

@sandersn sandersn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Error seems good, and implementation seems OK except for the flags problem.

src/compiler/diagnosticMessages.json
@@ -5653,5 +5653,9 @@
"An optional chain cannot contain private identifiers.": {
"category": "Error",
"code": 18030
},
"The type 'never' was reduced from the intersection '{0}'. Each type of that intersection has properties that conflict, so values of that type can never exist.": {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why 'each' here? Wouldn't 'some' be correct?

If that's true, I'd just say "Types in that intersection ..."

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point

@ahejlsberg ahejlsberg mentioned this pull request Apr 2, 2020
Merged
@DanielRosenwasser
Copy link
Member Author

#37618 provides the better error message.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@sandersn sandersn sandersn left review comments

@weswigham weswigham weswigham left review comments

@ahejlsberg ahejlsberg Awaiting requested review from ahejlsberg

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@DanielRosenwasser @sandersn @weswigham