[PATCH] D73271: [clang][CodeComplete] Support for designated initializers

Kadir Cetinkaya via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon Jan 27 06:21:28 PST 2020


kadircet marked 7 inline comments as done.
kadircet added inline comments.


================
Comment at: clang/lib/Parse/ParseDecl.cpp:2463
 
+    PreferredType.enterVariableInit(Tok.getLocation(), ThisDecl);
     ExprResult Init(ParseBraceInitializer());
----------------
sammccall wrote:
> oops, I missed where this was happening.
> 
> There are lots of non-vardecl cases where we might use a designated init.
> We won't necessarily know the type in all of them, but it'd be good to at least cover the cases where we do. (Particularly `ty{...}`)
see tests for more cases we handle


================
Comment at: clang/lib/Parse/ParseInit.cpp:162
+ExprResult Parser::ParseInitializerWithPotentialDesignator(
+    llvm::function_ref<void(const Designation &)> CodeCompleteCB) {
 
----------------
sammccall wrote:
> This callback stuff doesn't seem so idiomatic in the parser from what I've seen - can we be a bit more direct and just pass the location?
it is not just the location though, we are also lacking the information regarding initializers seen so far. there are other occurrences of this callback mechanisms while parsing parenthesized expressions, for similar reasons, lacking the bigger picture. I think it is better to keep those element parsing functions unaware of the outer state, since they mostly don't care or depend on it.


================
Comment at: clang/lib/Sema/SemaCodeComplete.cpp:4731
 
+static RecordDecl *getAsRecordDecl(const QualType BaseType) {
+  if (const RecordType *Record = BaseType->getAs<RecordType>())
----------------
sammccall wrote:
> sammccall wrote:
> > this needs a name and/or comment to describe how it falls back to the primary template if the decl for the specialization isn't known.
> > (From the name, you can't tel how it's different from Type::getRecordDecl)
> as discussed offline, this doesn't handle null, neither does the new caller
handling it in the new caller instead, as discussed previous caller technically can't have an incomplete type when it reaches this code path.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D73271/new/

https://reviews.llvm.org/D73271





More information about the cfe-commits mailing list