[NewErrors] 5.4.0-dev.20240121 vs 5.3.3 #57117
Comments
|
|
|
|
|
|
|
|
|
|
|
|
|
@MichaelMitchell-at fix at #57113 |
|
react-redux is trying to do the should-be-impossible and prevent function arguments from subtyping with this function export function expectExactType<T>(t: T) {
return <U extends Equals<T, U>>(u: U) => {}
}demonstrated here: // @ts-expect-error
expectExactType('5' as string)('5' as const)and also to prevent // @ts-expect-error
expectExactType('5' as any)('5' as const)To the extent they once succeeded, they're now broken by #56515. However, this functionality was never used AFAICT, every call is in the form e.g. so I don't think this is a blocker for that project in particular. |
It's worth noting that this is a fix for the @MichaelMitchell-at's minimal repro case but that minimal repro case likely isn't related to Drizzle's "cannot be used as an index type" problems (I know you have already bisected this to the PR that caused this particular change). Unless I'm mistaken, we only have changes between 5.3 and 5.4 reported here (the title of the issue suggests so :P) - and that minimal repro case already doesn't typecheck with 5.3 |
This PR compares errors between 5.3.3 and 5.4.0-dev.20240121 (not 5.4 and 5.4); but if it didn't build with 5.3, common errors will be ignored. |
|
That was just a typo - I meant what you have confirmed 😉 That minimal repro didn't typecheck with 5.3 so it just continues to be an error with the current nightly of 5.4 and because of that it's unlikely to be related to any errors reported here. |
|
@ahejlsberg react-hook-form repro: type AsyncDefaultValues<TFieldValues> = (
payload?: unknown,
) => Promise<TFieldValues>;
type DefaultValues<TFieldValues> =
TFieldValues extends AsyncDefaultValues<TFieldValues>
? Awaited<TFieldValues>
: TFieldValues;
function f<T extends Record<string, any>>(options: DefaultValues<T> | AsyncDefaultValues<T>) {
if (typeof options === 'function') {
options().then((data) => data);
}
} |
Discovered in microsoft#57117 The implementation should not `couldContainTypeVariables`--it's not intended a fast path, and should not be used in places where its unreliability can be observed. The tests stay, but with a note added that they should pass but do not.
|
I double checked qwik. The errors below are definitely caused by #56598. I manually reverted that PR's checker diff and the errors went away. I'll try to make a small repro. |
|
Regarding the new react-hook-form error, the issue is the f(() => "hello");The reason we issue an implicit any error on the Things work fine when the constraint of Other than adding a type assertion, I'm not sure what the best fix is in the react-hook-form project since new errors pop up if I just change the constraint to |
|
Here's an independent repro for qwik's use-on errors. This one fails after #56598 and passes before (where 'before' includes #56004 -- though both are required for the error to appear.) (I'll have a much smaller repro soon; this is just the first one that is independent of qwik) export type Q<TYPE = unknown> = {
// Special type brand to let eslint that the Type is serializable
__qwik_serializable__?: any;
__brand__Q__: TYPE;
/** Resolve the Q and return the actual value. */
resolve(): Promise<TYPE>;
/** The resolved value, once `resolve()` returns. */
resolved: undefined | TYPE;
getCaptured(): unknown[] | null;
getSymbol(): string;
getHash(): string;
}
type Handler<EV = Event, EL = {}> = {
bivarianceHack(event: EV, element: EL): any;
}['bivarianceHack'];
type VirtualKeys = keyof WMap
interface E { }
interface WMap {
"boo": E;
}
type AllEventsMap = WMap
type LcEvent<T extends string, C extends string = Lowercase<T>> = C extends keyof AllEventsMap
? AllEventsMap[C]
: Event;
type VirtualEvent<T extends string = VirtualKeys> =
| Q<Handler<LcEvent<T>, {}>>
| undefined;
type Stringy<LiteralType, BaseType extends null | undefined | string | number | boolean | symbol | bigint> =
| LiteralType
| (BaseType & Record<never, never>);
type VirtualEventNames = Stringy<VirtualKeys, string>; // VirtualKeys | (string & { });
declare const _virtualOn: (eventQrl: VirtualEvent<VirtualKeys>) => void;
export const virtualOn = <T extends VirtualEventNames>(eventQrl: VirtualEvent<T>) => {
_virtualOn(eventQrl); // error here where none was before
};Smaller: // interesting things:
// 1. only errors if event in EMap is all lowercase.
// 2. bivariance hack is required
// 3. Lowercase<T> is required
type EMap = { event: {} }
type Keys = keyof EMap
type EPlusFallback<C> = C extends Keys
? EMap[C]
: "unrecognised event";
type VirtualEvent<T extends string> = { bivarianceHack(event: EPlusFallback<Lowercase<T>>): any; }['bivarianceHack'];
type KeysPlusString = Keys | (string & Record<never, never>);
declare const _virtualOn: (eventQrl: VirtualEvent<Keys>) => void;
export const virtualOn = <T extends KeysPlusString>(eventQrl: VirtualEvent<T>) => {
_virtualOn(eventQrl);
}; |
|
The error is the one @RyanCavanaugh and @ahejlsberg found before-- The error seems to show that the conditional type
Also: I guess assignability to |
|
It repros for me, so maybe it's the tsconfig I'm using. I'll create a standalone repo. Example run of before/after showing no error/error |
|
Here's the standalone repo: https://github.com/sandersn/repro56598 |
|
Ok, I see the same effects with your repro. The root cause is #56004, but the issue only shows up after #56598 because that PR fixes template literal placeholder matching such that |
|
Anyway, this means the repro can be reduced to: type EMap = { event: {} }
type Keys = keyof EMap
type EPlusFallback<C> = C extends Keys ? EMap[C] : "unrecognised event";
type VirtualEvent<T extends string> = { bivarianceHack(event: EPlusFallback<Lowercase<T>>): any; }['bivarianceHack'];
declare const _virtualOn: (eventQrl: VirtualEvent<Keys>) => void;
export const virtualOn = <T extends string>(eventQrl: VirtualEvent<T>) => {
_virtualOn(eventQrl);
}; |
|
Ok, I now see what's going on. The repro checks whether With #56004, the constraint of The constraint of This is where things go wrong. We currently lack the ability to reduce unions and intersections of string literal types (like So, long story short, we can fix this issue by doing a better job reducing unions and intersections of string literal types and string mapping types with non-generic placeholders. I will look at putting up a PR. |
The following errors were reported by 5.4.0-dev.20240121, but not by 5.3.3
Pipeline that generated this bug
Logs for the pipeline run
File that generated the pipeline
This run considered 200 popular TS repos from GH (after skipping the top 0).
Successfully analyzed 115 of 200 visited repos
Investigation Status
ts-expect-errordue to #56908, Intentional isolatedModules correctness improvementThe text was updated successfully, but these errors were encountered: