aboutsummaryrefslogtreecommitdiff
path: root/libjava/classpath/gnu/java/awt/Buffers.java
diff options
context:
space:
mode:
Diffstat (limited to 'libjava/classpath/gnu/java/awt/Buffers.java')
0 files changed, 0 insertions, 0 deletions
generated by cgit v1.1 at 2026-02-24 10:52:30 +0000
-dap'>revert-149394-dexter-add-dap Unnamed repository; edit this file 'description' to name the repository.root
aboutsummaryrefslogtreecommitdiff
path: root/clang
AgeCommit message (Collapse)AuthorFilesLines
2025-12-16[clang][NFC] Remove useless `const_cast` in `CFGWalker` (#172549)David Stone1-4/+2
We have two `const_cast`, but the function those pointers are passed to accept pointers to `const`.
2025-12-16[clang][NFC] Make `ClassifyRefs` and `TransferFunctions` const-correct (#172544)David Stone1-49/+51
2025-12-16[LFI] Introduce AArch64 LFI Target (#167061)Zachary Yedidia5-0/+68
This PR is the first step towards introducing LFI into LLVM as a new sub-architecture backend of AArch64. For details, please see the [RFC](https://discourse.llvm.org/t/rfc-lightweight-fault-isolation-lfi-efficient-native-code-sandboxing-upstream-lfi-target-and-compiler-changes/88380), which has been approved for AArch64. This patch creates the `aarch64_lfi` architecture, and marks the appropriate registers as reserved when it is targeted (`x25`, `x26`, `x27`, `x28`). It also adds a Clang driver toolchain for targeting LFI, and updates the compiler-rt CMake to allow builds for the `aarch64_lfi` target. The patch also includes documentation for LFI and the rewrites that will be implemented in future patches. I am planning to split the relevant modifications for LFI into a series of patches, organized as described below (after this one). Please let me know if you'd like me to split the changes in a different way, or provide one big patch. 1. The next patch will introduce the `MCLFIExpander` mechanism for applying the MC-level rewrites needed by LFI, along with the `.lfi_expand` and `.lfi_no_expand` assembly directives when targeting LFI. A preview can be seen on the `lfi-project` [fork](https://github.com/llvm/llvm-project/compare/main...lfi-project:llvm-project:lfi-patchset/aarch64-pr-2). 2. The following patch will create an `MCLFIExpander` for the AArch64 backend that performs LFI expansions. This patch will contain the majority of the LFI-specific logic. 3. The final patch will add an optimization to the rewriter that can eliminate redundant guard instructions that occur within the same basic block. We plan to introduce x86-64 support after further discussion and once the `MCLFIExpander` infrastructure is in place. Please let me know your feedback, and thank you very much for your help and guidance in the review process.
2025-12-16[CIR] Support Try catch with handler for specific type (#171042)Amr Hesham7-25/+316
Add support for try-catch with a handler for a specific exception type Issue https://github.com/llvm/llvm-project/issues/154992
2025-12-16[C++20][Modules][NFC] Some minor non-functional fixes (#172524)Michael Park2-4/+4
2025-12-16[flang][driver] Add options -fdefault-integer-4 and -fdefault-real-4Tarun Prabhu2-0/+6
These options are supported by the Intel compiler. There are similar options in the IBM compiler as well. Each of the options can be provided more than once. In that case, the last occurence of -fdefault-real-* (respectively -fdefault-integer-*) is used if both -fdefault-real-4 and -fdefault-real-8 are specified. The fdefault.f90 test file was extensively modified. Testing handling of the options by the driver was removed since testing handling of the options by -fc1 is sufficient. Fixes #160252
2025-12-16[clang][NFC] In `CFGStmtMap`, remove mutable `getBlock` overload. (#172364)David Stone2-7/+3
The mutable version of the overload is not used. The way we implemented code sharing in the const vs. mutable overloads had a const-correctness violation, anyway.
2025-12-16[clang][deps] Prefer `DiagnosticConsumer` over `llvm::{Error,Expected}` ↵Jan Svoboda7-140/+84
(#172389) This PR moves the `DependencyScanning{Worker,Tool}` APIs from using `llvm::{Error,Expected}` to using `DiagnosticConsumer`. This makes it possible to learn about non-error diagnostics (warnings, remarks) emitted by the scanner. I found a need for this while exploring the possibility of caching dependency scans and emitting remarks to report cache hits/misses.
2025-12-16[Clang] [Headers] Actually install the stddefer.h header (#172512)Sirraide1-0/+1
I forgot to add the `stddefer.h` header to this list, which causes it to not be found at the moment: (see https://godbolt.org/z/arc18rhrK).
2025-12-16[clang-tidy] `bugprone-unchecked-optional-access`: handle inheritance from ↵Valentyn Yukhymenko1-2/+7
`BloombergLP::bslstl::Optional_Base` to prevent false-positives for allocator-aware BDE types (#168863) ### Problem `bugprone-unchecked-optional-access` produces a lot of false positives if type inside of `bsl::optional` or `bdlb::NullableValue` is **allocator-aware**. This is a very common pattern, especially due to frequent use of `bsl::string`. [Compiler explorer example to showcase false-positives with BDE library](https://compiler-explorer.com/z/P4zh7KbGx) ### Context https://github.com/llvm/llvm-project/pull/101450 added support for analysing `bsl::optional` access patterns. However, mock `bsl::optional` type has been very simplified for testing purposes which lead to missing false-positives related to _inheritance_ logic for this type. [According to this article](https://bloomberg.github.io/bde/articles/bsl_optional.html#interoperability-between-bsl-optional-and-bdlb-nullablevalue), there are two ways of inheritance for `bsl::optional` and `bdlb::NullableValue`: 1. C++17 non-allocator-aware type ` bdlb::NullableValue<T> -> bsl::optional<T> -> std::optional<T>` 2. C++17 **Allocator-Aware**, and pre-C++17 `bdlb::NullableValue<T> -> bsl::optional<T>` But this is not a full picture :( In practice, there is an additional layer in the inheritance chain: `BloombergLP::bslstl::Optional_Base`. Thus, the actual inheritance structure is: 1. C++17 non-allocator-aware `bdlb::NullableValue<T> -> bsl::optional<T> -> BloombergLP::bslstl::Optional_Base<T, false> -> std::optional<T>` 2. C++17 **Allocator-Aware**, and pre-C++17 `bdlb::NullableValue<T> -> bsl::optional<T> -> BloombergLP::bslstl::Optional_Base<T, true>` [Source code to show this inheritance](https://github.com/bloomberg/bde/blob/f8b09a9298a5a76741c0820344c8850bf0b2e177/groups/bsl/bslstl/bslstl_optional.h#L1851) ### Root cause IIUC, because of this inheritance logic, function calls to `bsl::optional::has_value()` are processed like: 1. `std::optional::has_value()` for non-allocator-aware type. 2. `BloombergLP::bslstl::Optional_Base::has_value()` for allocator-aware type. Obviously, similar conversion are true for other common methods like `.value()` **This PR tries to solve this issue by improving mocks and adding `BloombergLP::bslstl::Optional_Base<T>` to list of supported optional types**
2025-12-16[OpenMP][CIR] Implement basic 'parallel' lowering + some clause infra (#172308)Erich Keane7-5/+155
This patch adds some basic lowering for the OMP 'parallel' lowering, which adds an omp.parallel operation, plus tries to insert into its region, with a omp.terminator operation.. However, this patch doesn't implement CapturedStmt (and I don't intend to do so at all), so there is an NYI error when emitting a parallel region (plus it shows up in IR as 'empty'. This patch also adds some infrastructure to 'lower' clauses, however no clauses are emitted, and this simply adds a 'not yet implemented' warning any time a clause is attempted. The OMP clause visitor seems to have had a bug with how it 'degraded' when a clause wasn't handled (it would result in an infinite recursion if it wasn't supplied), so this fixes that as well. A followup patch or two may use this infrastructure to demonstrate how to use it.
2025-12-16[OpenMP][CIR] Implement 'barrier' lowering (#172305)Erich Keane2-2/+17
As my next patch showing how OMP lowering should work, here is a simple construct implementation. Best I can tell, the 'barrier' construct just results in a omp.barrier to be emitted into the IR. This is our first use of the omp dialect, though the dialect was already added in my last patch.
2025-12-16[AArch64] Add support for C1 CPUs (#171124)dcandler7-0/+299
This patch adds initial support for the Arm v9.3 C1 processors: * C1-Nano * C1-Pro * C1-Premium * C1-Ultra For more information on each, see: https://developer.arm.com/Processors/C1-Nano https://developer.arm.com/Processors/C1-Pro https://developer.arm.com/Processors/C1-Premium https://developer.arm.com/Processors/C1-Ultra Technical Reference Manual for C1-Nano: https://developer.arm.com/documentation/107753/latest/ Technical Reference Manual for C1-Pro: https://developer.arm.com/documentation/107771/latest/ Technical Reference Manual for C1-Premium: https://developer.arm.com/documentation/109416/latest/ Technical Reference Manual for C1-Ultra: https://developer.arm.com/documentation/108014/latest/
2025-12-16[CLANG] Fixes the crash on the use of nested requirements in require ↵Ebin Jose3-0/+16
expressions (#169876) Fixes #165386 Nested requirements in requires-expressions must be constant expressions. Previously, using an invented parameter in a nested requirement caused a crash. Now emit a clear diagnostic and recover.
2025-12-16[Headers][X86] Allow vector bitcast intrinsics to be used in constexpr (#167180)Red-RobinHood4-30/+71
Fixes #156348
2025-12-16[CGHLSLRuntime] Use getSigned() for total array sizeNikita Popov1-2/+2
This may be -1 for incompete array types.
2025-12-16[CGObjCGNU] Set isSigned for negative valueNikita Popov1-4/+6
2025-12-16[ItaniumCXXABI] Use getSigned() for signed offsetNikita Popov1-1/+1
2025-12-16[CGBuilder] Use getSigned() for CharUnitsNikita Popov1-1/+1
CharUnits holds a signed quantity.
2025-12-16[libclang/python] Remove unused import in example (#172369)Thomas Applencourt2-2/+2
Remove unused `OptionGroup` import in some `cindex.py` example.
2025-12-16[libclang/python] Add LIBCLANG_LIBRARY_PATH and LIBCLANG_LIBRARY_FILE (#170201)Thomas Applencourt25-97/+91
Close #167421 This PR adds the environment variables ``LIBCLANG_LIBRARY_PATH`` and ``LIBCLANG_LIBRARY_FILE``, which allow users to specify the directory path and the exact library file that should be used to locate libclang. --------- Co-authored-by: Jannick Kremer <jannick.kremer@mailbox.org> Co-authored-by: Vlad Serebrennikov <serebrennikov.vladislav@gmail.com>
2025-12-16Enable libarcher in LLVM releases (#172310)Leandro Lupori1-3/+0
It was disabled due to #170138, which is fixed now.
2025-12-16Revert "[clang][analyzer] Format macro expansions" (#172468)Balázs Benics8-154/+139
Reverts llvm/llvm-project#156046 See https://github.com/llvm/llvm-project/pull/156046#issuecomment-3660172948 ``` 11.210 [660/22/4115] Linking CXX shared library lib/libclangAnalysis.so.22.0git FAILED: lib/libclangAnalysis.so.22.0git : && /usr/bin/c++ -fPIC -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-uninitialized -Wno-nonnull -Wno-class-memaccess -Wno-redundant-move -Wno-pessimizing-move -Wno-array-bounds -Wno-stringop-overread -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment -Wno-misleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -ffunction-sections -fdata-sections -fno-common -Woverloaded-virtual -O3 -DNDEBUG -Wl,-z,defs -Wl,-z,nodelete -Wl,-rpath-link,/home/botworker/builds/openmp-offload-amdgpu-runtime-2/llvm.build/./lib -Wl,--gc-sections -shared -Wl,-soname,libclangAnalysis.so.22.0git -o lib/libclangAnalysis.so.22.0git tools/clang/lib/Analysis/CMakeFiles/obj.clangAnalysis.dir/AnalysisDeclContext.cpp.o tools/clang/lib/Analysis/CMakeFiles/obj.clangAnalysis.dir/BodyFarm.cpp.o tools/clang/lib/Analysis/CMakeFiles/obj.clangAnalysis.dir/CalledOnceCheck.cpp.o tools/clang/lib/Analysis/CMakeFiles/obj.clangAnalysis.dir/CFG.cpp.o tools/clang/lib/Analysis/CMakeFiles/obj.clangAnalysis.dir/CFGReachabilityAnalysis.cpp.o tools/clang/lib/Analysis/CMakeFiles/obj.clangAnalysis.dir/CFGStmtMap.cpp.o tools/clang/lib/Analysis/CMakeFiles/obj.clangAnalysis.dir/CallGraph.cpp.o tools/clang/lib/Analysis/CMakeFiles/obj.clangAnalysis.dir/CloneDetection.cpp.o tools/clang/lib/Analysis/CMakeFiles/obj.clangAnalysis.dir/CocoaConventions.cpp.o tools/clang/lib/Analysis/CMakeFiles/obj.clangAnalysis.dir/ConstructionContext.cpp.o tools/clang/lib/Analysis/CMakeFiles/obj.clangAnalysis.dir/Consumed.cpp.o tools/clang/lib/Analysis/CMakeFiles/obj.clangAnalysis.dir/CodeInjector.cpp.o tools/clang/lib/Analysis/CMakeFiles/obj.clangAnalysis.dir/Dominators.cpp.o tools/clang/lib/Analysis/CMakeFiles/obj.clangAnalysis.dir/ExprMutationAnalyzer.cpp.o tools/clang/lib/Analysis/CMakeFiles/obj.clangAnalysis.dir/FixitUtil.cpp.o tools/clang/lib/Analysis/CMakeFiles/obj.clangAnalysis.dir/IntervalPartition.cpp.o tools/clang/lib/Analysis/CMakeFiles/obj.clangAnalysis.dir/IssueHash.cpp.o tools/clang/lib/Analysis/CMakeFiles/obj.clangAnalysis.dir/LiveVariables.cpp.o tools/clang/lib/Analysis/CMakeFiles/obj.clangAnalysis.dir/MacroExpansionContext.cpp.o tools/clang/lib/Analysis/CMakeFiles/obj.clangAnalysis.dir/ObjCNoReturn.cpp.o tools/clang/lib/Analysis/CMakeFiles/obj.clangAnalysis.dir/PathDiagnostic.cpp.o tools/clang/lib/Analysis/CMakeFiles/obj.clangAnalysis.dir/PostOrderCFGView.cpp.o tools/clang/lib/Analysis/CMakeFiles/obj.clangAnalysis.dir/ProgramPoint.cpp.o tools/clang/lib/Analysis/CMakeFiles/obj.clangAnalysis.dir/ReachableCode.cpp.o tools/clang/lib/Analysis/CMakeFiles/obj.clangAnalysis.dir/RetainSummaryManager.cpp.o tools/clang/lib/Analysis/CMakeFiles/obj.clangAnalysis.dir/ThreadSafety.cpp.o tools/clang/lib/Analysis/CMakeFiles/obj.clangAnalysis.dir/ThreadSafetyCommon.cpp.o tools/clang/lib/Analysis/CMakeFiles/obj.clangAnalysis.dir/ThreadSafetyLogical.cpp.o tools/clang/lib/Analysis/CMakeFiles/obj.clangAnalysis.dir/ThreadSafetyTIL.cpp.o tools/clang/lib/Analysis/CMakeFiles/obj.clangAnalysis.dir/UninitializedValues.cpp.o tools/clang/lib/Analysis/CMakeFiles/obj.clangAnalysis.dir/UnsafeBufferUsage.cpp.o -Wl,-rpath,"\$ORIGIN/../lib:/home/botworker/builds/openmp-offload-amdgpu-runtime-2/llvm.build/lib:" lib/libclangASTMatchers.so.22.0git lib/libclangFormat.so.22.0git lib/libclangAST.so.22.0git lib/libclangLex.so.22.0git lib/libclangBasic.so.22.0git lib/libLLVMFrontendOpenMP.so.22.0git lib/libLLVMSupport.so.22.0git -Wl,-rpath-link,/home/botworker/builds/openmp-offload-amdgpu-runtime-2/llvm.build/lib && : /usr/bin/ld: tools/clang/lib/Analysis/CMakeFiles/obj.clangAnalysis.dir/MacroExpansionContext.cpp.o: in function `clang::MacroExpansionContext::getFormattedExpandedText(clang::SourceLocation) const': MacroExpansionContext.cpp:(.text._ZNK5clang21MacroExpansionContext24getFormattedExpandedTextENS_14SourceLocationE+0x274): undefined reference to `clang::tooling::applyAllReplacements[abi:cxx11](llvm::StringRef, clang::tooling::Replacements const&)' collect2: error: ld returned 1 exit status ```
2025-12-16[Clang] Fix crash on malformed std::partial_ordering static members (#172001)Pankaj3-2/+62
This fixes a crash (segmentation fault) when the standard library implementation of comparison categories (like `std::partial_ordering`) is malformed. Specifically, if the static members (like `equivalent`) are defined as a primitive type (e.g., `int`) instead of the comparison category type itself, the compiler previously attempted to process them incorrectly, leading to a crash. This adds strict type checking in `ComparisonCategoryInfo::lookupValueInfo`. If the found static member does not match the record type, it is rejected safely, triggering a diagnostic error instead of a crash. Fixes #170015 Fixes #56571
2025-12-16[clang][analyzer] Format macro expansions (#156046)ankurkraj8-139/+154
Fixes #154743
2025-12-16[CGExprScalar] Use getSigned() for signed valueNikita Popov1-1/+1
2025-12-16[CGExpr] Use getSigned() for negative constantNikita Popov1-1/+1
2025-12-16[CGVTables] Use getSigned() for signed offsetNikita Popov1-2/+2
2025-12-16[CGOpenMP] Use getSigned() for NumTeams constantNikita Popov1-1/+1
This value may be -1.
2025-12-16[AArch64] Add intrinsics support for SVE2p2 instructions (#163575)Lukacma12-0/+1300
This patch add intrinsics for SVE2p2 instructions defined in [this](https://github.com/ARM-software/acle/pull/412) ACLE proposal. Intrinsics added: ``` // Variants are available for: // _s8, _s16, _u16, _mf8, _bf16, _f16 svuint8_t svcompact[_u8](svbool_t pg, svuint8_t zn); // Variants are available for: // _s8, _s16, _u16, _s32, _u32, _s64, _u64 // _mf8, _bf16, _f16, _f32, _f64 svuint8_t svexpand[_u8](svbool_t pg, svuint8_t zn); // Variants are available for: // _b16, _b32, _b64 int64_t svfirstp_b8(svbool_t pg, svbool_t pn); // Variants are available for: // _b16, _b32, _b64 int64_t svlastp_b8(svbool_t pg, svbool_t pn); ``` It also generates Sema tests using aarch64_builtins_test_generator script for some previously merged intrinsics patches, which were merged without regenerating. --------- Co-authored-by: Kerry McLaughlin <kerry.mclaughlin@arm.com>
2025-12-16[sancov] Add -diff and -union options to compute set difference and union of ↵Manuel Carrasco1-12/+33
sancov files (#171191) Add two new actions for `.sancov` files: `-diff`: Computes the difference between two `.sancov` files (A - B) and writes the result to a new file. Requires exactly two inputs and an `--output` option. The output preserves the binary format (magic number and bitness) of the first input. `-union`: Computes the union of one or more `.sancov` files and writes the result to a new file. Requires at least one input and an `--output` option. The output preserves the binary format of the first input. A warning is shown if input files differ in bitness (32-bit vs 64-bit), but the operation proceeds using the first file’s bitness.
2025-12-16[Clang][C++26] Remove the notion of replaceability. (#172150)Corentin Jabot17-561/+58
In Kona, WG21 decided to revert trivial relocation (P2786). Given that the notion of replaceability that was introduced at the same time does not appear to be used by clang 21 users, and is less likely to come back, it is easier to fully remove wholesale. Subsequent patches will deal with relocation.
2025-12-16[NFC] [C++20] [Modules] Add a test for module local template instantiation ↵Chuanqi Xu1-0/+59
in namespace This was found when debugging https://github.com/llvm/llvm-project/issues/164466 I think more tests are always good. So I want to land this as a regression check.
2025-12-16[Clang] Remove 't' from __builtin_amdgcn_ds_atomic_fadd_f32/f64 (#172293)Juan Manuel Martinez Caamaño3-2/+64
Allows for type checking depending on the builtin signature.
2025-12-16[MicrosoftCXXABI] Use getSigned() for signed vptr offsetNikita Popov1-15/+18
2025-12-16[CodeGen] Use getAllOnesValue() for -1 constantsNikita Popov4-6/+6
2025-12-16[CGExprScalar] Fix inc/dec of vector larger than 64-bit (#172301)Nikita Popov2-5/+5
Use getSigned() to create the 1 or -1 constant, so it gets properly sign extended. This miscompile was found while working on https://github.com/llvm/llvm-project/pull/171456.
2025-12-15[C++20][Modules] Improve namespace look-up performance for modules. (#171769)Michael Park4-16/+318
## Problem Given code such as `N::foo();`, we perform name look-up on `N`. In the case where `N` is a namespace declared in imported modules, one namespace decl (the "key declaration") for each module that declares a namespace `foo` is loaded and stored. In large scales where there are many such modules, (e.g., 1,500) and many uses (e.g., 500,000), this becomes extremely inefficient because every look-up (500,000 of them) return 1,500 results. The following synthetic script demonstrates the problem: ```bash #/usr/bin/env bash CLANG=${CLANG:-clang++} NUM_MODULES=${NUM_MODULES:-1500} NUM_USES=${NUM_USES:-500000} USE_MODULES=${USE_MODULES:-true} TMPDIR=$(mktemp -d) echo "Working in temp directory: $TMPDIR" cd $TMPDIR trap "rm -rf \"$TMPDIR\"" EXIT echo "namespace N { inline void foo() {} }" > m1.h for i in $(seq 2 $NUM_MODULES); do echo "namespace N {}" > m${i}.h; done if $USE_MODULES; then seq 1 $NUM_MODULES | xargs -I {} -P $(nproc) bash -c "$CLANG -std=c++20 -fmodule-header m{}.h" fi > a.cpp if $USE_MODULES; then for i in $(seq 1 $NUM_MODULES); do echo "import \"m${i}.h\";" >> a.cpp; done else for i in $(seq 1 $NUM_MODULES); do echo "#include \"m${i}.h\"" >> a.cpp; done fi echo "int main() {" >> a.cpp for i in $(seq 1 $NUM_USES); do echo " N::foo();" >> a.cpp; done echo "}" >> a.cpp if $USE_MODULES; then time $CLANG -std=c++20 -Wno-experimental-header-units -c a.cpp -o /dev/null \ $(for i in $(seq 1 $NUM_MODULES); do echo -n "-fmodule-file=m${i}.pcm "; done) else time $CLANG -std=c++20 -Wno-experimental-header-units -c a.cpp -o /dev/null fi ``` As of 575d6892bcc5cef926cfc1b95225148262c96a15, without modules (`USE_MODULES=false`) this takes about **4.5s**, whereas with modules (`USE_MODULES=true`), this takes about **37s**. With this PR, without modules there's no change (as expected) at 4.5s, but with modules it improves to about **5.2s**. ## Approach The approach taken here aims to maintain status-quo with respect to the input and output of modules. That is, the `ASTReader` and `ASTWriter` both read and write the same declarations as it did before. The difference is in the middle part: the [`StoredDeclsMap` in `DeclContext`](https://github.com/llvm/llvm-project/blob/release/21.x/clang/include/clang/AST/DeclBase.h#L2024-L2030). The `StoredDeclsMap` is roughly a `map<DeclarationName, StoredDeclsList>`. Currently, we read all of the external namespace decls from `ASTReader`, they all get stored into the `StoredDeclsList`, and the `ASTWriter` iterates through that list and writes out the results. This PR continues to read all of the external namespace decls from `ASTReader`, but only stores one namespace decl in the `StoredDeclsList`. This is okay since the reading of the decls handles all of the merging and chaining of the namespace decls, and as long as they're loaded and chained, returning one for look-up purposes is sufficient. The other half of the problem is to write out all of the external namespaces that we used to store in `StoredDeclsList` but no longer. For this, we take advantage of the [`KeyDecls`](https://github.com/llvm/llvm-project/blob/release/21.x/clang/include/clang/Serialization/ASTReader.h#L1342-L1347) data structure in `ASTReader`. `KeyDecls` is roughly a `map<Decl *, vector<GlobalDeclID>>`, and it stores a mapping from the canonical decl of a redeclarable decl to a list of `GlobalDeclID`s where each ID represents a "key declaration" from each imported module. More to the point, if we read external namespaces `N1`, `N2`, `N3` in `ASTReader`, we'll either have `N1` mapped to `[N2, N3]`, or some newly local canonical decl mapped to `[N1, N2, N3]`. Either way, we can visit `N1`, `N2`, and `N3` by doing `ASTReader::forEachImportedKeyDecls(N1, Visitor)`, and we leverage this to maintain the current behavior of writing out all of the imported namespace decls in `ASTWriter`. ## Alternatives Attempted - Tried reading fewer declarations on the `ASTReader` side, and writing out fewer declarations on the `ASTWriter` side, and neither options worked at all. - Tried trying to split `StoredDeclsList` into two pieces, one with non-namespace decls and one with only namespace decls, but that didn't work well... I think because the order of the declarations matter sometimes, and maybe also because the declaration replacement logic gets more complicated. - Tried to deduplicate at the `SemaLookup` level. Basically, retrieve all the stored decls but deduplicate populating the `LookupResult` [here](https://github.com/llvm/llvm-project/blob/release/21.x/clang/lib/Sema/SemaLookup.cpp#L1137-L1144). This did improve things slightly, but not quite enough, and this solution seemed cleaner in the end anyway.
2025-12-16[clang-format] Align different categories together (#172242)sstwcw2-0/+9
How the program figured out which lines to move along the aligned lines changed in 75c85bafb830e5. Aligning the lines caused the information to be out of date for aligning different categories later on. It caused a regression. Fixes #171021. new, with the options `AlignConsecutiveAssignments` and `AlignConsecutiveDeclarations` enabled ```C++ const char *const MatHtoolCompressorTypes[] = {"sympartialACA", "fullACA", "SVD"}; const char HtoolCitation[] = "@article{marchand2020two,\n" " " " " " " "}\n"; ``` old ```C++ const char *const MatHtoolCompressorTypes[] = {"sympartialACA", "fullACA"}; const char HtoolCitation[] = "@article{marchand2020two,\n" " " " " " " "}\n"; ```
2025-12-16[CodeGen] Fix volatile inst, to match MSVC code semantics on windows (#171862)GkvJwa2-8/+10
Fix #126516 Use AtomicOrdering::Monotonic's atomic loading to let the backend automatically select the appropriate instructions to match MSVC semantics.
2025-12-15[clang][lex] Introduce new single-module-parse mode (#135813)Jan Svoboda5-9/+134
This PR introduces new single-module preprocessing mode. It is very similar to single-file-parse mode, but has the following differences: * Single-file mode skips over all inclusion directives, while the single-module mode skips only over import directives and does resolve textual inclusion directives. * Single-file mode enters all branches of a conditional directive with an undefined identifier, while the single-module enters none of them. This will be used from the dependency scanner to quickly discover a subset of modular dependencies of a TU/module. The dependencies aren't being imported in this mode, but the file-inclusion preprocessor callback does get invoked.
2025-12-15[OpenMP][Clang] Use `ATTACH` map-type for list-items with base-pointers. ↵Abhinav Gaba47-3888/+5396
(#153683) This adds support for using `ATTACH` map-type for proper pointer-attachment when mapping list-items that have base-pointers. For example, for the following: ```c int *p; #pragma omp target enter data map(p[1:10]) ``` The following maps are now emitted by clang: ``` (A) &p[0], &p[1], 10 * sizeof(p[1]), TO | FROM &p, &p[1], sizeof(p), ATTACH ``` Previously, the two possible maps emitted by clang were: ``` (B) &p[0], &p[1], 10 * sizeof(p[1]), TO | FROM (C) &p, &p[1], 10 * sizeof(p[1]), TO | FROM | PTR_AND_OBJ ```` (B) does not perform any pointer attachment, while (C) also maps the pointer p, both of which are incorrect. ----- With this change, we are using ATTACH-style maps, like `(A)`, for cases where the expression has a base-pointer. For example: ```cpp int *p, **pp; S *ps, **pps; ... map(p[0]) ... map(p[10:20]) ... map(*p) ... map(([20])p) ... map(ps->a) ... map(pps->p->a) ... map(pp[0][0]) ... map(*(pp + 10)[0]) ``` #### Grouping of maps based on attach base-pointers We also group mapping of clauses with the same base decl in the order of the increasing complexity of their base-pointers, e.g. for something like: ``` S **spp; map(spp[0][0], spp[0][0].a), // attach-ptr: spp[0] map(spp[0]), // attach-ptr: spp map(spp), // attach-ptr: N/A ``` We first map `spp`, then `spp[0]` then `spp[0][0]` and `spp[0][0].a`. This allows us to also group "struct" allocation based on their attach pointers. This resolves the issues of us always mapping everything from the beginning of the symbol `spp`. Each group is mapped independently, and at the same level, like `spp[0][0]` and its member `spp[0][0].a`, we still get map them together as part of the same contiguous struct `spp[0][0]`. This resolves issue #141042. #### use_device_ptr/addr fixes The handling of `use_device_ptr/addr` was updated to use the attach-ptr information, and works for many cases that were failing before. It has to be done as part of this series because otherwise, the switch from ptr_to_obj to attach-style mapping would have caused regressions in existing use_device_ptr/addr tests. #### Handling of attach-pointers that are members of implicitly mapped structs: * When a struct member-pointer, like `p` below, is a base-pointer in a `map` clause on a target construct (like `map(p[0:1])`, and the base of that struct is either the `this` pointer (implicitly or explicitly), or a struct that is implicitly mapped on that construct, we add an implicit `map(p)` so that we don't implicitly map the full struct. ```c struct S { int *p; void f1() { #pragma omp target map(p[0:1]) // Implicitly map this->p, to ensure // that the implicit map of `this[:]` does // not map the full struct printf("%p %p\n", &p, p); } ``` #### Scope for improvement: * We may be able to compute attach-ptr expr while collecting component-lists in Sema. * But we cache the computation results already, and `findAttachPtrExpr` is fairly simple, and fast. * There may be a better way to implement semantic expr comparison. #### Needs future work: * Attach-style maps not yet emitted for declare mappers. * Mapping of class member references: We are still using PTR_AND_OBJ maps for them. We will likely need to change that to handle `ref_ptr/ref_ptee`, and `attach` map-type-modifier on them. * Implicit capturing of "this" needs to map the full `this[0:1]` unless there is an explicit map on one of the members, or a map with a member as its base-pointer. * Implicit map added for capturing a class member pointer needs to also add a zero-length-array-section map. * `use_device_addr` on array-sections-on-pointers need further improvements (documented using FIXMEs) #### Why a large PR While it's unfortunate that this PR has gotten large and difficult to review, the issue is that all the functional changes have to be made together, to prevent regressions from partially implemented changes. For example, the changes to capturing were previously done separately (#145454), but they would still cause stability issues in absence of full attach-mapping. And attach-mapping needs those changes to be able to launch kernels. We extracted the utilities and functions, like those for finding attach-ptrs, or comparing exprs, out as a separate NFC PR that doesn't call those functions, just adds them (#155625). Maybe the change that adds a new error message for use_device_addr on array-sections with non-var base-pointers could have been extracted out too (but that would have had to be a follow-up change in that case, and we would get comp-fails with this PR when the erroneous case was not caught/diagnosed). --------- Co-authored-by: Alex Duran <alejandro.duran@intel.com>
2025-12-16[libclang/python] Fix cindex test for cpp lang (#172368)Thomas Applencourt1-1/+1
Fix typo in cindex.py where the C++ support test was incorrectly named test_c instead of test_cpp
2025-12-15[NFC][HIP] Disable device-side kernel launches for HIP (#171043)Alex Voicu1-1/+2
#165519 added support for launching kernels from the device side. This is only available in CUDA at the moment. We have to explicitly check whether we are compiling for HIP to guard against this path being exercised, since the CUDA and HIP languages rely on the same `CUDAIsDevice` bit to check for device side compilation, and it is not possible to disambiguate otherwise.
2025-12-15[CIR] Add support for EmbedExpr for ScalarExpr (#172088)Amr Hesham4-5/+78
Add support for the EmbedExpr for ScalarExpr
2025-12-15[clang][Dependency Scanning][NFC] Extract the DependencyScanningTool Logic ↵Qiongsi Wu2-16/+37
to Initialize the Compiler Instance With Context (#172345) #171238 moved the compiler instance with context initialization logic from DependencyScanningWorker to DependencyScanningTools. This led to a problem in the Swift fork (https://github.com/swiftlang/llvm-project/blob/905c010b8e793d85a1cfbbdb93dc29d75d06b343/clang/tools/libclang/CDependencies.cpp#L359) where we need to initialize the dependency scanning worker without an instance of the dependency scanning tool. This patch extracts the logic that generates the `cc1` command to a static method so we can facilitate this use case in Swift.
2025-12-15[CIR] Add BuildableType traits to relevant constraints (NFC) (#172224)Henrich Lauko7-42/+50
This also eliminates some explicit uses of buildable types.
2025-12-15[clang] Properly check for -mms-bitfields in Sema/struct-packed-align.c ↵Dan Klishch1-2/+3
(#172337) Before #71148, providing only `-triple=x86_64-windows-gnu` to cc1 did not set `-mms-bitfields` (`-fms-layout-compatibility=microsoft`). Therefore, MS-compatible layout was only triggered in true MSVC targets. This is not the case now, so we should only check if we are compiling for Windows to test to determine if MS layout will be used. The change of behavior is harmless as it only affects direct invocations of cc1.
2025-12-15hipcc/ld.lld unable to link separable compilation when dynamic librar… ↵David Salinas1-16/+22
(#169551) …y is fully specified --------- Co-authored-by: Omri Mor <omri50@gmail.com>
2025-12-15[clang][DependencyScanning] Use structured bindings for ↵Naveen Seth Hanig2-9/+2
initVFSForByNameScanning (NFC) (#172335)
generated by cgit v1.1 at 2026-02-24 10:52:30 +0000