================
@@ -1449,7 +1449,10 @@ void InitListChecker::CheckSubElementType(const
InitializedEntity &Entity,
// dependent non-array type or an array type with a value-dependent
// bound
assert(AggrDeductionCandidateParamTypes);
- if (!isa_and_nonnull<ConstantArrayType>(
+ // Don't consider the brace elision if the initializer is a
+ // braced-init-list.
+ if (isa<InitListExpr, DesignatedInitExpr>(expr) ||
----------------
zyn0217 wrote:
Thanks for the writeup! This matches what I thought.
A few more comments:
> as the e1 has a dependent type we can't perform semantic checks to see
> whether the T t[2] can be initialized by x1, we always assume true here.
Yeah. For the case above, and as per
[P2081](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2082r1.pdf)'s
purposes, brace elision should be considered on arrays (possibly
type-dependent, but the bound should be non-dependent), and what we used to do
here is to always fall through to the brace elision logic below regardless of
the presence of braces within the corresponding initializer `e`. And this
results in issues of not having proper deduction guides.
> This has an effect that we will generate the deduction guide even for invalid
> case e.g. x1 is {1, 2, 3} ...
Yep, we don't guard against invalid initializers here because the
`InitListChecker` is merely employed to generate "candidate" parameters. (where
we set `VerifyOnly` to true)
https://github.com/llvm/llvm-project/pull/94889
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
