-
Notifications
You must be signed in to change notification settings - Fork 12.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. Weβll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Completions for string literal type parameter don't work if it's constraint includes an empty string #47227
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: