1270 Commits

Author SHA1 Message Date
Mariya Podchishchaeva
aced81c0a5
[C23] Implement N3018: The constexpr specifier for object definitions (#73099)
The implementation mostly reuses C++ code paths where possible,
including narrowing check in order to provide diagnostic messages in
case initializer for constexpr variable is not exactly representable in
target type.

The following won't work due to lack of support for other features:
- Diagnosing of underspecified declarations involving constexpr
- Constexpr attached to compound literals

Also due to lack of support for char8_t some of examples with utf-8
strings don't work properly.

Fixes https://github.com/llvm/llvm-project/issues/64742
2024-03-06 09:46:35 +01:00
Erich Keane
bd7bce2c84
Fix null-deref thanks to an attribute on a global declarator chunk (#83611)
This was reported (sort of) in a PR: #77703. The problem is that a
declarator 'owns' an attributes allocation via an `AttributePool`.
However, this example tries to copy a DeclaratorChunk from one
Declarator to another, so when the temporary Declarator goes out of
scope, it deletes the attribute it has tried to pass on via the chunk.

This patch ensures that we copy the 'ownership' of the attribute
correctly, and adds an assert to catch any other casess where this
happens.

Additionally, this was put in as a bug report, so this
Fixes #83611
2024-03-04 09:25:29 -08:00
Sergei Barannikov
2d0137dd64
[clang] Differentiate between identifier and string EnumArgument (#68550)
EnumArgument may be a string or an identifier. If it is a string, it
should be parsed as unevaluated string literal. Add IsString flag to
EnumArgument so that the parser can choose the correct parsing method.

Target-specific attributes that share spelling may have different
attribute "prototypes". For example, ARM's version of "interrupt"
attribute accepts a string enum, while MSP430's version accepts an
unsigned integer. Adjust ClangAttrEmitter so that the generated
`attributeStringLiteralListArg` returns the correct mask depending on
target triple.

It is worth noting that even after this change some string arguments are
still parsed as identifiers or, worse, as expressions. This is because
of some special logic in `ParseAttributeArgsCommon`. Fixing it is out of
scope of this patch.
2024-02-18 17:44:19 +03:00
Aaron Ballman
97434cb318
[C11] Diagnose C11 keywords as being incompatible w/earlier standards (#82015)
Our usual pattern when issuing an extension warning is to also issue a
default-off diagnostic about the keywords not being compatible with
standards before a certain point. This adds those diagnostics for C11
keywords.
2024-02-16 15:08:04 -05:00
Aaron Ballman
b9cf7f1066
[C23] Fix handling of alignas (#81637)
In C++, alignas is an attribute specifier, while in C23, it's an alias
of _Alignas, which is a type specifier/qualifier. This means that they
parse differently in some circumstances.

Fixes https://github.com/llvm/llvm-project/issues/81472
2024-02-15 07:58:01 -05:00
Krystian Stasiowski
1156bbc5b1
[Clang][Sema] Diagnose use of template keyword after declarative nested-name-specifiers (#78595)
According to [temp.names] p5:
> The keyword template shall not appear immediately after a declarative nested-name-specifier.

[expr.prim.id.qual] p2 defines a declarative nested-name-specifier as follows:
> A nested-name-specifier is declarative if it is part of
> - a class-head-name,
> - an enum-head-name,
> - a qualified-id that is the id-expression of a declarator-id, or
> - a declarative nested-name-specifier.

Note: I believe this definition is defective as it doesn't include _nested-name-specifiers_ appearing in _elaborated-type-specifiers_ that declare partial/explicit specializations and explicit instantiations. See my post to the core reflector. Minus a few bugs that are addressed by this PR, this is how we implement it.

This means that declarations like:
```
template<typename>
struct A
{
    template<typename> 
    struct B
   {
        void f();
   };
};

template<typename T>
template<typename U>
void A<T>::template B<U>::f() { } // error: 'template' cannot be used after a declarative nested name specifier
```
are ill-formed. This PR add diagnostics for such declarations. The name of the diagnostic group is `template-in-declaration-name`.

Regarding the aforementioned "few bugs that are addressed by this PR" in order to correctly implement this:
- `CheckClassTemplate` did not call `diagnoseQualifiedDeclaration` when the semantic context was dependent. This allowed for constructs like:
```
struct A
{
    template<typename T>
    struct B
    {
        template<typename U>
        struct C;
    };
};

template<typename T>
template<typename U>
struct decltype(A())::B<T>::C { };
```
- `ActOnClassTemplateSpecialization` did not call `diagnoseQualifiedDeclaration` at all, allowing for qualified partial/explicit specializations at class scope and other related nonsense
- `TreeTransform::TransformNestedNameSpecifierLoc` would rebuild a `NestedNameSpecifier::TypeSpecWithTemplate` as a `NestedNameSpecifier::TypeSpec`
- `TemplateSpecializationTypeLoc::initializeLocal` would set the `template` keyword `SourceLocation` to the provided `Loc` parameter, which would result in a `TemplateSpecializationTypeLoc` obtained via `ASTContext::getTrivialTypeSourceInfo` being displayed as always having a `template` prefix (since the presence of the keyword is not stored anywhere else).
2024-02-02 13:15:41 -05:00
Krystian Stasiowski
c5f461918c
[Clang][Parse] Diagnose member template declarations with multiple declarators (#78243)
According to [temp.pre] p5:
> In a template-declaration, explicit specialization, or explicit instantiation the init-declarator-list in the declaration shall contain at most one declarator. 

A member-declaration that is a template-declaration or explicit-specialization contains a declaration, even though it declares a member. This means it _will_ contain an init-declarator-list (not a member-declarator-list), so [temp.pre] p5 applies.

This diagnoses declarations such as:
```
struct A
{
    template<typename T>
    static const int x = 0, f(); // error: a template declaration can only declare a single entity

    template<typename T>
    static const int g(), y = 0; // error: a template declaration can only declare a single entity
};
```
The diagnostic messages are the same as those of the equivalent namespace scope declarations.

Note: since we currently do not diagnose declarations with multiple abbreviated function template declarators at namespace scope e.g., `void f(auto), g(auto);`, so this patch does not add diagnostics for the equivalent member declarations.

This patch also refactors `ParseSingleDeclarationAfterTemplate` (now named `ParseDeclarationAfterTemplate`) to call `ParseDeclGroup` and return the resultant `DeclGroup`.
2024-02-01 11:19:04 -05:00
yronglin
0aff71c178
[Clang] Implement P2718R0 "Lifetime extension in range-based for loops" (#76361)
Implement P2718R0 "Lifetime extension in range-based for loops"
(https://wg21.link/P2718R0)

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

---------

Signed-off-by: yronglin <yronglin777@gmail.com>
2024-01-30 06:48:14 +08:00
cor3ntin
ad1a65fcac
[Clang][C++26] Implement Pack Indexing (P2662R3). (#72644)
Implements https://isocpp.org/files/papers/P2662R3.pdf

The feature is exposed as an extension in older language modes.
Mangling is not yet supported and that is something we will have to do before release.
2024-01-27 10:23:38 +01:00
Egor Zhdan
77d21e758e
[APINotes] Upstream dependencies of Sema logic to apply API Notes to decls
This upstreams more of the Clang API Notes functionality that is
currently implemented in the Apple fork:
https://github.com/apple/llvm-project/tree/next/clang/lib/APINotes

This is the largest chunk of the API Notes functionality in the
upstreaming process. I will soon submit a follow-up patch to actually
enable usage of this functionality by having a Clang driver flag that
enables API Notes, along with tests.
2024-01-17 13:13:10 +00:00
Krystian Stasiowski
68ae1e49d2
[Clang][Sema][NFC] Remove unused Scope* parameter from Sema::GetTypeForDeclarator and Sema::ActOnTypeName (#78325)
Split from #78274
2024-01-17 05:47:57 -05:00
Sander de Smalen
8e7f073eb4
[Clang][AArch64] Change SME attributes for shared/new/preserved state. (#76971)
This patch replaces the `__arm_new_za`, `__arm_shared_za` and
`__arm_preserves_za` attributes in favour of:
* `__arm_new("za")`
* `__arm_in("za")`
* `__arm_out("za")`
* `__arm_inout("za")`
* `__arm_preserves("za")`

As described in https://github.com/ARM-software/acle/pull/276.

One change is that `__arm_in/out/inout/preserves(S)` are all mutually
exclusive, whereas previously it was fine to write `__arm_shared_za
__arm_preserves_za`. This case is now represented with `__arm_in("za")`.

The current implementation uses the same LLVM attributes under the hood,
since `__arm_in/out/inout` are all variations of "shared ZA", so can use
the existing `aarch64_pstate_za_shared` attribute in LLVM.

#77941 will add support for the new "zt0" state as introduced
with SME2.
2024-01-15 09:41:32 +00:00
Ding Fei
46944210eb
[clang][Parser] Pop scope prior VarDecl invalidating by invalid init (#77434)
Invalid (direct) initializer would invalid `VarDecl` so
`InitializerScopeRAII` cannot restore scope stack balance.

As with other kind of initializer, `InitializerScopeRAII::pop()` is
moved up before `Sema::ActOnInitializerError()` which invalidates the
`VarDecl`, so scope can be balanced and current `DeclContext` can be
restored.

Fixes #30908
2024-01-10 08:49:36 +08:00
ChipsSpectre
b5a3e96392
[Clang][Parser] Fix crash of clang when using C++ constructs like :: in C code (#74926)
Ensure we do not try to parse a nested-name-specifier when parsing an ill-formed file in C mode.

Fixes #73559
2024-01-04 21:04:54 +01:00
Kazu Hirata
f3dcc2351c
[clang] Use StringRef::{starts,ends}_with (NFC) (#75149)
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.

I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
2023-12-13 08:54:13 -08:00
Chris B
d462621694
[HLSL] Parameter modifier parsing and AST (#72139)
This change implements parsing for HLSL's parameter modifier keywords
`in`, `out` and `inout`. Because HLSL doesn't support references or
pointers, these keywords are used to allow parameters to be passed in
and out of functions.

This change only implements the parsing and AST support. In the HLSL
ASTs we represent `out` and `inout` parameters as references, and we
implement the semantics of by-value passing during IR generation.

In HLSL parameters marked `out` and `inout` are ambiguous in function
declarations, and `in`, `out` and `inout` may be ambiguous at call
sites.

This means a function may be defined as `fn(in T)` and `fn(inout T)` or
`fn(out T)`, but not `fn(inout T)` and `fn(out T)`. If a funciton `fn`
is declared with `in` and `inout` or `out` arguments, the call will be
ambiguous the same as a C++ call would be ambiguous given declarations
`fn(T)` and `fn(T&)`.

Fixes #59849
2023-11-28 15:03:10 -06:00
erichkeane
7d1a9e81b0 [OpenACC] Rename ParseOpenACCDirective to ParseOpenACCDirectiveDecl
The former name is more useful as a callee of the function in a future
patch, so as suggested in that review, move the rename here.
2023-11-17 07:28:33 -08:00
Erich Keane
ff219ea9ca
[OpenACC] Initial commits to support OpenACC (#70234)
Initial commits to support OpenACC.  This patchset:

adds a clang-command line argument '-fopenacc', and starts
 to define _OPENACC, albeit to '1' instead of the standardized
value (since we don't properly implement OpenACC yet).

The OpenACC spec defines `_OPENACC` to be equal to the latest standard
implemented. However, since we're not done implementing any standard,
we've defined this by default to be `1`. As it is useful to run our
compiler against existing OpenACC workloads, we're providing a
temporary override flag to change the `_OPENACC` value to be any
entirely digit value, permitting testing against any existing OpenACC
project.

Exactly like the OpenMP parser, the OpenACC pragma parser needs to
consume and reprocess the tokens. This patch sets up the infrastructure
to do so by refactoring the OpenMP version of this into a more general
version that works for OpenACC as well.

Additionally, this adds a few diagnostics and token kinds to get us
started.
2023-11-17 06:29:02 -08:00
PiJoules
2c65860667
[clang] Remove fixed point arithmetic error (#71884)
Prior to this, clang would always report

```
compile with '-ffixed-point' to enable fixed point types
```

whenever it sees `_Accum`, `_Fract`, or `_Sat` when fixed point
arithmetic is not enabled. This can break existing code that uses these
as variable names and doesn't use fixed point arithmetic like in some
microsoft headers

(https://github.com/llvm/llvm-project/pull/67750#issuecomment-1775264907).

Fixed point should not raise this error for these cases, so this removes
the error altogether and defaults to the usual error clang gives where
it can see these keywords as either unknown types or regular variables.
2023-11-13 12:31:49 -08:00
Aaron Ballman
66f4a1399d
[C23] Use thread_local semantics (#70107)
When implementing thread_local as a keyword in C23, we accidentally
started using C++11 thread_local semantics when using that keyword
instead of using C11 _Thread_local semantics.

This oversight is fixed by pretending the user wrote _Thread_local
instead. This doesn't have the best behavior in terms of diagnostics,
but it does correct the semantic behavior.

Fixes https://github.com/llvm/llvm-project/issues/70068
Fixes https://github.com/llvm/llvm-project/issues/69167
2023-10-25 07:51:28 -04:00
Guillot Tony
d5444ab267
[clang][C2x] Remove confusing diagnostic auto storage class specifier (#68710)
When declaring `auto int` at local or file scope, we emit a warning
intended for C++11 and later, which is incorrect and confusing in C23.
See [Godbolt example](https://godbolt.org/z/j1acGhecd).
Now this diagnostic does not show up in C23.
2023-10-11 09:51:46 +02:00
Guillot Tony
13ffc61a42 [C2X] N3007 Type inference for object definitions
Re-landing 5d78b78c8538 which was reverted.

This patches implements the auto keyword from the N3007 standard
specification.
This allows deducing the type of the variable like in C++:
```
auto nb = 1;
auto chr = 'A';
auto str = "String";
```
The list of statements which allows the usage of auto:

    * Basic variables declarations (int, float, double, char, char*...)
    * Macros declaring a variable with the auto type

The list of statements which will not work with the auto keyword:

    * auto arrays
    * sizeof(), alignas()
    * auto parameters, auto return type
    * auto as a struct/typedef member
    * uninitialized auto variables
    * auto in an union
    * auto as a enum type specifier
    * auto casts
    * auto in an compound literals

Differential Revision: https://reviews.llvm.org/D133289
2023-10-05 12:16:00 -04:00
Aaron Ballman
dc1000d5b2 Revert "[C2X] N3007 Type inference for object definitions"
This reverts commit 5d78b78c853830516e734cfa64bfba70479e35dc.

Reverting due to the failure found by:
https://lab.llvm.org/buildbot/#/builders/245/builds/14999
2023-10-05 08:52:12 -04:00
Guillot Tony
5d78b78c85 [C2X] N3007 Type inference for object definitions
This patches implements the auto keyword from the N3007 standard
specification.
This allows deducing the type of the variable like in C++:
```
auto nb = 1;
auto chr = 'A';
auto str = "String";
```
The list of statements which allows the usage of auto:

    * Basic variables declarations (int, float, double, char, char*...)
    * Macros declaring a variable with the auto type

The list of statements which will not work with the auto keyword:

    * auto arrays
    * sizeof(), alignas()
    * auto parameters, auto return type
    * auto as a struct/typedef member
    * uninitialized auto variables
    * auto in an union
    * auto as a enum type specifier
    * auto casts
    * auto in an compound literals

Differential Revision: https://reviews.llvm.org/D133289
2023-10-05 08:11:02 -04:00
cor3ntin
c72d3a0966
[Clang] Handle consteval expression in array bounds expressions (#66222)
The bounds of a c++ array is a _constant-expression_. And in C++ it is
also a constant expression.

But we also support VLAs, ie arrays with non-constant bounds.

We need to take care to handle the case of a consteval function (which
are specified to be only immediately called in non-constant contexts)
that appear in arrays bounds.

This introduces `Sema::isAlwayConstantEvaluatedContext`, and a flag in
ExpressionEvaluationContextRecord, such that immediate functions in
array bounds are always immediately invoked.

Sema had both `isConstantEvaluatedContext` and
`isConstantEvaluated`, so I took the opportunity to cleanup that.

The change in `TimeProfilerTest.cpp` is an unfortunate manifestation of
the problem that #66203 seeks to address.

Fixes #65520
2023-10-05 11:36:27 +02:00
Shoaib Meenai
c6fed74f6f
[diag] Silence -Wfixed-enum-extension in C23 (#68060)
The C23 standard supports enums with fixed underlying types (N3030 [1]),
so we shouldn't emit `-Wfixed-enum-extension` in C23 mode (since it's no
longer a Clang extension at that point).

[1]
https://thephd.dev/_vendor/future_cxx/papers/C%20-%20Enhanced%20Enumerations.html
2023-10-03 13:04:22 -07:00
Corentin Jabot
af4751738d [C++] Implement "Deducing this" (P0847R7)
This patch implements P0847R7 (partially),
CWG2561 and CWG2653.

Reviewed By: aaron.ballman, #clang-language-wg

Differential Revision: https://reviews.llvm.org/D140828
2023-10-02 14:33:02 +02:00
cor3ntin
64ffe64d2d
[Clang] Handle sema of noexcept condition in their evaluation context. (#67538)
The conditions of a noexcept and explicit specifier are full
expressions. Before this patch, we would call ActOnFinishFullExpr on
these in the context of the enclosing expression, which would cause the
collect of odr-used variables (and subsequently capture attempts) in the
wrong (enclosing) context.

This was observable when parsing the noexcept specifier condition of a
lambda appearing in a wider full expression odr-using variables.

Fixes #67492
2023-09-28 08:25:30 +02:00
Sam McCall
880fa7faa9 Revert "[clang][SemaCXX] Diagnose tautological uses of consteval if and is_constant_evaluated"
This reverts commit 491b2810fb7fe5f080fa9c4f5945ed0a6909dc92.

This change broke valid code and generated incorrect diagnostics, see
https://reviews.llvm.org/D155064
2023-09-27 18:58:01 +02:00
Takuya Shimizu
491b2810fb [clang][SemaCXX] Diagnose tautological uses of consteval if and is_constant_evaluated
This patch makes clang diagnose extensive cases of consteval if and is_constant_evaluated usage that are tautologically true or false.
This introduces a new IsRuntimeEvaluated boolean flag to Sema::ExpressionEvaluationContextRecord that means the immediate appearance of if consteval or is_constant_evaluated are tautologically false(e.g. inside if !consteval {} block or non-constexpr-qualified function definition body)
This patch also pushes new expression evaluation context when parsing the condition of if constexpr and initializer of constexpr variables so that Sema can be aware that the use of consteval if and is_consteval are tautologically true in if constexpr condition and constexpr variable initializers.
BEFORE this patch, the warning for is_constant_evaluated was emitted from constant evaluator. This patch moves the warning logic to Sema in order to diagnose tautological use of is_constant_evaluated in the same way as consteval if.

This patch separates initializer evaluation context from InitializerScopeRAII.
This fixes a bug that was happening when user takes address of function address in initializers of non-local variables.

Fixes https://github.com/llvm/llvm-project/issues/43760
Fixes https://github.com/llvm/llvm-project/issues/51567

Reviewed By: cor3ntin, ldionne
Differential Revision: https://reviews.llvm.org/D155064
2023-09-27 09:26:06 +09:00
Shafik Yaghmour
6eadc8f16e [Clang] Fix crash in Parser::ParseDirectDeclarator by adding check that token is not an annotation token
In Parser::ParseDirectDeclarator(...) in some cases ill-formed code can cause an
annotation token to end up where it was not expected. The fix is to add a
!Tok.isAnnotation() guard before attempting to access identifier info.

This fixes: https://github.com/llvm/llvm-project/issues/64836

Differential Revision: https://reviews.llvm.org/D158804
2023-09-12 11:06:06 -07:00
Yaxun (Sam) Liu
9b7763821a
Reland "[CUDA][HIP] Fix overloading resolution in global var init" (#65606)
https://reviews.llvm.org/D158247 caused regressions for HIP on Windows
and was reverted.

A reduced test case is:

```
typedef void (__stdcall* funcTy)();
void invoke(funcTy f);

static void __stdcall callee() noexcept {
}

void foo() {
   invoke(callee);
}
```

It is due to clang missing handling host/device attributes for calling
convention at a few places

This patch fixes that.
2023-09-07 23:18:30 -04:00
Yaxun (Sam) Liu
27313b68ef Revert "[CUDA][HIP] Fix overloading resolution in global variable initializer"
This reverts commit de0df639724b10001ea9a74539381ea494296be9.

It was reverted due to regression in HIP unit test on Windows:

 In file included from C:\hip-tests\catch\unit\graph\hipGraphClone.cc:37:

 In file included from C:\hip-tests\catch\.\include\hip_test_common.hh:24:

 In file included from C:\hip-tests\catch\.\include/hip_test_context.hh:24:

 In file included from C:/install/native/Release/x64/hip/include\hip/hip_runtime.h:54:

 C:/dk/win\vc\14.31.31107\include\thread:76:70: error: cannot initialize a parameter of type '_beginthreadex_proc_type' (aka 'unsigned int (*)(void *) __attribute__((stdcall))') with an lvalue of type 'const unsigned int (*)(void *) noexcept __attribute__((stdcall))': different exception specifications

    76 |             reinterpret_cast<void*>(_CSTD _beginthreadex(nullptr, 0, _Invoker_proc, _Decay_copied.get(), 0, &_Thr._Id));

       |                                                                      ^~~~~~~~~~~~~

 C:\hip-tests\catch\unit\graph\hipGraphClone.cc:290:21) &>' requested here

    90 |         _Start(_STD forward<_Fn>(_Fx), _STD forward<_Args>(_Ax)...);

       |         ^

 C:\hip-tests\catch\unit\graph\hipGraphClone.cc:290:21) &, 0>' requested here

   311 |     std::thread t(lambdaFunc);

       |                 ^

 C:/dk/win\ms_wdk\e22621\Include\10.0.22621.0\ucrt\process.h:99:40: note: passing argument to parameter '_StartAddress' here

    99 |     _In_      _beginthreadex_proc_type _StartAddress,

       |                                        ^

 1 error generated when compiling for gfx1030.
2023-08-31 09:02:49 -04:00
Sergei Barannikov
a7eaaba699 [Parser] Parse string literal arguments of 'availability', 'external_source_symbol' and 'uuid' attributes as unevaluated
This is a complementary to D156237.
These attributes have custom parsing logic.

Reviewed By: cor3ntin

Differential Revision: https://reviews.llvm.org/D159024
2023-08-30 11:46:54 +03:00
Yaxun (Sam) Liu
de0df63972 [CUDA][HIP] Fix overloading resolution in global variable initializer
Currently, clang does not resolve certain overloaded functions correctly in the initializer
of global variables, e.g.

template<typename T1, typename U>
T1 mypow(T1, U);

__attribute__((device)) double mypow(double, int);

double t_extent = mypow(1.0, 2);

In the above example, mypow is supposed to resolve to the host version
but clang resolves it to the device version instead, and emits an error
(https://godbolt.org/z/17xxzaa67).

However, if the variable is assigned in a host function, there is no error.
The discrepancy in overloading resolution inside and outside of
a function is due to clang not accounting for the host/device target
when resolving functions called in the initializer of a global variable.

This patch introduces a global host/device target context for CUDA/HIP
for functions called outside of functions. For global variable initialization,
it is determined by the host/device attribute of the variable. For other
situations, a default value of host_device is sufficient.

Reviewed by: Artem Belevich

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

Fixes: SWDEV-416731
2023-08-29 10:17:24 -04:00
Fred Fu
79af92bb99 Reland "[clang-repl] support code completion at a REPL."
Original commit message:
"
This patch enabled code completion for ClangREPL. The feature was built upon
three existing Clang components: a list completer for LineEditor, a
CompletionConsumer from SemaCodeCompletion, and the ASTUnit::codeComplete method.
The first component serves as the main entry point of handling interactive inputs.

Because a completion point for a compiler instance has to be unchanged once it
is set, an incremental compiler instance is created for each code
completion. Such a compiler instance carries over AST context source from the
main interpreter compiler in order to obtain declarations or bindings from
previous input in the same REPL session.

The most important API codeComplete in Interpreter/CodeCompletion is a thin
wrapper that calls with ASTUnit::codeComplete with necessary arguments, such as
a code completion point and a ReplCompletionConsumer, which communicates
completion results from SemaCodeCompletion back to the list completer for the
REPL.

In addition, PCC_TopLevelOrExpression and CCC_TopLevelOrExpression` top levels
were added so that SemaCodeCompletion can treat top level statements like
expression statements at the REPL. For example,

clang-repl> int foo = 42;
clang-repl> f<tab>

From a parser's persective, the cursor is at a top level. If we used code
completion without any changes, PCC_Namespace would be supplied to
Sema::CodeCompleteOrdinaryName, and thus the completion results would not
include foo.

Currently, the way we use PCC_TopLevelOrExpression and
CCC_TopLevelOrExpression is no different from the way we use PCC_Statement
and CCC_Statement respectively.

Differential revision: https://reviews.llvm.org/D154382
"

The new patch also fixes clangd and several memory issues that the bots reported
and upload the missing files.
2023-08-28 20:09:03 +00:00
Vassil Vassilev
752f87cd6a Revert "Reland "[clang-repl] support code completion at a REPL.""
This reverts commit 5ab25a42ba70c4b50214b0e78eaaccd30696fa09 due to forgotten
files.
2023-08-28 20:05:14 +00:00
Fred Fu
5ab25a42ba Reland "[clang-repl] support code completion at a REPL."
Original commit message:
"
This patch enabled code completion for ClangREPL. The feature was built upon
three existing Clang components: a list completer for LineEditor, a
CompletionConsumer from SemaCodeCompletion, and the ASTUnit::codeComplete method.
The first component serves as the main entry point of handling interactive inputs.

Because a completion point for a compiler instance has to be unchanged once it
is set, an incremental compiler instance is created for each code
completion. Such a compiler instance carries over AST context source from the
main interpreter compiler in order to obtain declarations or bindings from
previous input in the same REPL session.

The most important API codeComplete in Interpreter/CodeCompletion is a thin
wrapper that calls with ASTUnit::codeComplete with necessary arguments, such as
a code completion point and a ReplCompletionConsumer, which communicates
completion results from SemaCodeCompletion back to the list completer for the
REPL.

In addition, PCC_TopLevelOrExpression and CCC_TopLevelOrExpression` top levels
were added so that SemaCodeCompletion can treat top level statements like
expression statements at the REPL. For example,

clang-repl> int foo = 42;
clang-repl> f<tab>

From a parser's persective, the cursor is at a top level. If we used code
completion without any changes, PCC_Namespace would be supplied to
Sema::CodeCompleteOrdinaryName, and thus the completion results would not
include foo.

Currently, the way we use PCC_TopLevelOrExpression and
CCC_TopLevelOrExpression is no different from the way we use PCC_Statement
and CCC_Statement respectively.

Differential revision: https://reviews.llvm.org/D154382
"

The new patch also fixes clangd and several memory issues that the bots reported.
2023-08-28 19:59:56 +00:00
Vassil Vassilev
f94a937cb3 Revert "[clang-repl] support code completion at a REPL."
This reverts commit eb0e6c3134ef6deafe0a4958e9e1a1214b3c2f14 due to failures in
clangd such as https://lab.llvm.org/buildbot/#/builders/57/builds/29377
2023-08-23 14:46:15 +00:00
Fred Fu
eb0e6c3134 [clang-repl] support code completion at a REPL.
This patch enabled code completion for ClangREPL. The feature was built upon
three existing Clang components: a list completer for LineEditor, a
CompletionConsumer from SemaCodeCompletion, and the ASTUnit::codeComplete method.
The first component serves as the main entry point of handling interactive inputs.

Because a completion point for a compiler instance has to be unchanged once it
is set, an incremental compiler instance is created for each code
completion. Such a compiler instance carries over AST context source from the
main interpreter compiler in order to obtain declarations or bindings from
previous input in the same REPL session.

The most important API codeComplete in Interpreter/CodeCompletion is a thin
wrapper that calls with ASTUnit::codeComplete with necessary arguments, such as
a code completion point and a ReplCompletionConsumer, which communicates
completion results from SemaCodeCompletion back to the list completer for the
REPL.

In addition, PCC_TopLevelOrExpression and CCC_TopLevelOrExpression` top levels
were added so that SemaCodeCompletion can treat top level statements like
expression statements at the REPL. For example,

clang-repl> int foo = 42;
clang-repl> f<tab>

From a parser's persective, the cursor is at a top level. If we used code
completion without any changes, PCC_Namespace would be supplied to
Sema::CodeCompleteOrdinaryName, and thus the completion results would not
include foo.

Currently, the way we use PCC_TopLevelOrExpression and
CCC_TopLevelOrExpression is no different from the way we use PCC_Statement
and CCC_Statement respectively.

Differential revision: https://reviews.llvm.org/D154382
2023-08-23 14:00:59 +00:00
Kadir Cetinkaya
373fcd5d73
[clang] Use RecoveryExprs for broken defaultargs, instead of OpaqueValueExprs
This makes sure we can preserve invalid-ness for consumers of this
node, it prevents crashes. It also aligns better with rest of the places that
store invalid expressions.

Differential Revision: https://reviews.llvm.org/D157868
2023-08-16 10:22:16 +02:00
Corentin Jabot
98322d3eb4 Complete the implementation of P2361 Unevaluated string literals
The attributes changes were left out of Clang 17.
Attributes that used to take a string literal now accept an unevaluated
string literal instead, which means they reject numeric escape sequences
and strings literal with an encoding prefix - but the later was already
ill-formed in most cases.

We need to know that we are going to parse an unevaluated string literal
before we do - so we can reject numeric escape sequence,
so we derive from Attrs.td which attributes parameters are expected
to be string literals.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D156237
2023-08-15 14:13:13 +02:00
Aaron Ballman
9c4ade0623 [C23] Rename C2x->C23 in diagnostics
This renames C2x to C23 in diagnostic identifiers and messages. The
changes were made mechanically.
2023-08-11 08:42:01 -04:00
Aaron Ballman
0ce056a814 [C23] Rename C2x -> C23; NFC
This does the rename for most internal uses of C2x, but does not rename
or reword diagnostics (those will be done in a follow-up).

I also updated standards references and citations to the final wording
in the standard.
2023-08-11 07:43:43 -04:00
Corentin Jabot
a8bef8865e [Clang] Implement P2169 A nice placeholder with no name
This is a C++ feature that allows the use of `_` to
declare multiple variable of that name in the same scope;
these variables can then not be referred to.

In addition, while P2169 does not extend to parameter
declarations, we stop warning on unused parameters of that name,
for consistency.

The feature is backported to all C++ language modes.

Reviewed By: #clang-language-wg, aaron.ballman

Differential Revision: https://reviews.llvm.org/D153536
2023-08-04 16:51:15 +02:00
Mariya Podchishchaeva
4a792e06e8 [clang] Fix new-expression with elaborated-type-specifier
Expressions like
```
struct A {};
...
new struct A {};
struct A* b = (1 == 1) ? new struct A : new struct A;

```
were parsed as redefinitions of `struct A` and failed, however as clarified by
`CWG2141` new-expression cannot define a type, so both these examples
should be considered as references to the previously declared `struct A`.
The patch adds a "new" kind context for parsing declaration specifiers in
addition to already existing declarator context in order to track that
the parser is inside of a new expression.

Fixes https://github.com/llvm/llvm-project/issues/34341

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D153857
2023-07-03 06:07:04 -04:00
Corentin Jabot
d9be8a8a99 [Clang] Allow omitting typename in befriended constructors parameters
Fixes #63119

Reviewed By: #clang-language-wg, aaron.ballman

Differential Revision: https://reviews.llvm.org/D152242
2023-06-06 15:04:47 +02:00
Richard Sandiford
33ee5c4663 [clang] Add Parse and Sema support for RegularKeyword attributes
This patch adds the Parse and Sema support for RegularKeyword attributes,
following on from a previous patch that added Attr.td support.

The patch is quite large.  However, nothing outside the tests is
specific to the first RegularKeyword attribute (__arm_streaming).
The patch should therefore be a one-off, up-front cost.  Other
attributes just need an entry in Attr.td and the usual Sema support.

The approach taken in the patch is that the keywords can be used with
any language version.  If standard attributes were added in language
version Y, the keyword rules for version X<Y are the same as they were
for version Y (to the extent possible).  Any extensions beyond Y are
handled in the same way for both keywords and attributes.  This ensures
that existing C++11 successors like C++17 are not treated differently
from versions that have yet to be defined.

Some notes on the implementation:

* The patch emits errors rather than warnings for diagnostics that
relate to keywords.

* Where possible, the patch drops “attribute” from diagnostics
relating to keywords.

* One exception to the previous point is that warnings about C++
extensions do still mention attributes.  The use there seemed OK
since the diagnostics are noting a change in the production rules.

* If a diagnostic string needs to be different for keywords and
attributes, the patch standardizes on passing the attribute/
name/token followed by 0 for attributes and 1 for keywords.

* Although the patch updates warn_attribute_wrong_decl_type_str,
warn_attribute_wrong_decl_type, and warn_attribute_wrong_decl_type,
only the error forms of these strings are used for keywords.

* I couldn't trigger the warnings in checkUnusedDeclAttributes,
even for existing attributes.  An assert on the warnings caused
no failures in the testsuite.  I think in practice all standard
attributes would be diagnosed before this.

* The patch drops a call to standardAttributesAllowed in
ParseFunctionDeclarator.  This is because MaybeParseCXX11Attributes
checks the same thing itself, where appropriate.

* The new tests are based on c2x-attributes.c and
cxx0x-attributes.cpp.  The C++ test also incorporates a version of
cxx11-base-spec-attributes.cpp.  The FIXMEs are carried across from
the originals.

Differential Revision: https://reviews.llvm.org/D148702
2023-05-31 10:43:10 +01:00
yronglin
f75b73549d [Clang][Attribute] Improve the AST/diagnoses fidelity of alignas and _Alignas
- Fix diagnoses when the argument to `alignas` or `_Alignas` is an incomplete type.

Before:
```
./alignas.cpp:1:15: error: invalid application of 'alignof' to an incomplete type 'void'
class alignas(void) Foo {};
             ~^~~~~
1 error generated.
```
Now:
```
./alignas.cpp:1:15: error: invalid application of 'alignas' to an incomplete type 'void'
class alignas(void) Foo {};
             ~^~~~~
1 error generated.
```

- Improve the AST fidelity of `alignas` and `_Alignas` attribute.

Before:
```
AlignedAttr 0x13f07f278 <col:7> alignas
    `-ConstantExpr 0x13f07f258 <col:15, col:21> 'unsigned long'
      |-value: Int 8
      `-UnaryExprOrTypeTraitExpr 0x13f07f118 <col:15, col:21> 'unsigned long' alignof 'void *'
```

Now:
```
AlignedAttr 0x14288c608 <col:7> alignas 'void *'
```

Reviewed By: erichkeane

Differential Revision: https://reviews.llvm.org/D150528
2023-05-26 07:41:26 +08:00
Corentin Jabot
1b0ba1c12f [Clang] Fix parsing of (auto(x)).
Allow auto(x) to appear in a parenthesis
expression.

The pattern (auto( can appear as part of a declarator,
so the parser is modified to avoid the ambiguity,
in a way consistent with the proposed resolution to CWG1223.

Reviewed By: aaron.ballman, #clang-language-wg

Differential Revision: https://reviews.llvm.org/D149276
2023-05-20 13:22:58 +02:00