Restrict use of references to functions as they can
result in non-conforming behavior.
Tags: #clang
Differential Revision: https://reviews.llvm.org/D95442
This change makes `DeclarationNameLoc` a proper class and refactors its
users to use getter methods instead of accessing the members directly.
The change also makes `DeclarationNameLoc` immutable (i.e., it cannot
be modified once constructed).
Reviewed By: aprantl
Differential Revision: https://reviews.llvm.org/D94596
default arguments.
When a function is declared with a qualified name, its eventual semantic
DeclContext may differ from the scope specified by the qualifier if it
redeclares a function in an inline namespace. In this case, we need to
update the DeclContext to be that of the previous declaration, and we
need to do so before we decide whether to inherit default arguments from
that previous declaration, because we only inherit default arguments
from declarations in the same scope.
Currently, there are many instances where `SourceLocation` objects are
converted to raw representation to be stored in structs that are
used as fields of tagged unions.
This is done to make the corresponding structs trivial.
Triviality allows avoiding undefined behavior when implicitly changing
the active member of the union.
However, in most cases, we can explicitly construct an active member
using placement new. This patch adds the required active member
selections and replaces `SourceLocation`-s represented as
`unsigned int` with proper `SourceLocation`-s.
One notable exception is `DeclarationNameLoc`: the objects of this class
are often not properly initialized (so the code currently relies on
its default constructor which uses memset). This class will be fixed
in a separate patch.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D94237
Introduce a function attribute 'enforce_tcb' that prevents the function
from calling other functions without the same attribute. This allows
isolating code that's considered to be somehow privileged so that it could not
use its privileges to exhibit arbitrary behavior.
Introduce an on-by-default warning '-Wtcb-enforcement' that warns
about violations of the above rule.
Introduce a function attribute 'enforce_tcb_leaf' that suppresses
the new warning within the function it is attached to. Such leaf functions
may implement common functionality between the trusted and the untrusted code
but they require extra careful audit with respect to their capabilities.
Fixes after a revert in 419ef38a50293c58078f830517f5e305068dbee6:
Fix a test.
Add workaround for GCC bug (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67274).
Attribute the patch appropriately!
Differential Revision: https://reviews.llvm.org/D91898
Introduce a function attribute 'enforce_tcb' that prevents the function
from calling other functions without the same attribute. This allows
isolating code that's considered to be somehow privileged so that it could not
use its privileges to exhibit arbitrary behavior.
Introduce an on-by-default warning '-Wtcb-enforcement' that warns
about violations of the above rule.
Introduce a function attribute 'enforce_tcb_leaf' that suppresses
the new warning within the function it is attached to. Such leaf functions
may implement common functionality between the trusted and the untrusted code
but they require extra careful audit with respect to their capabilities.
Differential Revision: https://reviews.llvm.org/D91898
The ordered comparison operators are defined for the SourceLocation
class, so SourceLocation objects can be compared directly. There is no
need to extract the internal representation for comparison.
Reviewed By: aprantl
Differential Revision: https://reviews.llvm.org/D94231
The new clang internal extension '__cl_clang_function_pointers'
allows use of function pointers and other features that have
the same functionality:
- Use of member function pointers;
- Unrestricted use of references to functions;
- Virtual member functions.
This not a vendor extension and therefore it doesn't require any
special target support. Exposing this functionality fully
will require vendor or Khronos extension.
Tags: #clang
Differential Revision: https://reviews.llvm.org/D94021
Pointers to member functions are a special case
of function pointers and therefore have to be
disallowed.
Tags: #clang
Differential Revision: https://reviews.llvm.org/D93958
dependent until it's been converted to match its parameter.
The type of a non-type template parameter can in general affect whether
the template argument is dependent.
Note that this is not always possible. For template arguments that name
static local variables in templates, the type of the template parameter
affects whether the argument is dependent, so the query is imprecise
until we know the parameter type. For example, in:
template<typename T> void f() {
static const int n = 5;
typename T::template X<n> x;
}
... we don't know whether 'n' is dependent until we know whether the
corresponding template parameter is of type 'int' or 'const int&'.
The `assumes` directive is an OpenMP 5.1 feature that allows the user to
provide assumptions to the optimizer. Assumptions can refer to
directives (`absent` and `contains` clauses), expressions (`holds`
clause), or generic properties (`no_openmp_routines`, `ext_ABCD`, ...).
The `assumes` spelling is used for assumptions in the global scope while
`assume` is used for executable contexts with an associated structured
block.
This patch only implements the global spellings. While clauses with
arguments are "accepted" by the parser, they will simply be ignored for
now. The implementation lowers the assumptions directly to the
`AssumptionAttr`.
Reviewed By: ABataev
Differential Revision: https://reviews.llvm.org/D91980
The `assumes` directive is an OpenMP 5.1 feature that allows the user to
provide assumptions to the optimizer. Assumptions can refer to
directives (`absent` and `contains` clauses), expressions (`holds`
clause), or generic properties (`no_openmp_routines`, `ext_ABCD`, ...).
The `assumes` spelling is used for assumptions in the global scope while
`assume` is used for executable contexts with an associated structured
block.
This patch only implements the global spellings. While clauses with
arguments are "accepted" by the parser, they will simply be ignored for
now. The implementation lowers the assumptions directly to the
`AssumptionAttr`.
Reviewed By: ABataev
Differential Revision: https://reviews.llvm.org/D91980
Currently we have a diagnostic that catches the other storage class specifies for the range based for loop declaration but we miss the thread_local case. This changes adds a diagnostic for that case as well.
Differential Revision: https://reviews.llvm.org/D92671
552c6c2 removed support for promoting VLAs to constant arrays when the bounds
isn't an ICE, since this can result in miscompiling a conforming program that
assumes that the array is a VLA. Promoting VLAs for fields is still supported,
since clang doesn't support VLAs in fields, so no conforming program could have
a field VLA.
This change is really disruptive, so this commit carves out two more cases
where we promote VLAs which can't miscompile a conforming program:
- When the VLA appears in an ivar -- this seems like a corollary to the field thing
- When the VLA has an initializer -- VLAs can't have an initializer
Differential revision: https://reviews.llvm.org/D90871
Fix bogus diagnostics that would get confused and think a "no viable
fuctions" case was an "undeclared identifiers" case, resulting in an
incorrect diagnostic preceding the correct one. Use overload resolution
to determine which function we should select when we can find call
candidates from a dependent base class. Make the diagnostics for a call
that could call a function from a dependent base class more specific,
and use a different diagnostic message for the case where the call
target is instead declared later in the same class. Plus some minor
diagnostic wording improvements.
caller.
This function did not satisfy its documented contract: it only
considered the first lookup result on each base path, not all lookup
results. It also performed unnecessary memory allocations.
This change results in a minor change to our representation: we now
include overridden methods that are found by any derived-to-base path
(not involving another override) in the list of overridden methods for a
function, rather than filtering out functions from bases that are both
direct virtual bases and indirect virtual bases for which the indirect
virtual base path contains another override for the function. (That
filtering rule is part of the class-scope name lookup rules, and doesn't
really have much to do with enumerating overridden methods.) The users
of the list of overridden methods do not appear to rely on this
filtering having happened, and it's simpler to not do it.
The restriction on pointer-to-pointer kernel arguments has been
relaxed in OpenCL 2.0. Apply the same address space restrictions for
pointer argument types to the inner pointer types.
Differential Revision: https://reviews.llvm.org/D92091
Similar to Windows Itanium, PS4 is also an Itanium C++ ABI variant
which shares the goal of semantic compatibility with Microsoft C++
code that uses dllimport/export.
This change introduces a new function to determine from the triple
if an environment aims for compatibility with MS C++ code w.r.t to
these attributes and guards the relevant code paths using that
function.
Differential Revision: https://reviews.llvm.org/D90299
Reviewed by aaron.ballman, rsmith, wchilders
Highlights of review:
- avoid specifying an underlying type (unless such an enum is stored (or part of an abi?))
- avoid using enums as bit-fields, preferring unsigned bit-fields that we static_cast enumerators to. (MS's abi laysout enum bit-fields differently).
- clang-format, clang-format, clang-format.
https://reviews.llvm.org/D91035
Thank you!
For dllexported default constructors with default arguments, we export
default constructor closures which pass in the default args. (See D8331
for a good explanation.)
For templates, that means those default args must be instantiated even
if the function isn't called. That is done by the
InstantiateDefaultCtorDefaultArgs() function, but it wasn't done for
explicit specializations, causing asserts (see bug).
Differential revision: https://reviews.llvm.org/D91089
Since these are scoped enumerators, they have to be prefixed by DeclaratorContext, so lets remove Context from the name, and return some characters to the multiverse.
Patch was reviewed here: https://reviews.llvm.org/D91011
Thank you to aaron, bruno, wyatt and barry for indulging me.
The use of the new types introduced for PowerPC MMA instructions needs to be restricted.
We add a PowerPC function checking that the given type is valid in a context in which we don't allow MMA types.
This function is called from various places in Sema where we want to prevent the use of these types.
Differential Revision: https://reviews.llvm.org/D82035
friends.
When determining whether a function has a template instantiation
pattern, look for other declarations of that function that were
instantiated from a friend function definition, rather than assuming
that checking for member specialization information on whichever
declaration name lookup found will be sufficient.
classes into the enclosing block scope.
We weren't properly detecting whether the name would be injected into a
block scope in the case where it was lexically declared in a local
class.
Instead of framing the interface around whether the variable is an ICE
(which is only interesting in C++98), primarily track whether the
initializer is a constant initializer (which is interesting in all C++
language modes).
No functionality change intended.
for which it matters.
This is a step towards separating checking for a constant initializer
(in which std::is_constant_evaluated returns true) and any other
evaluation of a variable initializer (in which it returns false).
Old GCC used to aggressively fold VLAs to constant-bound arrays at block
scope in GNU mode. That's non-conforming, and more modern versions of
GCC only do this at file scope. Update Clang to do the same.
Also promote the warning for this from off-by-default to on-by-default
in all cases; more recent versions of GCC likewise warn on this by
default.
This is still slightly more permissive than GCC, as pointed out in
PR44406, as we still fold VLAs to constant arrays in structs, but that
seems justifiable given that we don't support VLA-in-struct (and don't
intend to ever support it), but GCC does.
Differential Revision: https://reviews.llvm.org/D89523
folding to not constant folding.
Constant folding of ICEs is done as a GCC compatibility measure, but new
code was picking it up, presumably by accident, due to the bad default.
While here, also switch the flag from a bool to an enum to make it more
obvious what it means at call sites. This highlighted a couple of places
where our behavior is different between C++11 and C++14 due to switching
from checking for an ICE to checking for a converted constant
expression (where there is no 'fold' codepath).
This happens in glibc's headers. It's important that we recognize these
functions so that we can mark them as returns_twice.
Differential Revision: https://reviews.llvm.org/D88518
The current C++ grammar allows an anonymous bit-field with an attribute,
but this is ambiguous (the attribute in that case could appertain to the
type instead of the bit-field). The current thinking in the Core Working
Group is that it's better to disallow attributes in that position at the
grammar level so that the ambiguity resolves in favor of applying to the
type.
During discussions about the behavior of the attribute, the Core Working
Group also felt it was better to disallow anonymous bit-fields from
specifying a default member initializer.
This implements both sets of related grammar changes.
Anastasia Stulova