Remove diagnostic dependent output in structuredTypeRelatedTo
#29817
Conversation
…t type parameters are correctly measured
|
Just tried this, and it does not seem to fix my issue (#29393) (same error as before) here's a clonable example: https://gist.github.com/phiresky/4584e5d36d5fbae37e6afb07e3076536 |
|
@weswigham please check if this fixes #29901 as well |
|
#29901 seems to be an unrelated issue to do with our subtype relationship. |
By that I assume you mean "now no matter what I try there's a type error"? #29698 tracks altering the change that makes that |
Not that that would be good for me either (since then I'm still stuck on 3.0), but no I actually mean that with this branch, it's still exactly the same as before, it shows an error only when commenting that other line. |
|
@phiresky I'm not seeing it?: You sure you have the |
|
I actually tried it from the command line not VSCode, just like I did the bisect ( but i'm not 100% confident I did it correctly |
|
@weswigham So regarding my actual issue #29393 @weswigham , should I open a new one or is that maybe the same as #29698? Here's my library that is broken by these changes btw: https://github.com/phiresky/typed-socket.io (errors in this file in TS>3.0) |
|
Actually, the error is in some respects correct... Long story short, a
And that's why the error is "correct". Now, I say that, but the mapped type assignability rules in higher order aren't keen on one case: mapping over the empty object always produces the empty object (so the variances of the type parameters no longer matter once the key set being mapped over is empty). This simplification/decomposition isn't reflected in mapped type higher order relationships (this would require expressing a dependent variance of some kind), so ends up not being reflected by variance measures. At it's heart, that is the same underlying issue as #29698 (though admittedly slightly different, since it relies on an edgecase around |
You are right. I managed to solve my problem by replacing instances of where I had I reason I wrote them as [1] because this is the error message i get on the actual instance of the problem: |
|
This breaks ember's types on DT in a very confusing way (which may be correct!). Go to ~/DefinitelyTyped/types/ember__application and run tsc. I'll provide a repro shortly once I understand the problem better. |
|
ember wants to do the unsound thing where they have: class Base {
resolver: BaseResolver
}
class Derived extends Base {
resolver: DerivedResolver
}where Here's a minified repro. I'm not sure how interesting it is: declare class ComputedProperty<Get, Set=Get> {
// Necessary in order to avoid losing type information
// see: https://github.com/typed-ember/ember-cli-typescript/issues/246#issuecomment-414812013
private ______getType: Get;
private ______setType: Set;
}
type UnwrapComputedPropertyGetter<T> = T extends ComputedProperty<infer U, any> ? U : T;
type UnwrapComputedPropertyGetters<T> = { [P in keyof T]: UnwrapComputedPropertyGetter<T[P]> };
type UnwrapComputedPropertySetter<T> = T extends ComputedProperty<any, infer V> ? V : T;
type UnwrapComputedPropertySetters<T> = {[P in keyof T]: UnwrapComputedPropertySetter<T[P]>};
interface Observable {
/**
* To get the values of multiple properties at once, call `getProperties`
* with a list of strings or an array:
*/
getProperties<K extends keyof this>(list: K[]): Pick<UnwrapComputedPropertyGetters<this>, K>;
setProperties<K extends keyof this>(hash: Pick<this, K>): Pick<UnwrapComputedPropertySetters<this>, K>;
}
type Ctor<T> = new (...args: any[]) => T;
declare class Mixin<T> { }
declare function ext<T>(arg1: Mixin<T>): Ctor<T>;
declare const MixedO: Mixin<Observable>;
declare class Base extends ext(MixedO) {}
declare class Derived extends Base {
p: number;
}
declare let r: Base
declare let dr: Derived
r = dr // unexpected error here |
|
jasmine is also broken because of this, with code interface Foo {
a: number;
b: number;
bar: string;
}
interface ObjectContaining<T> {
new (sample: Partial<T>): Partial<T>
}
declare let cafoo: ObjectContaining<{ a: number, foo: number }>;
declare let cfoo: ObjectContaining<Foo>;
cfoo = cafoo;
cafoo = cfoo;I'm not sure why this worked before. |
|
As for the ember bit I'm pretty sure it's because |
Same. Shouldn't weak type checking have at least forbidden the one direction of that? |
|
Some other DT breaks:
I haven't investigated these, but they fail at exactly the same bisected commit. |
|
I'm not positive, but this may be the same issue I've seen in a library, reproduction here. If it's not the same, it's another thing hit by changes in variance—but the symptoms are very similar, and the issue definitely one of invariance. I can see how minimal the definitions for True Myth's |
|
Here is another example, similar to #29698 type Base = Record<string, {}>;
interface Wrapper<B extends Base> {
b: B;
f(): keyof B; // makes Wrapper covariant in keyof B
// in reality it was map: Map<Extract<keyof B, string>, {}>;
}
declare function createWrapper<B extends Base>(b: B): Wrapper<B>;
declare function acceptRecordOfWrappers<R extends Record<string, Wrapper<Base>>>(r: R): void;
acceptRecordOfWrappers({
w: createWrapper({a: {}})
});
// Type 'Wrapper<{ a: {}; }>' is not assignable to type 'Wrapper<Record<string, {}>>'.
// Property 'a' is missing in type 'Record<string, {}>' but required in type '{ a: {}; }'.Some notes:
I actually mean |
|
Pretty sure yargs has the problem too: declare let yb: yargs.Argv<{ b: number }>
declare let yab: yargs.Argv<{ a: string, b: number }>
yb = yab // seems fine......Except that one of Argv's methods uses |
|
Poking at material-ui, the break there is on React's ComponentClass. I'm not sure why no other react tests break -- it's hard to believe that all other uses are invariant. Edit: it's because material-ui has strictFunctionTypes: false, so all (most?) other react dependents have been fixed. |
Fixes #29393
Also unified the special-case (void covariant param) handling between aliases and interfaces, and removed the early bail on no
strictFunctionTypesfromgetVariancesso we can still measure independent type parameters whenstrictFunctionTypesisn't on (as now that the variance result is always consistently reported, this flaw was pretty obvious).