This is an archive of the discontinued LLVM Phabricator instance.

[CodeComplete] Guess type for designated initializers
ClosedPublic

Authored by sammccall on Feb 4 2021, 9:42 AM.

Details

Summary

This enables:

  • completion in { .x.^ }
  • completion in { .x = { .^ } }
  • type-based ranking of candidates for { .x = ^ }

Diff Detail

Event Timeline

sammccall requested review of this revision.Feb 4 2021, 9:42 AM
sammccall created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptFeb 4 2021, 9:42 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
kadircet accepted this revision.Feb 4 2021, 11:17 AM

Thanks! LG with a small concern around possible effects on member completions for uninstantiated templates.

clang/lib/Parse/ParseInit.cpp
163

it might be nice to make the whole preferredtypebuilder a no-op on construction when codecompletion is disabled. but that can be an adventure for another day.

clang/lib/Sema/SemaCodeComplete.cpp
4803

i think this means we are going to offer completion for uninstantiated specializations using the primary template now (through Sema::CodeCompleteMemberReferenceExpr), which i am not sure is possible, but should be an improvement in either case.

but not having any tests (especially failing) makes me a little anxious.

5790

why don't we break after the first one ?

This revision is now accepted and ready to land.Feb 4 2021, 11:17 AM
sammccall marked an inline comment as done.Feb 4 2021, 1:17 PM
sammccall added inline comments.
clang/lib/Parse/ParseInit.cpp
163

Agree, this felt awkward. There's already a laziness mechanism (the function-arg stuff) but it doesn't quite fit for this case.

clang/lib/Sema/SemaCodeComplete.cpp
4803

I think this case is vacuous for CodeCompleteMemberExpr, like you say.

Before calling CodeCompleteMemberExpr, we call ActOnStartCXXMemberReference. If it's a non-dependent record type, then it calls RequireCompleteType, which will try to instantiate the template. If this fails, then we bail out and never invoke code completion.

So I think there's no change in behavior for member completion, and thus can't produce a test for it. The reason for moving the fallback case into this function is that instead of 2 callsites where 1 needed the fallback, we now have 3 callsites where 2 need it. So it seems less awkward to factor this way.

This revision was landed with ongoing or failed builds.Feb 4 2021, 1:17 PM
This revision was automatically updated to reflect the committed changes.