There is a version that just tests (also called
isIntegerConstantExpression) & whereas this version is specifically used
when the value is of interest (a few call sites were actually refactored
to calling the test-only version) so let's make the API look more like
it.
Reviewers: aaron.ballman
Differential Revision: https://reviews.llvm.org/D76646
sequence on a glvalue expression.
If the sequence is supposed to perform an lvalue-to-rvalue conversion,
then one will be specified as the first conversion in the sequence.
Otherwise, one should not be invented.
DiagnosticErrorTrap is usually inappropriate because it indicates
whether an error message was rendered in a given region (and is
therefore affected by -ferror-limit and by suppression of errors if we
see an invalid declaration).
hasErrorOccurred() is usually inappropriate because it indicates
whethere an "error:" message was displayed, regardless of whether the
message was a warning promoted to an error, and therefore depends on
things like -Werror that are usually irrelevant.
Where applicable, CodeSynthesisContexts are used to attach notes to
the first diagnostic produced in a region of code, isnstead of using an
error trap and then attaching a note to whichever diagnostic happened to
be produced last (or suppressing the note if the final diagnostic is a
disabled warning!).
This is mostly NFC.
Summary:
For a none-function-like unresolved expression, clang builds a TypoExpr
for it, and tries to correct it afterwards. If the typo-correction
fails, clang just drops the whole expr.
This patch improves the recovery strategy -- if the typo-correction
fails, we preserve the AST by degrading the typo exprs to recovery
exprs.
This would improve toolings for "undef_var" broken cases:
```
void foo();
void test() {
fo^o(undef_var); // go-to-def, hover still works.
}
```
TESTED=ran tests with this patch + turn-on-recovery-ast patch, it breaks
one declare_variant_messages testcase (the diagnostics are slightly
changed), I think it is acceptable.
```
Error: 'error' diagnostics seen but not expected:
File llvm-project/clang/test/OpenMP/declare_variant_messages.cpp Line 16: expected 'match' clause on 'omp declare variant' directive
File llvm-project/clang/test/OpenMP/declare_variant_messages.cpp Line 57: expected 'match' clause on 'omp declare variant' directive
error: 'warning' diagnostics expected but not seen:
File llvm-project/clang/test/OpenMP/declare_variant_messages.cpp Line 47: the context selector 'kind' in the context set 'device' cannot have a score ('<invalid>'); score ignored
File llvm-project/clang/test/OpenMP/declare_variant_messages.cpp Line 87: the context selector 'kind' in the context set 'device' cannot have a score ('<invalid>'); score ignored
error: 'warning' diagnostics seen but not expected:
File llvm-project/clang/test/OpenMP/declare_variant_messages.cpp Line 47: the context selector 'kind' in the context set 'device' cannot have a score ('<recovery-expr>()'); score ignored
File llvm-project/clang/test/OpenMP/declare_variant_messages.cpp Line 87: the context selector 'kind' in the context set 'device' cannot have a score ('<recovery-expr>()'); score ignored
6 errors generated.
```
Reviewers: sammccall, jdoerfert
Subscribers: sstefan1, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D80733
arr is a volatile non-local array.
This fixes a recent regression exposed by removing lvalue-to-rvalue
conversion of discarded volatile arrays. In passing, regularize the
rules we use to determine whether '(void)expr;' warns when expr is a
volatile glvalue.
Summary:
Previously, we treated CXXUuidofExpr as quite a special case: it was the
only kind of expression that could be a canonical template argument, it
could be a constant lvalue base object, and so on. In addition, we
represented the UUID value as a string, whose source form we did not
preserve faithfully, and that we partially parsed in multiple different
places.
With this patch, we create an MSGuidDecl object to represent the
implicit object of type 'struct _GUID' created by a UuidAttr. Each
UuidAttr holds a pointer to its 'struct _GUID' and its original
(as-written) UUID string. A non-value-dependent CXXUuidofExpr behaves
like a DeclRefExpr denoting that MSGuidDecl object. We cache an APValue
representation of the GUID on the MSGuidDecl and use it from constant
evaluation where needed.
This allows removing a lot of the special-case logic to handle these
expressions. Unfortunately, many parts of Clang assume there are only
a couple of interesting kinds of ValueDecl, so the total amount of
special-case logic is not really reduced very much.
This fixes a few bugs and issues:
* PR38490: we now support reading from GUID objects returned from
__uuidof during constant evaluation.
* Our Itanium mangling for a non-instantiation-dependent template
argument involving __uuidof no longer depends on which CXXUuidofExpr
template argument we happened to see first.
* We now predeclare ::_GUID, and permit use of __uuidof without
any header inclusion, better matching MSVC's behavior. We do not
predefine ::__s_GUID, though; that seems like a step too far.
* Our IR representation for GUID constants now uses the correct IR type
wherever possible. We will still fall back to using the
{i32, i16, i16, [8 x i8]}
layout if a definition of struct _GUID is not available. This is not
ideal: in principle the two layouts could have different padding.
Reviewers: rnk, jdoerfert
Subscribers: arphaman, cfe-commits, aeubanks
Tags: #clang
Differential Revision: https://reviews.llvm.org/D78171
Summary: 5ade17e broke __is_pointer for Objective-C pointer types. This patch fixes the builtin and re-applies the change to type_traits.
Tags: #clang, #libc
Differential Revision: https://reviews.llvm.org/D77519
Sizeless types can't be used with "new", so it doesn't make sense
to use them with "delete" either. The SVE ACLE therefore doesn't
allow that.
This is slightly stronger than for normal incomplete types, since:
struct S;
void f(S *s) { delete s; }
is (by necessity) just a default-on warning rather than an error.
Differential Revision: https://reviews.llvm.org/D76219
new-expressions for a type T require sizeof(T) to be computable,
so the SVE ACLE does not allow them for sizeless types. At the moment:
auto f() { return new __SVInt8_t; }
creates a call to operator new with a zero size:
%call = call noalias nonnull i8* @_Znwm(i64 0)
This patch reports an appropriate error instead.
Differential Revision: https://reviews.llvm.org/D76218
Summary:
The same rules for throwing and catching incomplete types also apply
to sizeless types. This patch enforces that for throw statements.
It also make sure that we use "sizeless type" rather "incomplete type"
in the associated message. (Both are correct, but "sizeless type" is
more specific and hopefully more user-friendly.)
The SVE ACLE simply extends the rule for incomplete types to
sizeless types. However, throwing pointers to sizeless types
should not pose any real difficulty, so as an extension,
the clang implementation allows that.
Reviewers: sdesmalen, efriedma, rovka, rjmccall
Subscribers: tschuett, rkruppe, psnobl, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D76088
a dependent context.
This matches the GCC behavior.
We track the enclosing template depth when determining whether a
statement expression is within a dependent context; there doesn't appear
to be any other reliable way to determine this.
We previously assumed they were neither value- nor
instantiation-dependent under any circumstances, which would lead to
crashes and other misbehavior.
Use castAs if we know the cast should succeed (or we're dereferencing without check), the castAs will assert as well so we can remove local non-null asserts.
dependent contexts.
We previously assumed they were neither value- nor
instantiation-dependent under any circumstances, which would lead to
crashes and other misbehavior.
is ambiguous, but only one of the possible lookup results could possibly
be right.
Clang recently started diagnosing ambiguity in more cases, and this
broke the build of Firefox. GCC, ICC, MSVC, and previous versions of
Clang all accept some forms of ambiguity here (albeit different ones in
each case); this patch mostly accepts anything any of those compilers
accept.
Summary:
Right now we annotate C++'s `operator new` with `noalias` attribute,
which very much is healthy for optimizations.
However as per [[ http://eel.is/c++draft/basic.stc.dynamic.allocation | `[basic.stc.dynamic.allocation]` ]],
there are more promises on global `operator new`, namely:
* non-`std::nothrow_t` `operator new` *never* returns `nullptr`
* If `std::align_val_t align` parameter is taken, the pointer will also be `align`-aligned
* ~~global `operator new`-returned pointer is `__STDCPP_DEFAULT_NEW_ALIGNMENT__`-aligned ~~ It's more caveated than that.
Supplying this information may not cause immediate landslide effects
on any specific benchmarks, but it for sure will be healthy for optimizer
in the sense that the IR will better reflect the guarantees provided in the source code.
The caveat is `-fno-assume-sane-operator-new`, which currently prevents emitting `noalias`
attribute, and is automatically passed by Sanitizers ([[ https://bugs.llvm.org/show_bug.cgi?id=16386 | PR16386 ]]) - should it also cover these attributes?
The problem is that the flag is back-end-specific, as seen in `test/Modules/explicit-build-flags.cpp`.
But while it is okay to add `noalias` metadata in backend, we really should be adding at least
the alignment metadata to the AST, since that allows us to perform sema checks on it.
Reviewers: erichkeane, rjmccall, jdoerfert, eugenis, rsmith
Reviewed By: rsmith
Subscribers: xbolva00, jrtc27, atanasyan, nlopes, cfe-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D73380
Summary:
There was even a TODO for this.
The main motivation is to make use of call-site based
`__attribute__((alloc_align(param_idx)))` validation (D72996).
Reviewers: rsmith, erichkeane, aaron.ballman, jdoerfert
Reviewed By: rsmith
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D73020
Compute and propagate conversion kind to diagnostics helper in C++
to provide more specific diagnostics about incorrect implicit
conversions in assignments, initializations, params, etc...
Duplicated some diagnostics as errors because C++ is more strict.
Tags: #clang
Differential Revision: https://reviews.llvm.org/D74116
1) Fix a regression in llvmorg-11-init-2485-g0e3a4877840 that would
reject some cases where a class name is shadowed by a typedef-name
causing a destructor declaration to be rejected. Prefer a tag type over
a typedef in destructor name lookup.
2) Convert the "type in destructor declaration is a typedef" error to an
error-by-default ExtWarn to allow codebases to turn it off. GCC and MSVC
do not enforce this rule.
Also add extension warnings for the cases that are disallowed by the
current rules for destructor name lookup, refactor and simplify the
lookup code, and improve the diagnostic quality when lookup fails.
The special case we previously supported for converting
p->N::S<int>::~S() from naming a class template into naming a
specialization thereof is subsumed by a more general rule here (which is
also consistent with Clang's historical behavior and that of other
compilers): if we can't find a suitable S in N, also look in N::S<int>.
The extension warnings are off by default, except for a warning when
lookup for p->N::S::~T() looks for T in scope instead of in N (or N::S).
That seems sufficiently heinous to warn on by default, especially since
we can't support it for a dependent nested-name-specifier.
We would previously try to evaluate atomic constraints of non-template functions as-is,
and since they are now unevaluated at first, this would cause incorrect evaluation (bugs #44657, #44656).
Substitute into atomic constraints of non-template functions as we would atomic constraints
of template functions, in order to rebuild the expressions in a constant-evaluated context.
a temporary.
We previously failed to materialize a temporary when performing an
implicit conversion to a reference type, resulting in our thinking the
argument was a value rather than a reference in some cases.
Implement support for C++2a requires-expressions.
Re-commit after compilation failure on some platforms due to alignment issues with PointerIntPair.
Differential Revision: https://reviews.llvm.org/D50360
A TemplateIdAnnotation represents only a template-id, not a
nested-name-specifier plus a template-id. Don't make a redundant copy of
the CXXScopeSpec and store it on the template-id annotation.
This slightly improves error recovery by more properly handling the case
where we would form an invalid CXXScopeSpec while parsing a typename
specifier, instead of accidentally putting the token stream into a
broken "annot_template_id with a scope specifier, but with no preceding
annot_cxxscope token" state.
GCC supports the conditional operator on VectorTypes that acts as a
'select' in C++ mode. This patch implements the support. Types are
converted as closely to GCC's behavior as possible, though in a few
places consistency with our existing vector type support was preferred.
Note that this implementation is different from the OpenCL version in a
number of ways, so it unfortunately required a different implementation.
First, the SEMA rules and promotion rules are significantly different.
Secondly, GCC implements COND[i] != 0 ? LHS[i] : RHS[i] (where i is in
the range 0- VectorSize, for each element). In OpenCL, the condition is
COND[i] < 0 ? LHS[i]: RHS[i].
In the process of implementing this, it was also required to make the
expression COND ? LHS : RHS type dependent if COND is type dependent,
since the type is now dependent on the condition. For example:
T ? 1 : 2;
Is not typically type dependent, since the result can be deduced from
the operands. HOWEVER, if T is a VectorType now, it could change this
to a 'select' (basically a swizzle with a non-constant mask) with the 1
and 2 being promoted to vectors themselves.
While this is a change, it is NOT a standards incompatible change. Based
on my (and D. Gregor's, at the time of writing the code) reading of the
standard, the expression is supposed to be type dependent if ANY
sub-expression is type dependent.
Differential Revision: https://reviews.llvm.org/D71463
type computation, in preparation for P0388R4, which adds another few
cases here.
We now properly handle forming multi-level composite pointer types
involving nested Objective-C pointer types (as is consistent with
including them as part of the notion of 'similar types' on which this
rule is based). We no longer lose non-CVR qualifiers on nested pointer
types.
The language wording change forgot to update overload resolution to rank
implicit conversion sequences based on qualification conversions in
reference bindings. The anticipated resolution for that oversight is
implemented here -- we order candidates based on qualification
conversion, not only on top-level cv-qualifiers, including ranking
reference bindings against non-reference bindings if they differ in
non-top-level qualification conversions.
For OpenCL/C++, this allows reference binding between pointers with
differing (nested) address spaces. This makes the behavior of reference
binding consistent with that of implicit pointer conversions, as is the
purpose of this change, but that pre-existing behavior for pointer
conversions is itself probably not correct. In any case, it's now
consistently the same behavior and implemented in only one place.
This reinstates commit de21704ba9,
reverted in commit d8018233d1, with
workarounds for some overload resolution ordering problems introduced by
CWG2352.
This reverts commit de21704ba9.
Regressed/causes this to error due to ambiguity:
void f(const int * const &);
void f(int *);
int main() {
int * x;
f(x);
}
(in case it's important - the original case where this turned up was a
member function overload in a class template with, essentially:
f(const T1&)
f(T2*)
(where T1 == X const *, T2 == X))
It's not super clear to me if this ^ is expected behavior, in which case
I'm sorry about the revert & happy to look into ways to fix the original
code.
The language wording change forgot to update overload resolution to rank
implicit conversion sequences based on qualification conversions in
reference bindings. The anticipated resolution for that oversight is
implemented here -- we order candidates based on qualification
conversion, not only on top-level cv-qualifiers.
For OpenCL/C++, this allows reference binding between pointers with
differing (nested) address spaces. This makes the behavior of reference
binding consistent with that of implicit pointer conversions, as is the
purpose of this change, but that pre-existing behavior for pointer
conversions is itself probably not correct. In any case, it's now
consistently the same behavior and implemented in only one place.
implementing the resolution of CWG2352.
No functionality change, except that we now convert the referent of a
reference binding to the underlying type of the reference in more cases;
we used to happen to preserve the type sugar from the referent if the
only type change was in the cv-qualifiers.
This exposed a bug in how we generate code for trivial assignment
operators: if the type sugar (particularly the may_alias attribute)
got lost during reference binding, we'd use the "wrong" TBAA information
for the load during the assignment.
This covers:
* usual arithmetic conversions (comparisons, arithmetic, conditionals)
between different enumeration types
* usual arithmetic conversions between enums and floating-point types
* comparisons between two operands of array type
The deprecation warnings are on-by-default (in C++20 compilations); it
seems likely that these forms will become ill-formed in C++23, so
warning on them now by default seems wise.
For the first two bullets, off-by-default warnings were also added for
all the cases where we didn't already have warnings (covering language
modes prior to C++20). These warnings are in subgroups of the existing
-Wenum-conversion (except that the first case is not warned on if either
enumeration type is anonymous, consistent with our existing
-Wenum-conversion warnings).
Clang was creating a DerivedToBase ImplicitCastExpr that was also
casting between address spaces as part of the second step in the
standard conversion sequence. Defer the address space conversion to
the third step in the sequence instead, such that we get a separate
ImplicitCastExpr for the address space conversion.
Differential Revision: https://reviews.llvm.org/D70605
When throwing objects with deleted copy constructors, the copy ctor
field of the catchable type should remain null and the mangle name
changes. This already worked in simple cases, but in cases involving
non-trivial subobjects, sometimes LookupCopyingConstructor could return
a non-null but deleted constructor decl. Skip those and don't reference
them.
Fixes PR43680
See also: D67515
- For the given call expression we would end up repeatedly
trying to transform the same expression over and over again
- Fix is to keep the old TransformCache when checking for ambiguity
Differential Revision: https://reviews.llvm.org/D69060
This fixes an assertion failure in the case where an implicit conversion for a
function call involves an lvalue function conversion, and makes the AST for
initializations involving implicit lvalue function conversions more accurate.
Differential Revision: https://reviews.llvm.org/D66437
llvm-svn: 375313
The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us.
llvm-svn: 375101
Haojian Wu