[PATCH] D116326: [CodeCompletion] Signature help for aggregate initialization.

Kadir Cetinkaya via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Jan 4 00:47:07 PST 2022


kadircet added inline comments.


================
Comment at: clang/include/clang/Sema/CodeCompleteConsumer.h:1085
+    const RecordDecl *getAggregate() const {
+      return getKind() == CK_Aggregate ? AggregateType : nullptr;
+    }
----------------
either assert the kind and return `AggregateType` or change the callers below to not explicitly check for kind (and directly check if returned RecordDecl is not-null).


================
Comment at: clang/lib/Sema/CodeCompleteConsumer.cpp:568
+
+  if (const auto *FD = getFunction()) {
+    if (N < FD->param_size())
----------------
this doesn't cover the function(proto)type case


================
Comment at: clang/lib/Sema/CodeCompleteConsumer.cpp:522
+    if (const auto *CRD = dyn_cast<CXXRecordDecl>(AggregateType))
+      Count += CRD->getNumBases();
+    return Count;
----------------
sammccall wrote:
> kadircet wrote:
> > i think this is only valid for c++17 onwards `If the number of initializer clauses exceeds the number of members and bases (since C++17) to initialize, the program is ill-formed.` (same for param type/decl)
> > 
> > it gets even more complicated, since one doesn't have to nest initialization of base class fields, e.g this is valid:
> > ```
> > struct X
> > {
> >     int a;
> >     int b;
> > };
> > 
> > struct Y : X
> > {
> >     int c;
> > };
> > 
> > Y y1{ {1,2}, 3};
> > Y y2{ 1, 2, 3 }; // both of these set a=1, b=2, c=3
> > ```
> > i think this is only valid for c++17 onwards
> 
> We only get here for aggregate types, and pre-C++17 those are guaranteed to have no bases.
> 
> > one doesn't have to nest initialization of base class fields
> 
> Great catch, somehow I missed this in the spec. This makes things very complicated. Why on earth is this allowed?! (After some digging, compatibility with C99)
> 
> I can't see a reasonable way to support this. If it were just bases I'd drop support for them, but it applies to fields too.
> The implementation difficulty is having to do full conversion-sequence checks for each element to tell whether it is a standalone element or the first in an implied nested list.
> 
> This elision is slightly discouraged (-Wmissing-braces in in -Wall) so I think it's OK to give results that are going to be a bit off if brace-elision is used.
> If there are a lot of complaints we could try to detect this in future.
> 
> 
> This elision is slightly discouraged (-Wmissing-braces in in -Wall) so I think it's OK to give results that are going to be a bit off if brace-elision is used.
If there are a lot of complaints we could try to detect this in future.

As discussed offline I second this.


================
Comment at: clang/lib/Sema/SemaCodeComplete.cpp:3826
     Result.AddTextChunk(Result.getAllocator().CopyString(OS.str()));
-  } else {
+  } else if (Proto) {
     Result.AddResultTypeChunk(Result.getAllocator().CopyString(
----------------
isn't this and the following case actually the same? can't we just use the return type inside functiontype ?


================
Comment at: clang/lib/Sema/SemaCodeComplete.cpp:5884
+    QualType CandidateParamType = Candidate.getParamType(N);
+    if (!CandidateParamType.isNull()) {
+      if (ParamType.isNull())
----------------
nit: early exit


================
Comment at: clang/lib/Sema/SemaCodeComplete.cpp:6029
+static llvm::Optional<unsigned>
+getNextAggregateIndexAfterDesignatedInit(const ResultCandidate &Aggregate,
+                                         ArrayRef<Expr *> Args) {
----------------
assert that `Aggregate` is of right kind?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116326



More information about the cfe-commits mailing list