Add some helpers to better check Scope's kind. NFC

Signed-off-by: Jun Zhang <[email protected]>

[HLSL] Pointers are unsupported in HLSL

HLSL does not support pointers or references. This change generates
errors in sema for generating pointer, and reference types as well as
common operators (ad

[HLSL] Pointers are unsupported in HLSL

HLSL does not support pointers or references. This change generates
errors in sema for generating pointer, and reference types as well as
common operators (address-of, dereference, arrow), which are used with
pointers and are unsupported in HLSL.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D123167

show more ...

Don't diagnostic atomic object access as UB in an unevaluated context

We started diagnosing this situation with a more clear diagnostic
message, but it was pointed out that unevaluated contexts don'

Don't diagnostic atomic object access as UB in an unevaluated context

We started diagnosing this situation with a more clear diagnostic
message, but it was pointed out that unevaluated contexts don't really
have the undefined behavior property as there is no runtime access
involved.

This augments the changes in https://reviews.llvm.org/D122656 to not
diagnose in an unevaluated context.

show more ...

[C11] Improve the diagnostic when accessing a member of an atomic struct

Member access for an atomic structure or union is unconditional
undefined behavior (C11 6.5.2.3p5). However, we would issue a

[C11] Improve the diagnostic when accessing a member of an atomic struct

Member access for an atomic structure or union is unconditional
undefined behavior (C11 6.5.2.3p5). However, we would issue a confusing
error message about the base expression not being a structure or union
type.

GCC issues a warning for this case. Clang now warns as well, but the
warning is defaulted to an error because the actual access is still
unsafe.

This fixes Issue 54563.

show more ...

[Clang] Allow "ext_vector_type" applied to Booleans

This is the `ext_vector_type` alternative to D81083.

This patch extends Clang to allow 'bool' as a valid vector element type
(attribute ext_vecto

[Clang] Allow "ext_vector_type" applied to Booleans

This is the `ext_vector_type` alternative to D81083.

This patch extends Clang to allow 'bool' as a valid vector element type
(attribute ext_vector_type) in C/C++.

This is intended as the canonical type for SIMD masks and facilitates
clean vector intrinsic declarations. Vectors of i1 are supported on IR
level and below down to many SIMD ISAs, such as AVX512, ARM SVE (fixed
vector length) and the VE target (NEC SX-Aurora TSUBASA).

The RFC on cfe-dev: https://lists.llvm.org/pipermail/cfe-dev/2020-May/065434.html

Reviewed By: erichkeane

Differential Revision: https://reviews.llvm.org/D88905

show more ...

[clang] Don't typo-fix an expression in a SFINAE context.

If this is a SFINAE context, then continuing to look up names
(in particular, to treat a non-function as a function, and then
do ADL) might

[clang] Don't typo-fix an expression in a SFINAE context.

If this is a SFINAE context, then continuing to look up names
(in particular, to treat a non-function as a function, and then
do ADL) might too-eagerly complete a type that it's not safe to
complete right now. We should just say "okay, that's a substitution
failure" and not do any more work than absolutely required.

Fixes #52970.

Differential Revision: https://reviews.llvm.org/D117603

show more ...

Revert "[clang] Don't typo-fix an expression in a SFINAE context."

This reverts commit 9be5f4d5afd9a1b6e88a268f6ea6eb282d77d9fe.

I'm not sure if this caused
https://lab.llvm.org/buildbot/#/builder

Revert "[clang] Don't typo-fix an expression in a SFINAE context."

This reverts commit 9be5f4d5afd9a1b6e88a268f6ea6eb282d77d9fe.

I'm not sure if this caused
https://lab.llvm.org/buildbot/#/builders/60/builds/6350
https://lab.llvm.org/buildbot/#/builders/119/builds/7433
but I'm acting as if it did.

show more ...

[clang] Don't typo-fix an expression in a SFINAE context.

If this is a SFINAE context, then continuing to look up names
(in particular, to treat a non-function as a function, and then
do ADL) might

[clang] Don't typo-fix an expression in a SFINAE context.

If this is a SFINAE context, then continuing to look up names
(in particular, to treat a non-function as a function, and then
do ADL) might too-eagerly complete a type that it's not safe to
complete right now. We should just say "okay, that's a substitution
failure" and not do any more work than absolutely required.

Fixes #52970.

Differential Revision: https://reviews.llvm.org/D117603

show more ...

[Sema] Fix the assertion in Sema::ActOnDependentMemberExpr

617007240cbfb97c introduced the use of ActOnDependentMemberExpr with
variable template specialization. The assertion inside
ActOnDependentM

[Sema] Fix the assertion in Sema::ActOnDependentMemberExpr

617007240cbfb97c introduced the use of ActOnDependentMemberExpr with
variable template specialization. The assertion inside
ActOnDependentMemberExpr should be adjusted accordingly.

Fixes https://bugs.llvm.org/show_bug.cgi?id=47211

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D113146

show more ...

[clang] fix typo correction not looking for candidates in base classes.

RecordMemberExprValidator was not looking through ElaboratedType
nodes when looking for candidates which occur in base classes

[clang] fix typo correction not looking for candidates in base classes.

RecordMemberExprValidator was not looking through ElaboratedType
nodes when looking for candidates which occur in base classes.

Signed-off-by: Matheus Izvekov <[email protected]>

Reviewed By: rsmith

Differential Revision: https://reviews.llvm.org/D111830

show more ...

Implement if consteval (P1938)

Modify the IfStmt node to suppoort constant evaluated expressions.

Add a new ExpressionEvaluationContext::ImmediateFunctionContext to
keep track of immediate function

Implement if consteval (P1938)

Modify the IfStmt node to suppoort constant evaluated expressions.

Add a new ExpressionEvaluationContext::ImmediateFunctionContext to
keep track of immediate function contexts.

This proved easier/better/probably more efficient than walking the AST
backward as it allows diagnosing nested if consteval statements.

show more ...

[OpenCL] Enables .rgba vector extension in C++ for OpenCL 2021

`.rgba` vector extension setting in C++ for OpenCL 2021 is now
performed analogously to OpenCL C 3.0. Test case added.

Differential Re

[OpenCL] Enables .rgba vector extension in C++ for OpenCL 2021

`.rgba` vector extension setting in C++ for OpenCL 2021 is now
performed analogously to OpenCL C 3.0. Test case added.

Differential Revision: https://reviews.llvm.org/D109370

show more ...

Use DeclContext::getNonTransparentContext(); NFC

[clang] NFC: Rename rvalue to prvalue

This renames the expression value categories from rvalue to prvalue,
keeping nomenclature consistent with C++11 onwards.

C++ has the most complicated taxonomy

[clang] NFC: Rename rvalue to prvalue

This renames the expression value categories from rvalue to prvalue,
keeping nomenclature consistent with C++11 onwards.

C++ has the most complicated taxonomy here, and every other language
only uses a subset of it, so it's less confusing to use the C++ names
consistently, and mentally remap to the C names when working on that
context (prvalue -> rvalue, no xvalues, etc).

Renames:
* VK_RValue -> VK_PRValue
* Expr::isRValue -> Expr::isPRValue
* SK_QualificationConversionRValue -> SK_QualificationConversionPRValue
* JSON AST Dumper Expression nodes value category: "rvalue" -> "prvalue"

Signed-off-by: Matheus Izvekov <[email protected]>

Reviewed By: rsmith

Differential Revision: https://reviews.llvm.org/D103720

show more ...

[OpenCL] Accept .rgba in OpenCL 3.0

The .rgba vector component accessors are supported in OpenCL C 3.0.

Previously, the diagnostic would check `OpenCLVersion` for version 2.2
(value 220) and report

[OpenCL] Accept .rgba in OpenCL 3.0

The .rgba vector component accessors are supported in OpenCL C 3.0.

Previously, the diagnostic would check `OpenCLVersion` for version 2.2
(value 220) and report those accessors are an OpenCL 2.2 feature.
However, there is no "OpenCL C version 2.2", so change the check and
diagnostic text to 3.0 only.

A spurious `OpenCLVersion` argument was passed into the diagnostic;
remove that.

Differential Revision: https://reviews.llvm.org/D99969

show more ...

Don't directly dereference getAs<> casts to avoid potential null dereferences. NFCI.

Replace with castAs<> which asserts the cast is valid.

Fixes a number of static analyzer warnings.

[clang] Fix noderef for AddrOf on MemberExpr

Committing on behalf of thejh (Jann Horn).

As part of this change, one existing test case has to be adjusted
because it accidentally stripped the NoDere

[clang] Fix noderef for AddrOf on MemberExpr

Committing on behalf of thejh (Jann Horn).

As part of this change, one existing test case has to be adjusted
because it accidentally stripped the NoDeref attribute without
getting caught.

Depends on D92140

Differential Review: https://reviews.llvm.org/D92141

show more ...

[clang] Fix noderef for array member of deref expr

Committing on behalf of thejh (Jann Horn).

Given an attribute((noderef)) pointer "p" to the struct

struct s { int a[2]; };
ensure

[clang] Fix noderef for array member of deref expr

Committing on behalf of thejh (Jann Horn).

Given an attribute((noderef)) pointer "p" to the struct

struct s { int a[2]; };
ensure that the following expressions are treated the same way by the
noderef logic:

p->a
(*p).a
Until now, the first expression would be treated correctly (nothing is
added to PossibleDerefs because CheckMemberAccessOfNoDeref() bails out
on array members), but the second expression would incorrectly warn
because "*p" creates a PossibleDerefs entry.

Handle this case the same way as for the AddrOf operator.

Differential Revision: https://reviews.llvm.org/D92140

show more ...

Ignore noderef attribute in unevaluated context

The noderef attribute is for catching code that accesses pointers in
a different address space. Unevaluated code is always safe in that regard.

Improve modeling of variable template specializations with dependent
arguments.

Don't build a variable template specialization declaration until its
scope and template arguments are non-dependent.

Improve modeling of variable template specializations with dependent
arguments.

Don't build a variable template specialization declaration until its
scope and template arguments are non-dependent.

No functionality change intended, but the AST representation is now more
consistent with how we model other templates.

show more ...

Don't form a 'context-independent expr' reference to a member during
name annotation.

Instead, defer forming the member access expression or DeclRefExpr until
we build the use of ClassifyName's resu

Don't form a 'context-independent expr' reference to a member during
name annotation.

Instead, defer forming the member access expression or DeclRefExpr until
we build the use of ClassifyName's result. Just build an
UnresolvedLookupExpr to track the LookupResult until we're ready to
consume it.

This also reverts commit 2f7269b6773de2750f9cd1417ef5f21cd6cf7a91 (other
than its testcase). That change was an attempted workaround for the same
problem.

show more ...

Resolve exception specifications after marking the corresponding
function as referenced, not before.

No functionality change intended. This is groundwork for computing the
exception specification of

Resolve exception specifications after marking the corresponding
function as referenced, not before.

No functionality change intended. This is groundwork for computing the
exception specification of a defaulted comparison, for which we'd like
to use the implicit body where possible.

show more ...

Silence static analyzer getAs<RecordType> null dereference warnings. NFCI.

The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<Record

Silence static analyzer getAs<RecordType> null dereference warnings. NFCI.

The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<RecordType> directly and if not assert will fire for us.

llvm-svn: 373584

show more ...

[Clang] Migrate llvm::make_unique to std::make_unique

Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
o

[Clang] Migrate llvm::make_unique to std::make_unique

Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.

Differential revision: https://reviews.llvm.org/D66259

llvm-svn: 368942

show more ...

[Sema] Actually map a variable template specialization from pattern to instantiation

We were previously just using a specialization in the class template instead of
creating a new specialization in

[Sema] Actually map a variable template specialization from pattern to instantiation

We were previously just using a specialization in the class template instead of
creating a new specialization in the class instantiation.

Fixes llvm.org/PR42779.

Differential revision: https://reviews.llvm.org/D65359

llvm-svn: 367367

show more ...