Skip excess property elaborations #29760
Conversation
|
Looks like this only fails because |
|
Exciting! |
|
@weswigham @RyanCavanaugh can you take a look? |
| !!! error TS2322: Types of property 'prop' are incompatible. | ||
| !!! error TS2322: Type '{ colour: string; }' is not assignable to type 'CSSProps'. | ||
| !!! error TS2322: Object literal may only specify known properties, but 'colour' does not exist in type 'CSSProps'. Did you mean to write 'color'? | ||
| !!! error TS2561: Object literal may only specify known properties, but 'colour' does not exist in type 'CSSProps'. Did you mean to write 'color'? | ||
| !!! related TS6500 tests/cases/compiler/nestedFreshLiteral.ts:5:3: The expected type comes from property 'nested' which is declared here on type 'NestedCSSProps' |
There was a problem hiding this comment.
Do these two messages mix well together?
| !!! error TS2322: Type '() => { foo: string; jj: number; }' is not assignable to type '() => Style'. | ||
| !!! error TS2322: Type '{ foo: string; jj: number; }' is not assignable to type 'Style'. | ||
| !!! error TS2322: Object literal may only specify known properties, and 'jj' does not exist in type 'Style'. | ||
| !!! error TS2353: Object literal may only specify known properties, and 'jj' does not exist in type 'Style'. |
There was a problem hiding this comment.
I think this is a minor improvement. (/s I think this is way better)
|
@sandersn @weswigham any chance you can take a look here? |
There was a problem hiding this comment.
I know I mentioned this the other day, but cutting the entire diagnostic trail seems wrong to me. However, I can certainly see how the A is not assignable to B error immediately above the extra props error as usually not being needed. Would it be okay to just suppress a single level of the diagnostic message chain, rather than deleting the entire chain?
Take this one:
Conversion of type '{ foo: string; }[]' to type '{ id: number; }[]' may be a mistake because neither type sufficiently overlaps with the other. If this was intentional, convert the expression to 'unknown' first.
Type '{ foo: string; }' is not comparable to type '{ id: number; }'.
Object literal may only specify known properties, and 'foo' does not exist in type '{ id: number; }'.
cutting it to just
Object literal may only specify known properties, and 'foo' does not exist in type '{ id: number; }'.
seems excessive - I have no idea why I'm getting an excess property warning here. But
Conversion of type '{ foo: string; }[]' to type '{ id: number; }[]' may be a mistake because neither type sufficiently overlaps with the other. If this was intentional, convert the expression to 'unknown' first.
Object literal may only specify known properties, and 'foo' does not exist in type '{ id: number; }'.
is i think an OK compromise.
|
This is /basically/ replaced by #33473 so I'm closing. I get that they're not exactly the same, but they more or less have the same goals. |
Tries to fix #29759, but I haven't gotten the chance to review the baselines (I know, sounds dumb but I'm on a phone call now). One thing to keep in mind is the fact that we lose context of which branch in a union we're picking. That can be pretty bad, and I'm not sure exactly how to address that.