[PATCH] D146971: [Sema] Populate declarations inside TypeLocs for some invalid types
Ilya Biryukov via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Mon Mar 27 08:33:05 PDT 2023
ilya-biryukov added a comment.
In D146971#4224465 <https://reviews.llvm.org/D146971#4224465>, @erichkeane wrote:
> One other thing we probably should do is have an assert when creating a function type that none of its params are null. WDYT?
This would definitely be great, however I don't think this is possible without some large redesign.
Currently, `FunctionType` does not store parameter decls. Instead, they are stored in the `FunctionTypeLoc`.
The latter gets created by allocating <https://github.com/llvm/llvm-project/blob/5f34259609f604bfcd5cbf324a32d265e6a5d347/clang/lib/AST/ASTContext.cpp#L3087> the necessary number of bytes and filling the empty state.
In principle, it would be much easier if `FuncionTypeLoc` and `FunctionType` were created in parallel, ensuring consistency there would be much easier. I have also though about this, but this looks like a large change and I didn't explore further.
================
Comment at: clang/lib/Sema/SemaType.cpp:5949
assert(!T.isNull() && "T must not be null at the end of this function");
- if (D.isInvalidType())
+ if (!AreDeclaratorChunksValid)
return Context.getTrivialTypeSourceInfo(T);
----------------
erichkeane wrote:
> Shouldn't the `D.setInvalidType(true)` in each of the branches work here? So this variable is unnecessary? Else this is a good change IMO.
(Let me know if I'm misreading the suggestion, I was not sure if my understanding is correct).
If we call `setInvalidType` more, we would actually get more crashes as the problematic branch is the one that calls `getTrivialTypeSourceInfo`.
To avoid the extra variable, we could instead ensure that the type always gets replaced with something trivial `T = Context.IntTy`. But I didn't want to go this path because this causes worse error recovery (going from something like `void(<recovered-to:int>)` to `<recovered-to:int>`) and possibly correctness issues (e.g. will we start getting function-decls or lambdas that do not have function types and other assertions may fire).
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D146971/new/
https://reviews.llvm.org/D146971
More information about the cfe-commits
mailing list