Skip to content

String literal overload does not provide completion when undefined or void parameter present #14333

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

Closed
NoelAbrahams opened this issue Feb 27, 2017 · 1 comment
Labels
Duplicate An existing issue was already created

Comments

@NoelAbrahams
Copy link

TypeScript Version: 2.2

Code

type Options = {
        text: string;
};

// Demonstrates fail with undefined
interface Foo {
    foo(kind: 'Bar', state?: undefined): void;
    foo(kind: 'Foo', state?: Options): void;
}

let f: Foo;
f.foo('Foo', { t }) // No completion offered for 't'

// Demonstrates fail with void
interface Foo2 {
    foo(kind: 'Bar', state?: void): void;
    foo(kind: 'Foo', state?: Options): void;
}

let ff: Foo2;
ff.foo('Foo', { t  }) // No completion here either

// Demonstrates success after changing order of overloads
interface Foo3 {
    foo(kind: 'Foo', state?: Options): void;
    foo(kind: 'Bar', state?: undefined): void;
}

let fff: Foo3;
fff.foo('Foo', { t }) // Okay: completion offered for 't'

Expected behavior:

Completion for the property "text" where it says "No completion offered for 't'"

Actual behavior:

There is no completion for "text" when "t" is typed.

@mhegazy mhegazy added Bug A bug in TypeScript Help Wanted You can do this Domain: Completion Lists The issue relates to showing completion lists in an editor Good First Issue Well scoped, documented and has the green light and removed Help Wanted You can do this Bug A bug in TypeScript Domain: Completion Lists The issue relates to showing completion lists in an editor Good First Issue Well scoped, documented and has the green light labels Feb 27, 2017
@mhegazy
Copy link
Contributor

mhegazy commented Feb 27, 2017

This is a design limitation I am afraid. The completion list logic does an overload resolution first, it just happens that neither signatures match when you are typing the object literal, the result is picking the first, it happens that the first has no useful completions.

This is a side effect of the issue tracked by #10523; if/when #10523 is fixed, this should just work.

@mhegazy mhegazy added the Duplicate An existing issue was already created label Feb 27, 2017
@mhegazy mhegazy closed this as completed Apr 21, 2017
@microsoft microsoft locked and limited conversation to collaborators Jun 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Duplicate An existing issue was already created
Projects
None yet
Development

No branches or pull requests

2 participants