aboutsummaryrefslogtreecommitdiff
path: root/clang/unittests/Basic
AgeCommit message (Collapse)AuthorFilesLines
2025-05-22Reapply "[clang] Remove intrusive reference count from `DiagnosticOptions` ↵Jan Svoboda3-17/+21
(#139584)" This reverts commit e2a885537f11f8d9ced1c80c2c90069ab5adeb1d. Build failures were fixed right away and reverting the original commit without the fixes breaks the build again.
2025-05-22Revert "[clang] Remove intrusive reference count from `DiagnosticOptions` ↵Kazu Hirata3-21/+17
(#139584)" This reverts commit 9e306ad4600c4d3392c194a8be88919ee758425c. Multiple builtbot failures have been reported: https://github.com/llvm/llvm-project/pull/139584
2025-05-22[clang] Remove intrusive reference count from `DiagnosticOptions` (#139584)Jan Svoboda3-17/+21
The `DiagnosticOptions` class is currently intrusively reference-counted, which makes reasoning about its lifetime very difficult in some cases. For example, `CompilerInvocation` owns the `DiagnosticOptions` instance (wrapped in `llvm::IntrusiveRefCntPtr`) and only exposes an accessor returning `DiagnosticOptions &`. One would think this gives `CompilerInvocation` exclusive ownership of the object, but that's not the case: ```c++ void shareOwnership(CompilerInvocation &CI) { llvm::IntrusiveRefCntPtr<DiagnosticOptions> CoOwner = &CI.getDiagnosticOptions(); // ... } ``` This is a perfectly valid pattern that is being actually used in the codebase. I would like to ensure the ownership of `DiagnosticOptions` by `CompilerInvocation` is guaranteed to be exclusive. This can be leveraged for a copy-on-write optimization later on. This PR changes usages of `DiagnosticOptions` across `clang`, `clang-tools-extra` and `lldb` to not be intrusively reference-counted.
2025-05-10[clang] Remove redundant calls to std::unique_ptr<T>::get (NFC) (#139399)Kazu Hirata1-2/+1
2025-05-01[Clang][SYCL] Add initial set of Intel OffloadArch values (#138158)Justin Cai2-0/+37
Following #137070, this PR adds an initial set of Intel `OffloadArch` values with corresponding predicates that will be used in SYCL offloading. More Intel architectures will be added in a future PR.
2025-04-30[clang] Shard out some small gtest binaries (#138021)Reid Kleckner1-1/+3
@nico mentioned that FormatTests and BasicTests are small binaries with few dependencies, so keeping them separate is nice. I broke them out as distinct test binaries, and they are still pretty small: $ find tools/clang/unittests/ -type f -name '*Tests' | xargs du -cksh | sort -nr 708M total 276M tools/clang/unittests/AllClangUnitTests 244M tools/clang/unittests/Interpreter/ClangReplInterpreterTests 167M tools/clang/unittests/Interpreter/ExceptionTests/ClangReplInterpreterExceptionTests 13M tools/clang/unittests/Format/FormatTests 6.9M tools/clang/unittests/Basic/BasicTests 1.1M tools/clang/unittests/libclang/CrashTests/libclangCrashTests I also broke out libclangCrashTests and re-enabled the failing test to resolve llvm#137855.
2025-04-28[clang] Hide the `TargetOptions` pointer from `CompilerInvocation` (#106271)Jan Svoboda1-1/+1
This PR hides the reference-counted pointer that holds `TargetOptions` from the public API of `CompilerInvocation`. This gives `CompilerInvocation` an exclusive control over the lifetime of this member, which will eventually be leveraged to implement a copy-on-write behavior. There are two clients that currently share ownership of that pointer: * `TargetInfo` - This was refactored to hold a non-owning reference to `TargetOptions`. The options object is typically owned by the `CompilerInvocation` or by the new `CompilerInstance::AuxTargetOpts` for the auxiliary target. This needed a bit of care in `ASTUnit::Parse()` to keep the `CompilerInvocation` alive. * `clangd::PreambleData` - This was refactored to exclusively own the `TargetOptions` that get moved out of the `CompilerInvocation`.
2025-04-04[clang] Do not share ownership of `PreprocessorOptions` (#133467)Jan Svoboda1-20/+15
This PR makes it so that `CompilerInvocation` is the sole owner of the `PreprocessorOptions` instance.
2025-04-02Reapply "[cmake] Refactor clang unittest cmake" (#134195)Reid Kleckner1-13/+5
This reapplies 5ffd9bdb50b57 (#133545) with fixes. The BUILD_SHARED_LIBS=ON build was fixed by adding missing LLVM dependencies to the InterpTests binary in unittests/AST/ByteCode/CMakeLists.txt .
2025-04-01Revert "[cmake] Refactor clang unittest cmake" (#134022)dpalermo1-5/+13
Reverts llvm/llvm-project#133545 This change is breaking several buildbots as well as developer's builds. Reverting to allow people to make progress.
2025-04-01[cmake] Refactor clang unittest cmake (#133545)Reid Kleckner1-13/+5
Pass all the dependencies into add_clang_unittest. This is consistent with how it is done for LLDB. I borrowed the same named argument list structure from add_lldb_unittest. This is a necessary step towards consolidating unit tests into fewer binaries, but seems like a good refactoring in its own right.
2025-03-25[clang][lex] Store non-owning options ref in `HeaderSearch` (#132780)Jan Svoboda1-10/+10
This makes it so that `CompilerInvocation` can be the only entity that manages ownership of `HeaderSearchOptions`, making it possible to implement copy-on-write semantics.
2025-02-06[clang] Parse warning-suppression-mapping after setting up diagengine (#125714)kadir çetinkaya1-0/+9
We can emit diagnostics while parsing warning-suppression-mapping, make sure command line flags take affect when emitting those.
2025-01-30[Clang] Remove ARCMigrate (#119269)Sirraide1-2/+2
In the discussion around #116792, @rjmccall mentioned that ARCMigrate has been obsoleted and that we could go ahead and remove it from Clang, so this patch does just that.
2024-12-06[clang][NFC] Change suppression mapping interfaces to use SourceLocation ↵kadir çetinkaya1-15/+25
(#118960) This way we can delay getting a presumed location even further, only performing it for diagnostics that are mapped.
2024-11-13Reapply "[clang] Introduce diagnostics suppression mappings (#112517)"Kadir Cetinkaya1-0/+169
This reverts commit 5f140ba54794fe6ca379362b133eb27780e363d7.
2024-11-12Revert "[clang] Introduce diagnostics suppression mappings (#112517)"Kadir Cetinkaya1-169/+0
This reverts commit 12e3ed8de8c6063b15916b3faf67c8c9cd17df1f. This reverts commit 41e3919ded78d8870f7c95e9181c7f7e29aa3cc4. There are some buildbot breakages in https://lab.llvm.org/buildbot/#/builders/18/builds/6832.
2024-11-12[clang] Introduce diagnostics suppression mappings (#112517)kadir çetinkaya1-0/+169
This implements https://discourse.llvm.org/t/rfc-add-support-for-controlling-diagnostics-severities-at-file-level-granularity-through-command-line/81292. Users now can suppress warnings for certain headers by providing a mapping with globs, a sample file looks like: ``` [unused] src:* src:*clang/*=emit ``` This will suppress warnings from `-Wunused` group in all files that aren't under `clang/` directory. This mapping file can be passed to clang via `--warning-suppression-mappings=foo.txt`. At a high level, mapping file is stored in DiagnosticOptions and then processed with rest of the warning flags when creating a DiagnosticsEngine. This is a functor that uses SpecialCaseLists underneath to match against globs coming from the mappings file. This implies processing warning options now performs IO, relevant interfaces are updated to take in a VFS, falling back to RealFileSystem when one is not available.
2024-10-18[NFC] add DiagnosticsTestHelper decl (#112820)Jinsong Ji1-0/+5
This is one of the many PRs to fix errors with LLVM_ENABLE_WERROR=on. Built by GCC 11. Fix warning llvm-project/clang/unittests/Basic/DiagnosticTest.cpp:19:6: error: ‘void clang::DiagnosticsTestHelper(clang::DiagnosticsEngine&)’ has not been declared within ‘clang’ [-Werror] 19 | void clang::DiagnosticsTestHelper(DiagnosticsEngine &diag) { | ^~~~~ In file included from llvm-project/clang/unittests/Basic/DiagnosticTest.cpp:9: llvm-project/clang/include/clang/Basic/Diagnostic.h:567:15: note: only here as a ‘friend’ 567 | friend void DiagnosticsTestHelper(DiagnosticsEngine &);
2024-09-25[clang] Fix FileManagerTestJan Svoboda1-2/+2
Compilation failure caused by b1aea98cfa357e23f4bb52232da5f41781f23bff.
2024-09-25[clang] Make deprecations of some `FileManager` APIs formal (#110014)Jan Svoboda2-38/+41
Some `FileManager` APIs still return `{File,Directory}Entry` instead of the preferred `{File,Directory}EntryRef`. These are documented to be deprecated, but don't have the attribute that warns on their usage. This PR marks them as such with `LLVM_DEPRECATED()` and replaces their usage with the recommended counterparts. NFCI.
2024-09-19[clang] Don't call raw_string_ostream::flush() (NFC)Youngsuk Kim1-1/+0
Don't call raw_string_ostream::flush(), which is essentially a no-op. As specified in the docs, raw_string_ostream is always unbuffered
2024-09-18Fix OOM in FormatDiagnostic (2nd attempt) (#108866)Vakhurin Sergei1-4/+15
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
2024-09-16Revert "Fix OOM in FormatDiagnostic" (#108838)Aaron Ballman1-15/+4
Reverting due to build failures found in #108187
2024-09-16Fix OOM in FormatDiagnostic (#108187)Vakhurin Sergei1-4/+15
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
2024-08-30[clang] Cleanup IncludeLocMap (#106241)kadir çetinkaya1-0/+60
CompilerInstance can re-use same SourceManager across multiple frontendactions. During this process it calls `SourceManager::clearIDTables` to reset any caches based on FileIDs. It didn't reset IncludeLocMap, resulting in wrong include locations for workflows that triggered multiple frontend-actions through same CompilerInstance.
2024-03-07[clang] Upstream visionOS Availability & DarwinSDKInfo APIs (#84279)Cyndy Ishida1-0/+10
Admittedly a bit awkward, `visionos` is the correct and accepted spelling for annotating availability for xrOS target triples. This patch detects errors and handles cases when `xros` is mistakenly passed. In addition, add APIs for introduced/deprecated/obsoleted versioning in DarwinSDKInfo mappings.
2024-02-11[clang][NFC] Annotate `SourceManagerTest.cpp` with `preferred_type`Vlad Serebrennikov1-0/+1
This helps debuggers to display values in bit-fields in a more helpful way.
2024-01-24[clang] NFC: Remove `{File,Directory}Entry::getName()` (#74910)Jan Svoboda1-6/+0
The files and directories that Clang accesses are uniqued by their inode. For each inode `FileManager` will create exactly one `FileEntry` or `DirectoryEntry` object, which makes answering the question _"Are these two files/directories the same?"_ a simple pointer equality check. However, since the same inode can be accessed through multiple different paths, asking the `FileEntry` or `DirectoryEntry` object _"What is your name?"_ doesn't have clear semantics. In c0ff9908 we started reporting the most recent name used to access the entry, which turned out to be necessary for Clang modules. However, the long-term solution has always been to explicitly track the as-requested name. This has been implemented in 4dc5573a as `FileEntryRef` and `DirectoryEntryRef`. The `DirectoryEntry::getName()` interface has been deprecated since the Clang 17 release and `FileEntry::getName()` since Clang 18. We have replaced uses of these deprecated APIs in `main` with `DirectoryEntryRef::getName()` and `FileEntryRef::getName()` respectively. This makes it possible to remove `{File,Directory}Entry::getName()` for good along with the `FileManager` code that implements them.
2023-12-08[clang] NFC: Remove `OptionalFileEntryRefDegradesToFileEntryPtr` (#74899)Jan Svoboda1-25/+0
2023-12-06[clang] NFC: Deprecate `FileEntry::getName()` (#68157)Jan Svoboda1-0/+4
All uses of `FileEntry::getName()` were removed in favor of `FileEntryRef::getName()`. This patch finally formally deprecates that function. The plan is to remove it entirely in the main branch after we cut the release branch for LLVM 18.
2023-10-06[clang] Fix tests build after 537344fcJan Svoboda1-0/+1
2023-10-06[clang][modules] Remove preloaded SLocEntries from PCM files (#66962)Jan Svoboda1-0/+53
This commit removes the list of SLocEntry offsets to preload eagerly from PCM files. Commit introducing this functionality (258ae54a) doesn't clarify why this would be more performant than the lazy approach used regularly. Currently, the only SLocEntry the reader is supposed to preload is the predefines buffer, but in my experience, it's not actually referenced in most modules, so the time spent deserializing its SLocEntry is wasted. This is especially noticeable in the dependency scanner, where this change brings 4.56% speedup on my benchmark.
2023-10-05[Lex] Introduce Preprocessor::LexTokensUntilEOF()Jonas Hahnfeld1-28/+4
This new method repeatedly calls Lex() until end of file is reached and optionally fills a std::vector of Tokens. Use it in Clang's unit tests to avoid quite some code duplication. Differential Revision: https://reviews.llvm.org/D158413
2023-09-29[clang] NFCI: Use `FileEntryRef` in `SourceManager::overrideFileContents()`Jan Svoboda2-18/+18
2023-09-29[clang] NFCI: Use `FileEntryRef` in `SourceManager::FileInfos` (#67742)Jan Svoboda1-0/+40
2023-09-20[clang] NFCI: Use `FileEntryRef` in `FileManagerTest`Jan Svoboda1-2/+2
2023-07-20Sarif: stabilize artifacts orderFangrui Song1-1/+1
StringMap iteration order is not guaranteed to be deterministic (https://llvm.org/docs/ProgrammersManual.html#llvm-adt-stringmap-h).
2023-05-25[clang] Make `FileEntryRef::getDir()` return the as-requested ↵Jan Svoboda2-1/+25
`DirectoryEntryRef` For redirected file entries, `FileEntryRef::getDir()` returns the parent directory entry of the target file entry. This differs from `FileEntry::getDir()` that always returns the parent directory that was last used to look up that file. After switching from `FileEntry` to `FileEntryRef` for umbrella headers in D142113, this discrepancy became observable and caused Clang to emit incorrect diagnostics. This patch changes Clang so that it always associates `FileEntryRef` with the parent directory that was used to look it up. This brings its behavior closer to `FileEntry`, but without the hacky mutation. This also ensures that `llvm::sys::path::parent_path(FileRef->getNameAsRequested()) == FileRef->getDir()->getName()`. Previously, `FileRef->getDir()` would fall underneath the redirecting VFS into the world of on-disk paths. Reviewed By: benlangmuir, rmaz Differential Revision: https://reviews.llvm.org/D151398
2023-04-17[CMake] Cleanup depsNAKAMURA Takumi1-1/+0
2023-03-03[clang/Diagnostic] Use `optional` to disambiguate between a ↵Argyrios Kyrtzidis1-0/+23
`StoredDiagMessage` that is not set vs set as empty string "But when would you have a completely empty diagnostic message", you ask dear reader? That is when there is an empty "#warning" in code. rdar://106155415 Differential Revision: https://reviews.llvm.org/D145256
2023-02-19Recommit "[Support] change StringMap hash function from djbHash to xxHash"Erik Desjardins1-1/+1
This reverts commit 37eb9d13f891f7656f811516e765b929b169afe0. Test failures have been fixed: - ubsan failure fixed by 72eac42f21c0f45a27f3eaaff9364cbb5189b9e4 - warn-unsafe-buffer-usage-fixits-local-var-span.cpp fixed by 03cc52dfd1dbb4a59b479da55e87838fb93d2067 (wasn't related) - test-output-format.ll failure was spurious, build failed at https://lab.llvm.org/buildbot/#/builders/54/builds/3545 (b4431b2d945b6fc19b1a55ac6ce969a8e06e1e93) but passed at https://lab.llvm.org/buildbot/#/builders/54/builds/3546 (5ae99be0377248c74346096dc475af254a3fc799) which is before my revert https://github.com/llvm/llvm-project/compare/b4431b2d945b6fc19b1a55ac6ce969a8e06e1e93...5ae99be0377248c74346096dc475af254a3fc799 Original commit message: Depends on https://reviews.llvm.org/D142861. Alternative to https://reviews.llvm.org/D137601. xxHash is much faster than djbHash. This makes a simple Rust test case with a large constant string 10% faster to compile. Previous attempts at changing this hash function (e.g. https://reviews.llvm.org/D97396) had to be reverted due to breaking tests that depended on iteration order. No additional tests fail with this patch compared to `main` when running `check-all` with `-DLLVM_ENABLE_PROJECTS="all"` (on a Linux host), so I hope I found everything that needs to be changed. Differential Revision: https://reviews.llvm.org/D142862
2023-02-08Revert "[Support] change StringMap hash function from djbHash to xxHash"Erik Desjardins1-1/+1
This reverts commit d768b97424f9e1a0aae45440a18b99f21c4027ce. Causes sanitizer failure: https://lab.llvm.org/buildbot/#/builders/238/builds/1114 ``` /b/sanitizer-aarch64-linux-bootstrap-ubsan/build/llvm-project/llvm/lib/Support/xxhash.cpp:107:12: runtime error: applying non-zero offset 8 to null pointer #0 0xaaaab28ec6c8 in llvm::xxHash64(llvm::StringRef) /b/sanitizer-aarch64-linux-bootstrap-ubsan/build/llvm-project/llvm/lib/Support/xxhash.cpp:107:12 #1 0xaaaab28cbd38 in llvm::StringMapImpl::LookupBucketFor(llvm::StringRef) /b/sanitizer-aarch64-linux-bootstrap-ubsan/build/llvm-project/llvm/lib/Support/StringMap.cpp:87:28 ``` Probably causes test failure in `warn-unsafe-buffer-usage-fixits-local-var-span.cpp`: https://lab.llvm.org/buildbot/#/builders/60/builds/10619 Probably causes reverse-iteration test failure in `test-output-format.ll`: https://lab.llvm.org/buildbot/#/builders/54/builds/3545
2023-02-07[Support] change StringMap hash function from djbHash to xxHashErik Desjardins1-1/+1
Depends on https://reviews.llvm.org/D142861. Alternative to https://reviews.llvm.org/D137601. xxHash is much faster than djbHash. This makes a simple Rust test case with a large constant string 10% faster to compile. Previous attempts at changing this hash function (e.g. https://reviews.llvm.org/D97396) had to be reverted due to breaking tests that depended on iteration order. No additional tests fail with this patch compared to `main` when running `check-all` with `-DLLVM_ENABLE_PROJECTS="all"` (on a Linux host), so I hope I found everything that needs to be changed. Differential Revision: https://reviews.llvm.org/D142862
2023-01-14[clang] Use std::optional instead of llvm::Optional (NFC)Kazu Hirata2-3/+3
This patch replaces (llvm::|)Optional< with std::optional<. I'll post a separate patch to remove #include "llvm/ADT/Optional.h". This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2023-01-14[clang] Add #include <optional> (NFC)Kazu Hirata2-0/+2
This patch adds #include <optional> to those files containing llvm::Optional<...> or Optional<...>. I'll post a separate patch to actually replace llvm::Optional with std::optional. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-12-20[Clang] Prepare for llvm::Optional becoming std::optional.Benjamin Kramer1-3/+2
The needed tweaks are mostly trivial, the one nasty bit is Clang's usage of OptionalStorage. To keep this working old Optional stays around as clang::CustomizableOptional, with the default Storage removed. Optional<File/DirectoryEntryRef> is replaced with a typedef. I tested this with GCC 7.5, the oldest supported GCC I had around. Differential Revision: https://reviews.llvm.org/D140332
2022-12-18Revert "[clang] Convert OptionalFileEntryRefDegradesToFileEntryPtr to ↵Krzysztof Parzyszek1-2/+1
std::optional" This reverts commit 8f0df9f3bbc6d7f3d5cbfd955c5ee4404c53a75d. The Optional*RefDegradesTo*EntryPtr types want to keep the same size as the underlying type, which std::optional doesn't guarantee. For use with llvm::Optional, they define their own storage class, and there is no way to do that in std::optional. On top of that, that commit broke builds with older GCCs, where std::optional was not trivially copyable (static_assert in the clang sources was failing).
2022-12-17[clang] Convert OptionalFileEntryRefDegradesToFileEntryPtr to std::optionalKrzysztof Parzyszek1-1/+2
2022-12-17clang/unittests/Basic/SarifTest.cpp: std::optional::value => operator*Fangrui Song1-5/+5