DeclResult tracks two states: valid/invalid and usable/unusable.
Passing a null pointer to the constructor creates a valid but unusable
result and we wanted an invalid result instead. This changes some
functions to return a DeclResult rather than a Decl * to make it harder
to get this incorrect in callers.
Discovered when working on https://reviews.llvm.org/D141280.
Co-authored-by: Haojian Wu <hokein@google.com>
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
Differential Revision: https://reviews.llvm.org/D141580
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2350.htm made very
clear that it is an UB having type definitions with in offsetof.
Clang supports defining a type as the first argument as a conforming
extension due to how many projects use the construct in C99 and earlier
to calculate the alignment of a type. GCC also supports defining a type
as the first argument.
This adds extension warnings and documentation for the functionality
Clang explicitly supports.
Fixes#57065
Co-authored-by: Yingchi Long <i@lyc.dev>
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
definitions in header units
Address part of https://github.com/llvm/llvm-project/issues/60079.
Since the the declaration of a non-inline static data member in its
class definition is not a definition. The following form:
```
class A {
public:
static const int value = 43;
};
```
should be fine to appear in a header unit. From the perspective of
implementation, it looks like we simply forgot to check if the variable
is a definition...
Reviewed By: iains
Differential Revision: https://reviews.llvm.org/D141905
This adds an error message if the isSVESizelessBuiltinType like
__SVFloat32_t / __SVInt64_t / etc, which provide the backing for the
svfloat32_t / svint64_t / etc ACLE types, are used in a function without
SVE. The alternative is a crash in the backend, which is not capable of
handling scalable vector types.
When SVE is available, either through a -march=..+sve option or via a
target(sve) attribute, nothing should change. Without the sve feature,
this patch gives an error for any function arguments, return values and
variable declarations involving the scalable types. Struct/class members
and global variables already give an error. As this can be based on the
current function target attributes, the error sometimes needs to be
handled later than would otherwise if it was just based on the global
target.
Differential Revision: https://reviews.llvm.org/D131058
This commit relands the patches for implementing P0960R3 and P1975R0,
which describe initializing aggregates via a parenthesized list.
The relanded commits are:
* 40c52159d3ee - P0960R3 and P1975R0: Allow initializing aggregates from
a parenthesized list of values
* c77a91bb7ba7 - Remove overly restrictive aggregate paren init logic
* 32d7aae04fdb - Fix a clang crash on invalid code in C++20 mode
This patch also fixes a crash in the original implementation.
Previously, if the input tried to call an implicitly deleted copy or
move constructor of a union, we would then try to initialize the union
by initializing it's first element with a reference to a union. This
behavior is incorrect (we should fail to initialize) and if the type of
the first element has a constructor with a single template typename
parameter, then Clang will explode. This patch fixes that issue by
checking that constructor overload resolution did not result in a
deleted function before attempting parenthesized aggregate
initialization.
Additionally, this patch also includes D140159, which contains some
minor fixes made in response to code review comments in the original
implementation that were made after that patch was submitted.
Co-authored-by: Sheng <ox59616e@gmail.com>
Fixes#54040, Fixes#59675
Reviewed By: ilya-biryukov
Differential Revision: https://reviews.llvm.org/D141546
[module.import/6] last sentence:
A header unit shall not contain a definition of a non-inline function or
variable whose name has external linkage.
Differential Revision: https://reviews.llvm.org/D140261
This feature causes clang to crash when compiling Chrome - see
https://crbug.com/1405031 and
https://github.com/llvm/llvm-project/issues/59675
Revert "[clang] Fix a clang crash on invalid code in C++20 mode."
This reverts commit 32d7aae04fdb58e65a952f281ff2f2c3f396d98f.
Revert "[clang] Remove overly restrictive aggregate paren init logic"
This reverts commit c77a91bb7ba793ec3a6a5da3743ed55056291658.
Revert "[clang][C++20] P0960R3 and P1975R0: Allow initializing aggregates from a parenthesized list of values"
This reverts commit 40c52159d3ee337dbed14e4c73b5616ea354c337.
This reverts commit e43924a75145d2f9e722f74b673145c3e62bfd07.
Reason: Patch broke the MSan buildbots. More information is available on
the original phabricator review: https://reviews.llvm.org/D127812
std::optional::value() has undesired exception checking semantics and is
unavailable in older Xcode (see _LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS). The
call sites block std::optional migration.
This makes `ninja clang` work in the absence of llvm::Optional::value.
This change will allow users to call getNullability() without providing an ASTContext.
Reviewed By: gribozavr2
Differential Revision: https://reviews.llvm.org/D140104
The main goal of this work is to allow developers to express the need to place instances
of a class or structure in the read-only part of the program memory. Such a placement is
desirable to prevent any further modifications to the instances of a given structure, by
leveraging the read-only run time protection.
To achieve this, we are introducing a new attribute that can be attached to any record
definition or a declaration. The compiler enforces that every instance of this type can
be placed in the read-only segment of the program memory, provided the target triplet
supports such a placement. If an instance of a given type bearing this attribute doesn’t
satisfy such a placement, the compiler attaches an appropriate warning at suitable program
locations. In other words, adding this attribute to a type requires every instance of this
type to be a global const, which are placed in the read-only segments for most target
triplets. However, this is *not a language feature* and it *need not* be true for
*all target triplets*.
The current patch emits a warning at global variable declaration sites of types bearing
the attribute without const qualification and corresponding note attached to the type
definition/declaration.
Differential Revision: https://reviews.llvm.org/D135851
This patch implements P0960R3, which allows initialization of aggregates
via parentheses.
As an example:
```
struct S { int i, j; };
S s1(1, 1);
int arr1[2](1, 2);
```
This patch also implements P1975R0, which fixes the wording of P0960R3
for single-argument parenthesized lists so that statements like the
following are allowed:
```
S s2(1);
S s3 = static_cast<S>(1);
S s4 = (S)1;
int (&&arr2)[] = static_cast<int[]>(1);
int (&&arr3)[2] = static_cast<int[2]>(1);
```
This patch was originally authored by @0x59616e and completed by
@ayzhao.
Fixes#54040, Fixes#54041
Co-authored-by: Sheng <ox59616e@gmail.com>
Full write up : https://discourse.llvm.org/t/c-20-rfc-suggestion-desired-regarding-the-implementation-of-p0960r3/63744
Reviewed By: ilya-biryukov
Differential Revision: https://reviews.llvm.org/D129531
Partially solves https://github.com/llvm/llvm-project/issues/59206:
We now mark trivial constructors as eligible even if there's a more constrained templated default constructor. Although technically non-conformant, this solves problems with pretty reasonable uses cases like
```
template<int n>
struct Foo {
constexpr Foo() = default;
template<class... Ts>
Foo(Ts... vals) requires(sizeof...(Ts) == n) {}
};
```
where we currently consider the default constructor to be ineligible and therefor inheriting/containing classes have non trivial constructors. This is aligned with GCC: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c75ebe76ae12ac4020f20a24f34606a594a40d15
This doesn't change `__is_trivial`. Although we're technically standard conformant in this regard, GCC/MSVC exhibit different behaviors that seem to make more sense. An issue has been filed to CWG and we await their response.
Reviewed By: erichkeane, #clang-language-wg
Differential Revision: https://reviews.llvm.org/D139038
This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
This patch teaches clang to parse statements on the global scope to allow:
```
./bin/clang-repl
clang-repl> int i = 12;
clang-repl> ++i;
clang-repl> extern "C" int printf(const char*,...);
clang-repl> printf("%d\n", i);
13
clang-repl> %quit
```
Generally, disambiguating between statements and declarations is a non-trivial
task for a C++ parser. The challenge is to allow both standard C++ to be
translated as if this patch does not exist and in the cases where the user typed
a statement to be executed as if it were in a function body.
Clang's Parser does pretty well in disambiguating between declarations and
expressions. We have added DisambiguatingWithExpression flag which allows us to
preserve the existing and optimized behavior where needed and implement the
extra rules for disambiguating. Only few cases require additional attention:
* Constructors/destructors -- Parser::isConstructorDeclarator was used in to
disambiguate between ctor-looking declarations and statements on the global
scope(eg. `Ns::f()`).
* The template keyword -- the template keyword can appear in both declarations
and statements. This patch considers the template keyword to be a declaration
starter which breaks a few cases in incremental mode which will be tackled
later.
* The inline (and similar) keyword -- looking at the first token in many cases
allows us to classify what is a declaration.
* Other language keywords and specifiers -- ObjC/ObjC++/OpenCL/OpenMP rely on
pragmas or special tokens which will be handled in subsequent patches.
The patch conceptually models a "top-level" statement into a TopLevelStmtDecl.
The TopLevelStmtDecl is lowered into a void function with no arguments.
We attach this function to the global initializer list to execute the statement
blocks in the correct order.
Differential revision: https://reviews.llvm.org/D127284
Improve checking for the standard layout type when diagnosing
the kernel argument with templated types. The check doesn't work
correctly for references or pointers due to the lazy template
instantiation.
Current fix only improves cases where nested types in the templates
do not depend on the template parameters.
Differential Revision: https://reviews.llvm.org/D134445
This revision fixes typos where there are 2 consecutive words which are
duplicated. There should be no code changes in this revision (only
changes to comments and docs). Do let me know if there are any
undesirable changes in this revision. Thanks.
This reverts commit dc170433137aeda5e5276bd292cac12aa93fee7c.
Breaks building LLVM on mac when targeting macOS before 10.15, see
comments on https://reviews.llvm.org/D136533
short will be promoted to int in UsualUnaryConversions.
Disable it for HLSL to keep int16_t as 16bit.
Reviewed By: aaron.ballman, rjmccall
Differential Revision: https://reviews.llvm.org/D133668
Added keyword, LangAS and TypeAttrbute for groupshared.
Tanslate it to LangAS with asHLSLLangAS.
Make sure it translated into address space 3 for DirectX target.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D135060
We had a bunch of places in the code where we were translating triple
environment enum cases to shader stage enum cases. The order of these
enums needs to be kept in sync for the translation to be simple, but we
were not properly handling out-of-bounds cases.
In normal compilation out-of-bounds cases shouldn't be possible because
the driver errors if you don't have a valid shader environment set, but
in clang tooling that error doesn't get treated as fatal and parsing
continues. This can result in crashes in clang tooling for out-of-range
shader stages.
To address this, this patch adds a constexpr method to handle the
conversion which handles out-of-range values by converting them to
`Invalid`.
Since this new method is a constexpr, the tests for this are a group of
static_asserts in the implementation file that verifies the correct
conversion for each valid enum case and validates that other cases are
converted to `Invalid`.
Reviewed By: bogner
Differential Revision: https://reviews.llvm.org/D135595
Closes https://github.com/llvm/llvm-project/issues/58196.
The root cause for the problem is an oversight in
https://reviews.llvm.org/D127624, which allows the redeclarations in
partitions. However, we took a mistake there that we should only allow
it if the redeclarations in the one same module instead of return
directly if either the redeclaration lives in a partition. The original
implementation makes no sense and I believe it was an oversight.
Previously we were stripping these normally inherited attributes during
explicit specialization. However for class template member functions
(but not function templates), MSVC keeps the attribute.
This makes Clang match that behavior, and fixes GitHub issue #54717
Differential revision: https://reviews.llvm.org/D135154
We would issue the same diagnostic twice in the case that the K&R C
function definition is preceded by a static declaration of the function
with a prototype.
Fixes#58181
This adds support under AArch64 for the target("..") attributes. The
current parsing is very X86-shaped, this patch attempts to bring it line
with the GCC implementation from
https://gcc.gnu.org/onlinedocs/gcc/AArch64-Function-Attributes.html#AArch64-Function-Attributes.
The supported formats are:
- "arch=<arch>" strings, that specify the architecture features for a
function as per the -march=arch+feature option.
- "cpu=<cpu>" strings, that specify the target-cpu and any implied
atributes as per the -mcpu=cpu+feature option.
- "tune=<cpu>" strings, that specify the tune-cpu cpu for a function as
per -mtune.
- "+<feature>", "+no<feature>" enables/disables the specific feature, for
compatibility with GCC target attributes.
- "<feature>", "no-<feature>" enabled/disables the specific feature, for
backward compatibility with previous releases.
To do this, the parsing of target attributes has been moved into
TargetInfo to give the target the opportunity to override the existing
parsing. The only non-aarch64 change should be a minor alteration to the
error message, specifying using "CPU" to describe the cpu, not
"architecture", and the DuplicateArch/Tune from ParsedTargetAttr have
been combined into a single option.
Differential Revision: https://reviews.llvm.org/D133848
This implements WG14 N2927 and WG14 N2930, which together define the
feature for typeof and typeof_unqual, which get the type of their
argument as either fully qualified or fully unqualified. The argument
to either operator is either a type name or an expression. If given a
type name, the type information is pulled directly from the given name.
If given an expression, the type information is pulled from the
expression. Recursive use of these operators is allowed and has the
expected behavior (the innermost operator is resolved to a type, and
that's used to resolve the next layer of typeof specifier, until a
fully resolved type is determined.
Note, we already supported typeof in GNU mode as a non-conforming
extension and we are *not* exposing typeof_unqual as a non-conforming
extension in that mode, nor are we exposing typeof or typeof_unqual as
a nonconforming extension in other language modes. The GNU variant of
typeof supports a form where the parentheses are elided from the
operator when given an expression (e.g., typeof 0 i = 12;). When in C2x
mode, we do not support this extension.
Differential Revision: https://reviews.llvm.org/D134286
This patch implements P0634r3 that removes the need for 'typename' in certain contexts.
For example,
```
template <typename T>
using foo = T::type; // ok
```
This is also allowed in previous language versions as an extension, because I think it's pretty useful. :)
Reviewed By: #clang-language-wg, erichkeane
Differential Revision: https://reviews.llvm.org/D53847
This reverts commit 95d94a67755620c0a2871ac6f056ca8e9731d5e9.
This implements the deferred concepts instantiation, which should allow
the libstdc++ ranges to properly compile, and for the CRTP to work for
constrained functions.
Since the last attempt, this has fixed the issues from @wlei and
@mordante.
Differential Revision: https://reviews.llvm.org/D126907
Prior to the patch, we didn't build a DeclRefExpr if the Decl being
referred to is invalid, because many clang downstream AST consumers
assume it, violating it will cause many diagnostic regressions.
With this patch, we build a DeclRefExpr enven for an invalid decl (when the
AcceptInvalidDecl is true), and wrap it with a dependent-type
RecoveryExpr (to prevent follow-up semantic analysis, and diagnostic
regressions).
This is a revised version of https://reviews.llvm.org/D76831
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D121599
This is first part for support cbuffer/tbuffer.
The format for cbuffer/tbuffer is
BufferType [Name] [: register(b#)] { VariableDeclaration [: packoffset(c#.xyzw)]; ... };
More details at https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-constants
New keyword 'cbuffer' and 'tbuffer' are added.
New AST node HLSLBufferDecl is added.
Build AST for simple cbuffer/tbuffer without attribute support.
The special thing is variables declared inside cbuffer is exposed into global scope.
So isTransparentContext should return true for HLSLBuffer.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D129883
In order to make this easier to track I've filed issues for each of the
HLSL FIXME comments that I can find. I may have missed some, but I want
this to be the new default mode.
After upgrading the type deduction machinery to retain type sugar in
D110216, we were left with a situation where there is no general
well behaved mechanism in Clang to unify the type sugar of multiple
deductions of the same type parameter.
So we ended up making an arbitrary choice: keep the sugar of the first
deduction, ignore subsequent ones.
In general, we already had this problem, but in a smaller scale.
The result of the conditional operator and many other binary ops
could benefit from such a mechanism.
This patch implements such a type sugar unification mechanism.
The basics:
This patch introduces a `getCommonSugaredType(QualType X, QualType Y)`
method to ASTContext which implements this functionality, and uses it
for unifying the results of type deduction and return type deduction.
This will return the most derived type sugar which occurs in both X and
Y.
Example:
Suppose we have these types:
```
using Animal = int;
using Cat = Animal;
using Dog = Animal;
using Tom = Cat;
using Spike = Dog;
using Tyke = Dog;
```
For `X = Tom, Y = Spike`, this will result in `Animal`.
For `X = Spike, Y = Tyke`, this will result in `Dog`.
How it works:
We take two types, X and Y, which we wish to unify as input.
These types must have the same (qualified or unqualified) canonical
type.
We dive down fast through top-level type sugar nodes, to the
underlying canonical node. If these canonical nodes differ, we
build a common one out of the two, unifying any sugar they had.
Note that this might involve a recursive call to unify any children
of those. We then return that canonical node, handling any qualifiers.
If they don't differ, we walk up the list of sugar type nodes we dived
through, finding the last identical pair, and returning that as the
result, again handling qualifiers.
Note that this patch will not unify sugar nodes if they are not
identical already. We will simply strip off top-level sugar nodes that
differ between X and Y. This sugar node unification will instead be
implemented in a subsequent patch.
This patch also implements a few users of this mechanism:
* Template argument deduction.
* Auto deduction, for functions returning auto / decltype(auto), with
special handling for initializer_list as well.
Further users will be implemented in a subsequent patch.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D111283
While investigating something else, I discovered that a prototypeless
function with 'overloadable' was having the attribute left on the
declaration, which caused 'ambiguous' call errors later on. This lead to
some confusion. This patch removes the 'overloadable' attribute from
the declaration and leaves it as prototypeless, instead of trying to
make it variadic.
This reverts commit d200db38637884fd0b421802c6094b2a03ceb29e, which causes a
clang crash. See https://reviews.llvm.org/D111283#3785755
Test case for convenience:
```
template <typename T>
using P = int T::*;
template <typename T, typename... A>
void j(P<T>, T, A...);
template <typename T>
void j(P<T>, T);
struct S {
int b;
};
void g(P<S> k, S s) { j(k, s); }
```
