-
Notifications
You must be signed in to change notification settings - Fork 12.8k
Completions for string literal type parameter don't work if it's constraint includes an empty string #47227
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. Weβll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
Yes that's because Sometimes you'd want to look up all possible values before you even start typing something, which you can't do in case of |
Ah, yeah then it seems the issue occurres only when you have already written |
This isn't really about an empty string but about the string literal at the argument position already matching one of the union members. The same happens here: declare const foo2: <P extends "bar" | "barbaz">(p: P) => void
foo2('bar') // we won't get autocomplete for 'barbaz' |
Ok, so the "problem" is that autocomplete here works on the "resolved signature" and since the function is generic this already includes an inferred generic: declare const foo2: <P extends "bar" | "barbaz">(p: P) => void
// signature: function foo2<"bar">(p: "bar"): void
foo2('bar') This can be verified~ when hovering over the function symbol at the call site. When the generic is not properly inferred because we have a signature applicability error then the signature is displayed like this: declare const foo2: <P extends "bar" | "barbaz">(p: P) => void
// signature: const foo2: <"bar" | "barbaz">(p: "bar" | "barbaz") => void
foo2('unknown') and that is what makes it work~. I've also looked into how this behaves with overloads and we get a full list of completions until we match one of the signatures (so basically it's very similar to single-signature functions discussed above): declare function bar1<P extends "bar" | "barbaz">(p: P): number;
declare function bar1<P extends "qwe" | "qwert">(p: P): string;
// completions: "bar" | "barbaz" | "qwe" | "qwert"
bar1('') This is thanks to the fact that Some other interesting bits:
@andrewbranch do you see any specific implementation difficulties for this? Or a rather simple heuristic could be used here? I would have to dive deeper into how different positions within the arguments list are resolved, potentially they might need the |
Isnβt this exactly what I fixed at #48410? Iβm guessing not, since youβre referring to methods and CheckModes I added there. But what youβre describing is what I remember doing π |
Ye, this is very related - the difference is that in the test case that you have added there is no overload selected because there is a mismatch between the arity of the function declaration and the supplied arguments count. So the added logic from your PR (#48410) handles that situation within |
Bug Report
π Search Terms
String literal completions, empty string constraint, intellisense
π Version & Regression Information
Tested with v4.5.4
β― Playground Link
Playground
π» Code
π Actual behavior
foo2
has no completionsπ Expected behavior
foo2
should have same completions likefoo1
which are""
,"bar"
,"baz"
The text was updated successfully, but these errors were encountered: