================
@@ -8192,6 +8192,14 @@ ExprResult InitializationSequence::Perform(Sema &S,
Kind.getRange().getEnd());
} else {
CurInit = new (S.Context) ImplicitValueInitExpr(Step->Type);
+ // Note the return value isn't used to return early
+ // to preserve the AST as best as possible even though an error
+ // might have occurred. For struct initialization it also allows
+ // all field assignments to be checked rather than bailing on the
+ // first error.
+ S.BoundsSafetyCheckInitialization(Entity, Kind, Sema::AA_Initializing,
+ /*LHSType=*/Step->Type,
+ /*RHSExpr=*/CurInit.get());
----------------
delcypher wrote:
This is here for clarify because it really isn't obvious that `Step->Type`
means the LHS type (similarly for the other parameters).
The style guide says:
https://llvm.org/docs/CodingStandards.html#comment-formatting
---
> When documenting the significance of constants used as actual parameters in a
> call. This is most helpful for bool parameters, or passing 0 or nullptr. The
> comment should contain the parameter name, which ought to be meaningful. For
> example, it’s not clear what the parameter means in this call:
```
Object.emitName(nullptr);
```
> An in-line C-style comment makes the intent obvious:
```
Object.emitName(/*Prefix=*/nullptr);
```
---
So you're right that it's encouraged for constant arguments which isn't the
case here. I'll drop the comments.
https://github.com/llvm/llvm-project/pull/106321
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
