Quickinfo for contextually typed arrow function parameter can be incorrect

[weswigham]

TypeScript Version: 2.7.0-dev.201xxxxx

Search Terms:

Code

interface BaseProps<T> {
  initialValues: T;
  nextValues: (cur: T) => T;
}
declare class Component<P> { constructor(props: P); props: P; }
declare class GenericComponent<Props = {}, Values = object>
    extends Component<Props & BaseProps<Values>> {
  iv: Values;
}

new GenericComponent({ initialValues: 12, nextValues: val => 12 });

Expected behavior:
Hover over val - see number. (Also: type val. in the lambda body and trigger completions, get completions for numbers). Hover over nextValues, see (val: number) => number.

Actual behavior:
val's quick info is any (compilation and errors show it is assigned the correct type during compilation, the quick info on GenericComponent is thankfully correct), has no completions (being any), and nextValues has a quickinfo type of (cur: number) => number & (val: number) => number, which is an intersection of two conspicuously identical signatures.

Playground Link (Also, here's a fourslash test to start anyone working on this off)

Preliminary investigation (read: believing this bug was related to JSX before trying the same construct outside a JSX tag) led me to believe this has something to do with execution order, as inference statefully assigns types to symbols via assignTypeToParameterAndFixTypeParameters, meaning if inference happens it assigns a type to the symbol, whereas if that hasn't happened and there's no cached type from an inference triggered by a check call, quickinfo only finds the contextual type for the position. However requesting errors (which does a full typecheck) prior to checking quickinfo doesn't hide the error (which would be expected if the issue depended on execution order), so I'm unsure what the underlying problem is. The correct types are returned at these positions for our .types baselines by getTypeAtLocation, which, in these cases, is just a roundabout way to say getTypeOfSymbol on the node's symbol, which is the same as getTypeOfSymbolAtLocation in these locations (which is what's used in services).

[sandersn]

Doesn’t sound like there is any order-dependent behaviour here (if I read your description right), so I guess it makes sense that the implementation wouldn’t have an order-dependent bug.

[weswigham]

Well, differing results between .types baselines and quickinfo can be caused by order dependence, but I don't think it's the case here, since guaranteeing a full typechecked before fetching quickinfo doesn't suppress the issue.