[clang] Extend diagnose_if to accept more detailed warning information, take 2 (#119712)

This is take two of #70976. This iteration of the patch makes sure that
custom
diagnostics without any warnin

[clang] Extend diagnose_if to accept more detailed warning information, take 2 (#119712)

This is take two of #70976. This iteration of the patch makes sure that
custom
diagnostics without any warning group don't get promoted by `-Werror` or
`-Wfatal-errors`.

This implements parts of the extension proposed in
https://discourse.llvm.org/t/exposing-the-diagnostic-engine-to-c/73092/7.

Specifically, this makes it possible to specify a diagnostic group in an
optional third argument.

show more ...

[SPIRV] Add Target Builtins using Distance ext as an example (#121598)

- Update pr labeler so new SPIRV files get properly labeled.
- Add distance target builtin to BuiltinsSPIRV.td.
- Update Targ

[SPIRV] Add Target Builtins using Distance ext as an example (#121598)

- Update pr labeler so new SPIRV files get properly labeled.
- Add distance target builtin to BuiltinsSPIRV.td.
- Update TargetBuiltins.h to account for spirv builtins.
- Update clang basic CMakeLists.txt to build spirv builtin tablegen.
- Hook up sema for SPIRV in Sema.h|cpp, SemaSPIRV.h|cpp, and
SemaChecking.cpp.
- Hookup sprv target builtins to SPIR.h|SPIR.cpp target.
- Update GBuiltin.cpp to emit spirv intrinsics when we get the expected
spirv target builtin.

Consensus was reach in this RFC to add both target builtins and pattern
matching:
https://discourse.llvm.org/t/rfc-add-targetbuiltins-for-spirv-to-support-hlsl/83329.

pattern matching will come in a separate pr this one just sets up the
groundwork to do target builtins for spirv.

partially resolves
[#99107](https://github.com/llvm/llvm-project/issues/99107)

show more ...

[HLSL] get inout/out ABI for array parameters working (#111047)

Get inout/out parameters working for HLSL Arrays.
Utilizes the fix from #109323, and corrects the assignment behavior
slightly to al

[HLSL] get inout/out ABI for array parameters working (#111047)

Get inout/out parameters working for HLSL Arrays.
Utilizes the fix from #109323, and corrects the assignment behavior
slightly to allow for Non-LValues on the RHS.
Closes #106917

---------

Co-authored-by: Chris B <beanz@abolishcrlf.org>

show more ...

[Sema] Remove unused includes (NFC) (#116461)

Identified with misc-include-cleaner.

[clang] Use {} instead of std::nullopt to initialize empty ArrayRef (#109399)

Follow up to #109133.

[clang] Deduplicate the logic that only warns once when stack is almost full (#112552)

Zero diff in behavior.

[Clang] [Sema] Don't crash on unexpanded pack in invalid block literal (#110762)

Consider #109148:
```c++
template <typename ...Ts>
void f() {
[] {
(^Ts);
};
}
```

When we

[Clang] [Sema] Don't crash on unexpanded pack in invalid block literal (#110762)

Consider #109148:
```c++
template <typename ...Ts>
void f() {
[] {
(^Ts);
};
}
```

When we encounter `^Ts`, we try to parse a block and subsequently call
`DiagnoseUnexpandedParameterPack()` (in `ActOnBlockArguments()`), which
sees `Ts` and sets `ContainsUnexpandedParameterPack` to `true` in the
`LambdaScopeInfo` of the enclosing lambda. However, the entire block is
subsequently discarded entirely because it isn’t even syntactically
well-formed. As a result, `ContainsUnexpandedParameterPack` is `true`
despite the lambda’s body no longer containing any unexpanded packs,
which causes an assertion the next time
`DiagnoseUnexpandedParameterPack()` is called.

This pr moves handling of unexpanded parameter packs into
`CapturingScopeInfo` instead so that the same logic is used for both
blocks and lambdas. This fixes this issue since the
`ContainsUnexpandedParameterPack` flag is now part of the block (and
before that, its `CapturingScopeInfo`) and no longer affects the
surrounding lambda directly when the block is parsed. Moreover, this
change makes blocks actually usable with pack expansion.

This fixes #109148.

show more ...

[clang][frontend] Support applying the annotate attribute to statements (#111841)

By allowing AnnotateAttr to be applied to statements, users can place arbitrary information in the AST for later use

[clang][frontend] Support applying the annotate attribute to statements (#111841)

By allowing AnnotateAttr to be applied to statements, users can place arbitrary information in the AST for later use.

For example, this can be used for HW-targeted language extensions that involve specialized loop annotations.

show more ...

[Clang] nonblocking/nonallocating attributes: 2nd pass caller/callee analysis (#99656)

- In Sema, when encountering Decls with function effects needing
verification, add them to a vector, DeclsWith

[Clang] nonblocking/nonallocating attributes: 2nd pass caller/callee analysis (#99656)

- In Sema, when encountering Decls with function effects needing
verification, add them to a vector, DeclsWithEffectsToVerify.
- Update AST serialization to include DeclsWithEffectsToVerify.
- In AnalysisBasedWarnings, use DeclsWithEffectsToVerify as a work
queue, verifying functions with declared effects, and inferring (when
permitted and necessary) whether their callees have effects.

---------

Co-authored-by: Doug Wyatt <dwyatt@apple.com>
Co-authored-by: Sirraide <aeternalmail@gmail.com>
Co-authored-by: Erich Keane <ekeane@nvidia.com>

show more ...

[AMDGPU] Specify width and align for all AMDGPU builtin types. NFC. (#109656)

This will be used in ASTContext::getTypeInfo which needs this
information for all builtin types, not just pointers.

Revert "[clang] Extend diagnose_if to accept more detailed warning information (#70976)"

This reverts commit e39205654dc11c50bd117e8ccac243a641ebd71f.

There are further discussions in
https://githu

Revert "[clang] Extend diagnose_if to accept more detailed warning information (#70976)"

This reverts commit e39205654dc11c50bd117e8ccac243a641ebd71f.

There are further discussions in
https://github.com/llvm/llvm-project/pull/70976, happening for past two
weeks. Since there were no responses for couple weeks now, reverting
until author is back.

show more ...

[clang] Don't call raw_string_ostream::flush() (NFC)

Don't call raw_string_ostream::flush(), which is essentially a no-op.
As specified in the docs, raw_string_ostream is always unbuffered

Fix OOM in FormatDiagnostic (2nd attempt) (#108866)

Resolves: #70930 (and probably latest comments from clangd/clangd#251)
by fixing racing for the shared DiagStorage value which caused messing wit

Fix OOM in FormatDiagnostic (2nd attempt) (#108866)

Resolves: #70930 (and probably latest comments from clangd/clangd#251)
by fixing racing for the shared DiagStorage value which caused messing with args inside the storage and then formatting the following message with getArgSInt(1) == 2:

def err_module_odr_violation_function : Error<
"%q0 has different definitions in different modules; "
"%select{definition in module '%2'|defined here}1 "
"first difference is "

which causes HandleSelectModifier to go beyond the ArgumentLen so the recursive call to FormatDiagnostic was made with DiagStr > DiagEnd that leads to infinite while (DiagStr != DiagEnd).

The Main Idea:
Reuse the existing DiagStorageAllocator logic to make all DiagnosticBuilders having independent states.
Also, encapsulating the rest of state (e.g. ID and Loc) into DiagnosticBuilder.

The last attempt failed -
https://github.com/llvm/llvm-project/pull/108187#issuecomment-2353122096
so was reverted - #108838

show more ...

[NFC] Move warning from CodeGen to Sema. (#107397)

This is a warning that wasn't associated with the source location. Moved
it to Sema and changed the warning message to a more verbose one.

Revert "Fix OOM in FormatDiagnostic" (#108838)

Reverting due to build failures found in #108187

Fix OOM in FormatDiagnostic (#108187)

Resolves: #70930 (and probably latest comments from
https://github.com/clangd/clangd/issues/251)
by fixing racing for the shared `DiagStorage` value which cau

Fix OOM in FormatDiagnostic (#108187)

Resolves: #70930 (and probably latest comments from
https://github.com/clangd/clangd/issues/251)
by fixing racing for the shared `DiagStorage` value which caused messing
with args inside the storage and then formatting the following message
with `getArgSInt(1)` == 2:
```
def err_module_odr_violation_function : Error<
"%q0 has different definitions in different modules; "
"%select{definition in module '%2'|defined here}1 "
"first difference is "
```
which causes `HandleSelectModifier` to go beyond the `ArgumentLen` so
the recursive call to `FormatDiagnostic` was made with `DiagStr` >
`DiagEnd` that leads to infinite `while (DiagStr != DiagEnd)`.

**The Main Idea:**
Reuse the existing `DiagStorageAllocator` logic to make all
`DiagnosticBuilder`s having independent states.
Also, encapsulating the rest of state (e.g. ID and Loc) into
`DiagnosticBuilder`.

**TODO (if it will be requested by reviewer):**
- [x] add a test (I have no idea how to turn a whole bunch of my
proprietary code which leads `clangd` to OOM into a small public
example.. probably I must try using
[this](https://github.com/llvm/llvm-project/issues/70930#issuecomment-2209872975)
instead)
- [x] [`Diag.CurDiagID !=
diag::fatal_too_many_errors`](https://github.com/llvm/llvm-project/pull/108187#pullrequestreview-2296395489)
- [ ] ? get rid of `DiagStorageAllocator` at all and make
`DiagnosticBuilder` having they own `DiagnosticStorage` coz it seems
pretty small so should fit the stack for short-living
`DiagnosticBuilder` instances

show more ...

Reapply "Reapply "[clang] Extend diagnose_if to accept more detailed warning information (#70976)" (#108453)"

This reverts commit e1bd9740faa62c11cc785a7b70ec1ad17e286bd1.

Fixes incorrect use of th

Reapply "Reapply "[clang] Extend diagnose_if to accept more detailed warning information (#70976)" (#108453)"

This reverts commit e1bd9740faa62c11cc785a7b70ec1ad17e286bd1.

Fixes incorrect use of the `DiagnosticsEngine` in the clangd tests.

show more ...

Revert "Reapply "[clang] Extend diagnose_if to accept more detailed warning information (#70976)" (#108453)"

This reverts commit e7f782e7481cea23ef452a75607d3d61f5bd0d22.

This had UBSan failures:

Revert "Reapply "[clang] Extend diagnose_if to accept more detailed warning information (#70976)" (#108453)"

This reverts commit e7f782e7481cea23ef452a75607d3d61f5bd0d22.

This had UBSan failures:

[----------] 1 test from ConfigCompileTests
[ RUN ] ConfigCompileTests.DiagnosticSuppression
Config fragment: compiling <unknown>:0 -> 0x00007B8366E2F7D8 (trusted=false)
/usr/local/google/home/fmayer/large/llvm-project/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:203:33: runtime error: reference binding to null pointer of type 'clang::DiagnosticIDs'

UndefinedBehaviorSanitizer: undefined-behavior /usr/local/google/home/fmayer/large/llvm-project/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:203:33

Pull Request: https://github.com/llvm/llvm-project/pull/108645

show more ...

Reapply "[clang] Extend diagnose_if to accept more detailed warning information (#70976)" (#108453)

This reverts commit e0cd11eba526234ca14a0b91f5598ca3363b6aca.

Update the use of `getWarningOpti

Reapply "[clang] Extend diagnose_if to accept more detailed warning information (#70976)" (#108453)

This reverts commit e0cd11eba526234ca14a0b91f5598ca3363b6aca.

Update the use of `getWarningOptionForDiag` in flang to use the
DiagnosticIDs.

show more ...

Revert "[clang] Extend diagnose_if to accept more detailed warning information (#70976)"

This reverts commit 030c6da7af826b641db005be925b20f956c3a6bb.

Several build bots are failing:
https://lab.ll

Revert "[clang] Extend diagnose_if to accept more detailed warning information (#70976)"

This reverts commit 030c6da7af826b641db005be925b20f956c3a6bb.

Several build bots are failing:
https://lab.llvm.org/buildbot/#/builders/89/builds/6211
https://lab.llvm.org/buildbot/#/builders/157/builds/7578
https://lab.llvm.org/buildbot/#/builders/140/builds/6429

show more ...

[clang] Extend diagnose_if to accept more detailed warning information (#70976)

This implements parts of the extension proposed in
https://discourse.llvm.org/t/exposing-the-diagnostic-engine-to-c/7

[clang] Extend diagnose_if to accept more detailed warning information (#70976)

This implements parts of the extension proposed in
https://discourse.llvm.org/t/exposing-the-diagnostic-engine-to-c/73092/7.

Specifically, this makes it possible to specify a diagnostic group in an
optional third argument.

show more ...

Fix GCC Wimplicit-fallthrough warnings. NFC.

[clang][NFC] Clean up `Sema` headers

When various `Sema*.h` and `Sema*.cpp` files were created, cleanup of
`Sema.h` includes and forward declarations was left for the later.
Now's the time. This com

[clang][NFC] Clean up `Sema` headers

When various `Sema*.h` and `Sema*.cpp` files were created, cleanup of
`Sema.h` includes and forward declarations was left for the later.
Now's the time. This commit touches `Sema.h` and Sema components:
1. Unused includes are removed.
2. Unused forward declarations are removed.
3. Missing includes are added (those files are largely IWYU-clean now).
4. Includes were converted into forward declarations where possible.

As this commit focuses on headers, all changes to `.cpp` files were
minimal, and were aiming at keeping everything buildable.

show more ...

[C++20] [Modules] Emit Errors when compiling a non-module source as module (#102565)

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

The root cause of the issue is that I removed the cod

[C++20] [Modules] Emit Errors when compiling a non-module source as module (#102565)

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

The root cause of the issue is that I removed the codes before and
failed to recognize it in time and this was not found for a long time
due to it only crashes with invalid codes.

show more ...

Reland "[Modules] Fix using `va_list` with modules and a precompiled header. (#100837)"

Fix the false warning
> incompatible pointer types passing 'va_list' (aka '__builtin_va_list')
to parameter

Reland "[Modules] Fix using `va_list` with modules and a precompiled header. (#100837)"

Fix the false warning
> incompatible pointer types passing 'va_list' (aka '__builtin_va_list')
to parameter of type 'struct __va_list_tag *'
[-Wincompatible-pointer-types]

The warning is wrong because both in the function declaration and at the
call site we are using `va_list`.

When we call `ASTContext::getBuiltinVaListDecl` at a specific moment, we
end up re-entering this function which causes creating 2 instances of
`BuiltinVaListDecl` and 2 instances of `VaListTagDecl` but the stored
instances are unrelated to each other because of the call sequence like

getBuiltinVaListDecl
CreateX86_64ABIBuiltinVaListDecl
VaListTagDecl = TagA
indirectly call getBuiltinVaListDecl
CreateX86_64ABIBuiltinVaListDecl
VaListTagDecl = TagB
BuiltinVaListDecl = ListB
BuiltinVaListDecl = ListA

Now we have `BuiltinVaListDecl == ListA` and `VaListTagDecl == TagB`.

For x86_64 '__builtin_va_list' and 'struct __va_list_tag *' are
compatible because '__builtin_va_list' == '__va_list_tag[1]'. But
because we have unrelated decls for VaListDecl and VaListTagDecl the
types are considered incompatible as we are comparing type pointers.

Fix the error by creating `BuiltinVaListDecl` before
`ASTReader::InitializeSema`, so that during
`ASTContext::getBuiltinVaListDecl` ASTReader doesn't try to de-serialize
'__builtin_va_list' and to call `ASTContext::getBuiltinVaListDecl`
again.

Reland with the requirement to have x86 target to avoid errors like
> error: unable to create target: 'No available targets are compatible
with triple "x86_64-apple-darwin"'

rdar://130947515

show more ...