================
@@ -2286,6 +2286,9 @@ ExprResult Sema::BuildCXXNew(SourceRange Range, bool
UseGlobal,
bool PassAlignment = getLangOpts().AlignedAllocation &&
Alignment > NewAlignment;
+ if (CheckArgsForPlaceholders(PlacementArgs))
----------------
Sirraide wrote:
The only expressions that this seems to affect is expressions for which
`isPlaceholderToRemoveAsArg` returns `true` by passing them to
`CheckPlaceholderExpr`; this only affects a handful of types:
- `BuiltinType::PseudoObject`: MSProperty (subscript) properties and ObjC
(subscript) properties; the latter are only relevant for Objective-C++ in this
case. I’ll add tests for the latter as well (to the best of my abilities as I
have never written a line of Objective-C or Objective-C++ before in my life).
The comment in `BuiltinTypes.def` also mentions ‘VS.NET's `__property`
declarations’, but I couldn’t find anything about `__property` in the rest of
the codebase, and I’m candidly not entirely sure what this is in reference to,
so I’m only adding tests for Objective-C++ for now.
- `BuiltinType::UnknownAny`: For this, `CheckPlaceholderExpr` just emits an
error, and I personally don’t see a way in which this would ever be valid as a
placement-arg to a new expression, but I could be wrong here. Should we add
tests for this case?
- `BuiltinType::BoundMember`: `s.foo` and friends, where `foo` is a non-static
member function; these are already invalid in placement-args, and
`CheckPlaceholderExpr` similarly issues what looks to be the exact same error;
we don’t seem to have any tests that check for this error, however, so I’ll add
some for this as well.
- `BuiltinType::BuiltinFn`: Only `DeclRefExpr`s are affected here as this
simply issues an error otherwise (which should be fine because passing a
builtin function as a function argument doesn’t make sense anyway); if it is a
builtin such as `__builtin_memset`, then this pr also ends up improving the
error message from ‘no known conversion from '<builtin fn type>'’ to ‘builtin
functions must be directly called’.
If it is a `DeclRefExpr`, there are two cases to consider: the first is the
MS `__noop` builtin, which w/o this pr simply errors, but now, it is implicitly
converted to a `CallExpr` that returns an `int` (which emits 0 in CG); this
matches MSVCs behaviour, but I doubt we have a test for that, so I’ll add one
as well.
The only other case that is affected here is if we have a
standard-namespace builtin (e.g. `std::move`, `std::forward_like`, which before
C++20 resulted in a warning, since C++ in an error; this behaviour is
unaffected by this change, but I’ll some tests for this as well because from
what I can tell, there currently are no tests for this diagnostic at all.
- `BuiltinType::IncompleteMatrixIdx`: From what I can tell, this is used for
[matrix types](https://clang.llvm.org/docs/MatrixTypes.html), specifically, for
the type of an expression such as `a[1]` where `a` is a matrix type because
matrix types always require two subscripts; since an expression of this type as
a placement-arg is thus always invalid, this should error, but previously, we
were emitting a less-than-ideal error (e.g. ‘no known conversion from
'<incomplete matrix index type>' to 'int'’), whereas with this pr, we now get
the error ‘single subscript expressions are not allowed for matrix values’.
There does not seem to be a test for this that involves placement-new, so I’ll
add a few as well.
- `BuiltinType::OMPArraySection`, `BuiltinType::OMPArrayShaping`, and
`BuiltinType::OMPIterator`: To my understanding, these cannot occur outside of
OMP `#pragma`s, so they’re not relevant here.
https://github.com/llvm/llvm-project/pull/75883
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
