TS7018 error without file and line number about typescript HOT 6 OPEN

This just looks like a bug - there shouldn't be an error in this code at all.

from typescript.

This just looks like a bug - there shouldn't be an error in this code at all.

What would be the correct behavior here? We get no implicit any error here outside of strictNullChecks (which this issue is about):

const obj = {
  prop: null, // Object literal's property 'prop' implicitly has an 'any' type.(7018)
};

In the OP's example the computed type of bar is:

const bar: {
    c?: undefined;
    p: any;
    s: any;
} | {
    c: string;
    p: string;
    s: string;
}

I guess that p and s in the first member could somehow inherit here a string type. It would require special-casing this here and investigating time in a strictNullChecks: false cases is not something I'm that interested in doing myself :P Is it even worth it at this point? Fixing error positions here seems like a reasonable solution to me.

from typescript.

What would be the correct behavior here?

To be 100% clear, the behavior I'm calling a bug is there appears to be an error on the object literal returned by the function doSthWithParams; bar seems to not be an error. If either one of the returns in that function is removed, the error in question goes away, which just feels like the kind of spooky action at a distance Ryan always harps against.

from typescript.

Anyway, if the reported behavior isn't a bug, this surely is:

function doSthWithParams(params: unknown) {
  return {
    c: 'foo',
    p: 'bar',
    s: 'baz',
  };
}

const bar = {
  p: null,
  s: null,
  ...doSthWithParams({
    p: 'hello',
    s: 'world',
  }),
};

Variable 'bar' implicitly has an '{ c: string; p: string; s: string; }' type.

Umm... wut (also note that this error names the variable bar, while the error in the OP doesn't)

from typescript.

Even more janky fun:

1. Comment out return {} in the playground from the OP
2. Observe that bar now becomes an error (the same as the one demonstrated above)
3. Uncomment the return
4. All errors are now gone!

from typescript.

I also noticed the above and I think it's fixed with my PR. I don't think it's worth looking more into it - the problem was that the error was reported on an undefined node and that should never happen. When that happens (node === undefined) a compiler-level diagnostic gets created (with file: undefined on it). I think that getDiagnosticsWorker might accidentally be dropping them here but that it only affects a situation that shouldn't exist in the first place.

from typescript.