[C++20] [Modules] Diagnose if import statement lakcs a semicolon

Close https://github.com/llvm/llvm-project/issues/121066

Now we will diagnose that the import statement lacks a semicolon as
expecte

[C++20] [Modules] Diagnose if import statement lakcs a semicolon

Close https://github.com/llvm/llvm-project/issues/121066

Now we will diagnose that the import statement lacks a semicolon as
expected. Note that the original "not found" diagnose message remains.
I meant to remove that, but the test shows it might be more complex
process (other unexpected diagnose shows up). Given the importance of
the issue, I chose to not dig deeper.

show more ...

[clang][ObjectiveC] Fix Parsing the `::` Optional Scope Specifier (#119908)

The parser hangs when processing types/variables prefixed by `::` as an
optional scope specifier. For example,
```
- (i

[clang][ObjectiveC] Fix Parsing the `::` Optional Scope Specifier (#119908)

The parser hangs when processing types/variables prefixed by `::` as an
optional scope specifier. For example,
```
- (instancetype)init:(::A *) foo;
```

The parser should not hang, and it should emit an error. This PR
implements the error check.

rdar://140885078

show more ...

[Parse] Remove ParseDiagnostic.h (#116496)

This patch removes clang/Parse/ParseDiagnostic.h because it just
forwards to clang/Basic/DiagnosticParse.h.

[clang] Remove dead incremental Parser code (#102450)

When incremental processing is enabled, the Parser will never report
tok::eof but tok::annot_repl_input_end. However, that case is already
tak

[clang] Remove dead incremental Parser code (#102450)

When incremental processing is enabled, the Parser will never report
tok::eof but tok::annot_repl_input_end. However, that case is already
taken care of in IncrementalParser::ParseOrWrapTopLevelDecl() so this
check was never executing.

show more ...

Revert "[Clang] Implement P3034R1 Module Declarations Shouldn’t be Macros" (#99838)

Reverts llvm/llvm-project#90574

[Clang] Implement P3034R1 Module Declarations Shouldn’t be Macros (#90574)

This PR implement [P3034R1 Module Declarations Shouldn’t be
Macros](https://wg21.link/P3034R1), and refactor the convolute

[Clang] Implement P3034R1 Module Declarations Shouldn’t be Macros (#90574)

This PR implement [P3034R1 Module Declarations Shouldn’t be
Macros](https://wg21.link/P3034R1), and refactor the convoluted state
machines in module name lexical analysis.

---------

Signed-off-by: yronglin <yronglin777@gmail.com>
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
Co-authored-by: cor3ntin <corentinjabot@gmail.com>

show more ...

[HLSL] Implement `export` keyword (#96823)

Implements `export` keyword in HLSL.

There are two ways the `export` keyword can be used:
1. On individual function declarations
```
export void f()

[HLSL] Implement `export` keyword (#96823)

Implements `export` keyword in HLSL.

There are two ways the `export` keyword can be used:
1. On individual function declarations
```
export void f() {}
```
2. On a group of function declaration:
```
export {
void f1();
void f2() {}
}
```

Functions declared with the `export` keyword have external linkage. The
implementation does not include validation of when a function can or
cannot be exported, such as when it has resource argument or semantic
annotations. That will be covered by llvm/llvm-project#93330.

Currently all function declarations in global or named namespaces have
external linkage by default so there are no specific code changes
required right now to make sure exported function have external linkage
as well. That will change as part of llvm/llvm-project#92071. Any
additional changes to make sure exported functions still have external
linkage will be done as part of this work item.

Fixes #92812

show more ...

[clang] require arg list in type specifiers using template kw (#94674)

Require a template argument list after a name prefixed by the template
keyword in nested name specifiers. Addresses [CWG
96](

[clang] require arg list in type specifiers using template kw (#94674)

Require a template argument list after a name prefixed by the template
keyword in nested name specifiers. Addresses [CWG
96](https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#96)
which was superseded by
[P1787](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1787r6.html).

Followup to #80801.

show more ...

[clang] Introduce `SemaCodeCompletion` (#92311)

This patch continues previous efforts to split `Sema` up, this time
covering code completion.
Context can be found in #84184.
Dropping `Code` prefi

[clang] Introduce `SemaCodeCompletion` (#92311)

This patch continues previous efforts to split `Sema` up, this time
covering code completion.
Context can be found in #84184.
Dropping `Code` prefix from function names in `SemaCodeCompletion` would
make sense, but I think this PR has enough changes already.
As usual, formatting changes are done as a separate commit. Hopefully
this helps with the review.

show more ...

[clang][NFC] Remove `const_cast` from `ParseClassSpecifier`

[clang] Store FPOptions earlier when parsing function (#92146)

After https://github.com/llvm/llvm-project/pull/85605 ([clang] Set
correct FPOptions if attribute 'optnone' presents) the current FP

[clang] Store FPOptions earlier when parsing function (#92146)

After https://github.com/llvm/llvm-project/pull/85605 ([clang] Set
correct FPOptions if attribute 'optnone' presents) the current FP
options in Sema are saved during parsing function because Sema can
modify them if optnone is present. However they were saved too late, it
caused fails in some cases when precompiled headers are used. This patch
moves the storing earlier.

show more ...

[clang] Set correct FPOptions if attribute 'optnone' presents (#85605)

Attribute `optnone` must turn off all optimizations including fast-math
ones. Actually AST nodes in the 'optnone' function sti

[clang] Set correct FPOptions if attribute 'optnone' presents (#85605)

Attribute `optnone` must turn off all optimizations including fast-math
ones. Actually AST nodes in the 'optnone' function still had fast-math
flags. This change implements fixing FP options before function body is
parsed.

show more ...

[clang][NFC] Move `Sema::SkipBodyInfo` into namespace scope

This makes it forward-declarable, and needed from splitting `Sema` up.

[Clang] [C++26] Implement P2573R2: `= delete("should have a reason");` (#86526)

This implements support for the `= delete("message")` syntax that was
only just added to C++26
([P2573R2](https://is

[Clang] [C++26] Implement P2573R2: `= delete("should have a reason");` (#86526)

This implements support for the `= delete("message")` syntax that was
only just added to C++26
([P2573R2](https://isocpp.org/files/papers/P2573R2.html#proposal-scope)).

show more ...

[C++20] [Modules] Disambuguous Clang module and C++20 Named module further

This patch tries to make the boundary of clang module and C++20 named
module more clear.

The changes included:

- Rename `

[C++20] [Modules] Disambuguous Clang module and C++20 Named module further

This patch tries to make the boundary of clang module and C++20 named
module more clear.

The changes included:

- Rename `TranslationUnitKind::TU_Module` to
`TranslationUnitKind::TU_ClangModule`.
- Rename `Sema::ActOnModuleInclude` to `Sema::ActOnAnnotModuleInclude`.
- Rename `ActOnModuleBegin` to `Sema::ActOnAnnotModuleBegin`.
- Rename `Sema::ActOnModuleEnd` to `Sema::ActOnAnnotModuleEnd`.
- Removes a warning if we're trying to compile a non-module unit as
C++20 module unit. This is not actually useful and makes (the future)
implementation unnecessarily complex.

This patch meant to be a NFC fix. But it shows that it fixed a bug
suprisingly that previously we would surppress the unused-value warning
in named modules. Because it shares the same logic with clang modules,
which has headers semantics. This shows the change is meaningful.

show more ...

[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 b

[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.

show more ...

[Clang][Parse] Diagnose member template declarations with multiple declarators (#78243)

According to [temp.pre] p5:
> In a template-declaration, explicit specialization, or explicit instantiation t

[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`.

show more ...

[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

[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.

show more ...

[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.

[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.

show more ...

[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}:

[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.

show more ...

[clang] Add support for -fcx-limited-range, #pragma CX_LIMITED_RANGE and -fcx-fortran-rules. (#70244)

This patch adds the #pragma CX_LIMITED_RANGE defined in the C
specification.
It also adds the

[clang] Add support for -fcx-limited-range, #pragma CX_LIMITED_RANGE and -fcx-fortran-rules. (#70244)

This patch adds the #pragma CX_LIMITED_RANGE defined in the C
specification.
It also adds the options -f[no]cx-limited-range and
-f[no]cx-fortran-rules.
-fcx-limited-range enables algebraic formulas for complex multiplication
and division. This option is enabled with -ffast-math.
-fcx-fortran-rules enables algebraic formulas for complex multiplication
and enables Smith’s algorithm for complex division (SMITH, R. L.
Algorithm 116: Complex division. Commun. ACM 5, 8 (1962)).

---------

Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
Co-authored-by: Joseph Huber <jhuber6@vols.utk.edu>
Co-authored-by: Guray Ozen <guray.ozen@gmail.com>
Co-authored-by: Nishant Patel <nishant.b.patel@intel.com>
Co-authored-by: Jessica Clarke <jrtc27@jrtc27.com>
Co-authored-by: Petr Hosek <phosek@google.com>
Co-authored-by: Joseph Huber <35342157+jhuber6@users.noreply.github.com>
Co-authored-by: Craig Topper <craig.topper@sifive.com>
Co-authored-by: Alexander Yermolovich <43973793+ayermolo@users.noreply.github.com>
Co-authored-by: Usama Hameed <u_hameed@apple.com>
Co-authored-by: Philip Reames <preames@rivosinc.com>
Co-authored-by: Evgenii Kudriashov <evgenii.kudriashov@intel.com>
Co-authored-by: Fangrui Song <i@maskray.me>
Co-authored-by: Aart Bik <39774503+aartbik@users.noreply.github.com>
Co-authored-by: Valentin Clement <clementval@gmail.com>
Co-authored-by: Youngsuk Kim <youngsuk.kim@hpe.com>
Co-authored-by: Arthur Eubanks <aeubanks@google.com>
Co-authored-by: Jan Svoboda <jan_svoboda@apple.com>
Co-authored-by: Walter Erquinigo <a20012251@gmail.com>
Co-authored-by: Eric <eric@efcs.ca>
Co-authored-by: Fazlay Rabbi <106703039+mdfazlay@users.noreply.github.com>
Co-authored-by: Pete Lawrence <plawrence@apple.com>
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
Co-authored-by: Adrian Prantl <aprantl@apple.com>
Co-authored-by: Owen Pan <owenpiano@gmail.com>
Co-authored-by: LLVM GN Syncbot <llvmgnsyncbot@gmail.com>
Co-authored-by: Med Ismail Bennani <ismail@bennani.ma>
Co-authored-by: Congcong Cai <congcongcai0907@163.com>
Co-authored-by: Rik Huijzer <github@huijzer.xyz>
Co-authored-by: Wang Pengcheng <wangpengcheng.pp@bytedance.com>
Co-authored-by: Yuanfang Chen <tabloid.adroit@gmail.com>
Co-authored-by: Kazu Hirata <kazu@google.com>
Co-authored-by: Mehdi Amini <joker.eph@gmail.com>
Co-authored-by: Aiden Grossman <agrossman154@yahoo.com>
Co-authored-by: Rana Pratap Reddy <109514914+ranapratap55@users.noreply.github.com>
Co-authored-by: Yingwei Zheng <dtcxzyw2333@gmail.com>
Co-authored-by: Piotr Zegar <me@piotrzegar.pl>
Co-authored-by: KAWASHIMA Takahiro <t-kawashima@fujitsu.com>
Co-authored-by: Tobias Hieta <tobias@hieta.se>
Co-authored-by: Luke Lau <luke@igalia.com>
Co-authored-by: Shivam Gupta <shivam98.tkg@gmail.com>
Co-authored-by: cor3ntin <corentinjabot@gmail.com>
Co-authored-by: Yeting Kuo <46629943+yetingk@users.noreply.github.com>
Co-authored-by: Stanislav Mekhanoshin <rampitec@users.noreply.github.com>
Co-authored-by: David Spickett <david.spickett@linaro.org>
Co-authored-by: Matthew Devereau <matthew.devereau@arm.com>
Co-authored-by: Martin Storsjö <martin@martin.st>
Co-authored-by: Qiu Chaofan <qiucofan@cn.ibm.com>
Co-authored-by: Pierre van Houtryve <pierre.vanhoutryve@amd.com>
Co-authored-by: Mikael Holmen <mikael.holmen@ericsson.com>
Co-authored-by: Uday Bondhugula <uday@polymagelabs.com>
Co-authored-by: Nikita Popov <npopov@redhat.com>
Co-authored-by: Johannes Reifferscheid <jreiffers@google.com>
Co-authored-by: Benjamin Kramer <benny.kra@googlemail.com>
Co-authored-by: Oliver Stannard <oliver.stannard@arm.com>
Co-authored-by: Dmitry Vyukov <dvyukov@google.com>
Co-authored-by: Benjamin Maxwell <benjamin.maxwell@arm.com>
Co-authored-by: Piotr Sobczak <piotr.sobczak@amd.com>
Co-authored-by: Simon Pilgrim <llvm-dev@redking.me.uk>
Co-authored-by: Timm Bäder <tbaeder@redhat.com>
Co-authored-by: Sunil Kuravinakop <koops@hpe.com>
Co-authored-by: zhongyunde 00443407 <zhongyunde@huawei.com>
Co-authored-by: Christudasan Devadasan <Christudasan.Devadasan@amd.com>
Co-authored-by: bjacob <jacob.benoit.1@gmail.com>
Co-authored-by: Weining Lu <luweining@loongson.cn>
Co-authored-by: Andrzej Warzyński <andrzej.warzynski@arm.com>
Co-authored-by: Jay Foad <jay.foad@amd.com>
Co-authored-by: Markus Mützel <markus.muetzel@gmx.de>
Co-authored-by: Erik Jonsson <erik.j.jonsson@ericsson.com>
Co-authored-by: Pete Steinfeld <47540744+psteinfeld@users.noreply.github.com>
Co-authored-by: Alexey Bataev <a.bataev@outlook.com>
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
Co-authored-by: Qizhi Hu <836744285@qq.com>

show more ...

[OpenACC] Implement initial parsing for `parallel` construct (#72661)

As the first real parsing effort for the OpenACC implementation effort,
this implements the parsing for first construct/directi

[OpenACC] Implement initial parsing for `parallel` construct (#72661)

As the first real parsing effort for the OpenACC implementation effort,
this implements the parsing for first construct/directive name. This
does not do any semantic analysis, nor any of the clauses. Those will
come in a future patch.

For the time being, we warn when we hit a point that we don't implement
the parsing for either of these situations.

show more ...

[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.

[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 t

[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.

show more ...

Add two time-trace scope variables.

A time trace scope variable of `ParseDeclarationOrFunctionDefinition`
with the function's source location is added to record the time spent
parsing the function's

Add two time-trace scope variables.

A time trace scope variable of `ParseDeclarationOrFunctionDefinition`
with the function's source location is added to record the time spent
parsing the function's declaration or definition. Another time trace
scope variable of `ParseFunctionDefinition` is also added to record the
name of the defined function. A release note is added as well.

Reviewed by: Aaron Ballman
Pull request: #65268

show more ...