Skip to content

Filter out self-fulfilling object literal member completions #35709

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

Merged
merged 1 commit into from
Dec 19, 2019
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 15 additions & 3 deletions src/services/completions.ts
Original file line number Diff line number Diff line change
Expand Up @@ -2540,18 +2540,30 @@ namespace ts.Completions {
}

function getPropertiesForObjectExpression(contextualType: Type, baseConstrainedType: Type | undefined, obj: ObjectLiteralExpression | JsxAttributes, checker: TypeChecker): Symbol[] {
const type = baseConstrainedType && !(baseConstrainedType.flags & TypeFlags.AnyOrUnknown)
? checker.getUnionType([contextualType, baseConstrainedType])
const hasBaseType = baseConstrainedType && baseConstrainedType !== contextualType;
const type = hasBaseType && !(baseConstrainedType!.flags & TypeFlags.AnyOrUnknown)
? checker.getUnionType([contextualType, baseConstrainedType!])
: contextualType;

return type.isUnion()
const properties = type.isUnion()
? checker.getAllPossiblePropertiesOfTypes(type.types.filter(memberType =>
// If we're providing completions for an object literal, skip primitive, array-like, or callable types since those shouldn't be implemented by object literals.
!(memberType.flags & TypeFlags.Primitive ||
checker.isArrayLikeType(memberType) ||
typeHasCallOrConstructSignatures(memberType, checker) ||
checker.isTypeInvalidDueToUnionDiscriminant(memberType, obj))))
: type.getApparentProperties();

return hasBaseType ? properties.filter(hasDeclarationOtherThanSelf) : properties;

// Filter out members whose only declaration is the object literal itself to avoid
// self-fulfilling completions like:
//
// function f<T>(x: T) {}
// f({ abc/**/: "" }) // `abc` is a member of `T` but only because it declares itself
function hasDeclarationOtherThanSelf(member: Symbol) {
return some(member.declarations, decl => decl.parent !== obj);
}
}

/**
Expand Down
23 changes: 23 additions & 0 deletions tests/cases/fourslash/completionsSelfDeclaring1.ts
Original file line number Diff line number Diff line change
@@ -0,0 +1,23 @@
/// <reference path="fourslash.ts" />

////interface Test {
//// keyPath?: string;
//// autoIncrement?: boolean;
////}
////
////function test<T extends Record<string, Test>>(opt: T) { }
////
////test({
//// a: {
//// keyPath: '',
//// a/**/
//// }
////})

verify.completions({
marker: "",
exact: [{
name: "autoIncrement",
sortText: completion.SortText.OptionalMember
}]
});
18 changes: 18 additions & 0 deletions tests/cases/fourslash/completionsSelfDeclaring2.ts
Original file line number Diff line number Diff line change
@@ -0,0 +1,18 @@
/// <reference path="fourslash.ts" />

////function f1<T>(x: T) {}
////f1({ abc/*1*/ });
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change looks great but do you think we should allow abc in completions if abc is some variable in scope?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, I guess don't filter our anything that could be a shorthand property declaration.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Those were never actually provided as object literal member completions, so this PR doesn’t filter them per se. I’m not sure if anything is really needed here as those completions already come up as plain text matches (I think this is provided by Monaco / VS):

image

I’m not sure if it’s right to make all in-scope identifiers first-class completions. Real missing members from the contextual type are a very strong signal that the user will want to add those members, but the presence of random identifiers is a very weak signal. We can sort them appropriately, but otherwise there’s no visual distinction that one completion is a sure thing and the other is a wild guess. I think this would get really confusing.

Besides, as I learned in #34855, with generics it can be extremely difficult to know ahead of time whether some hypothetical arbitrary member is a valid completion or not. It often appears not to be until the user adds it, when inference runs and incorporates it into the contextual type just because it’s there. But with conditional types, we effectively can’t know whether that member is going to be valid without speculatively type checking the change, which is prohibitively expensive.

////
////function f2<T extends { xyz: number }>(x: T) {}
////f2({ x/*2*/ });


verify.completions({
marker: "1",
exact: []
});

verify.completions({
marker: "2",
exact: ["xyz"]
});
25 changes: 25 additions & 0 deletions tests/cases/fourslash/completionsSelfDeclaring3.ts
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
/// <reference path="fourslash.ts" />

////function f<T extends { x: number }>(p: T & (T extends { hello: string } ? { goodbye: number } : {})) {}
////f({ x/*x*/: 0, hello/*hello*/: "", goodbye/*goodbye*/: 0, abc/*abc*/: "" })


verify.completions({
marker: "x",
exact: ["x"]
});

verify.completions({
marker: "hello",
exact: []
});

verify.completions({
marker: "goodbye",
exact: ["goodbye"]
});

verify.completions({
marker: "abc",
exact: []
});