aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Sema/Sema.cpp
AgeCommit message (Collapse)AuthorFilesLines
2025-07-03[AArch64] Add option -msve-streaming-vector-bits= . (#144611)Eli Friedman1-0/+18
This is similar to -msve-vector-bits, but for streaming mode: it constrains the legal values of "vscale", allowing optimizations based on that constraint. This also fixes conversions between SVE vectors and fixed-width vectors in streaming functions with -msve-vector-bits and -msve-streaming-vector-bits. This rejects any use of arm_sve_vector_bits types in streaming functions; if it becomes relevant, we could add arm_sve_streaming_vector_bits types in the future. This doesn't touch the __ARM_FEATURE_SVE_BITS define.
2025-06-27[clang] Suppress noreturn warning if last statement in a function is a throw ↵Samarth Narang1-2/+3
(#145166) Fixes https://github.com/llvm/llvm-project/issues/144952
2025-06-13Remove delayed typo expressions (#143423)Aaron Ballman1-9/+0
This removes the delayed typo correction functionality from Clang (regular typo correction still remains) due to fragility of the solution. An RFC was posted here: https://discourse.llvm.org/t/rfc-removing-support-for-delayed-typo-correction/86631 and while that RFC was asking for folks to consider stepping up to be maintainers, and we did have a few new contributors show some interest, experiments show that it's likely worth it to remove this functionality entirely and focus efforts on improving regular typo correction. This removal fixes ~20 open issues (quite possibly more), improves compile time performance by roughly .3-.4% (https://llvm-compile-time-tracker.com/?config=Overview&stat=instructions%3Au&remote=AaronBallman&sortBy=date), and does not appear to regress diagnostic behavior in a way we wouldn't find acceptable. Fixes #142457 Fixes #139913 Fixes #138850 Fixes #137867 Fixes #137860 Fixes #107840 Fixes #93308 Fixes #69470 Fixes #59391 Fixes #58172 Fixes #46215 Fixes #45915 Fixes #45891 Fixes #44490 Fixes #36703 Fixes #32903 Fixes #23312 Fixes #69874
2025-06-06[clang] Strip away lambdas (NFC) (#143226)Kazu Hirata1-2/+1
We don't need lambdas here.
2025-06-03[clang] Correct FixIt ranges for unused capture warnings (#141148)Oliver Hunt1-0/+22
Fixes #106445 by using the lexer to find the correct range for the removal FixIts. Previously the ranges that were generated assuming no unsurprising formatting, which for the most part works. Being correct in all cases requires using the lexer to find the bounding tokens for the region to remove. As part of this it adds Sema::getRangeForNextToken to wrap Lexer::findNextToken.
2025-06-02[AArch64] Add missing Neon Types (#126945)Tomas Matheson1-2/+5
The AAPCS64 adds a number of vector types to the C unconditionally: https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#11appendix-support-for-advanced-simd-extensions The equivalent SVE types are already available in clang: https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#12appendix-support-for-scalable-vectors __mfp8 is defined in the ACLE https://arm-software.github.io/acle/main/acle.html#data-types --------- Co-authored-by: David Green <david.green@arm.com>
2025-05-31[clang][Sema] Optimize ~SemaDiagnosticBuilder (#142252)Timm Baeder1-4/+7
Call getDiagnosticLevel(), which is expensive, only if ShowCallStack is set. Small gains: https://llvm-compile-time-tracker.com/compare.php?from=843e362318e884991e517a54446b4faeacdad789&to=5cef0c18466318a426924b3c45f7abaaa8f6b535&stat=instructions:u
2025-05-28[AArch64] Rename AArch64SVEACLETypes.def and add base SVE_TYPE.David Green1-1/+1
2025-05-02[C] Update the -Wdefault-const-init-unsafe wording (#138266)Aaron Ballman1-1/+6
This drops the "and is incompatible with C++" phrasing from the diagnostic unless -Wc++-compat is explicitly passed. This makes the diagnostic less confusing when it is on by default rather than enabled because of C++ compatibility concerns
2025-05-02[clang][NFC] Convert `Sema::NonTrivialCUnionContext` to scoped enumVlad Serebrennikov1-2/+2
2025-05-01[C] Modify -Wdefault-const-init (#137961)Aaron Ballman1-1/+1
Post-commit review feedback on https://github.com/llvm/llvm-project/pull/137166 raised a concern from the Linux kernel about wanting to silence the new diagnostic when the uninitialized object is a const member of a structure. These members can be initialized later if the containing object is non-const, such as through a call to memset, for example. This splits the diagnostic groups into: ``` -Wc++-compat -Wdefault-const-init -Wdefault-const-init-field -Wdefault-const-init-var -Wdefault-const-init-unsafe -Wdefault-const-init-field-unsafe -Wdefault-const-init-var-unsafe ``` --------- Co-authored-by: Mariya Podchishchaeva <mariya.podchishchaeva@intel.com>
2025-04-25[C] Warn on uninitialized const objects (#137166)Aaron Ballman1-0/+12
Unlike C++, C allows the definition of an uninitialized `const` object. If the object has static or thread storage duration, it is still zero-initialized, otherwise, the object is left uninitialized. In either case, the code is not compatible with C++. This adds a new diagnostic group, `-Wdefault-const-init-unsafe`, which is on by default and diagnoses any definition of a `const` object which remains uninitialized. It also adds another new diagnostic group, `-Wdefault-const-init` (which also enabled the `unsafe` variant) that diagnoses any definition of a `const` object (including ones which are zero-initialized). This diagnostic is off by default. Finally, it adds `-Wdefault-const-init` to `-Wc++-compat`. GCC diagnoses these situations under this flag. Fixes #19297
2025-04-23Control analysis-based diagnostics with #pragma (#136323)Aaron Ballman1-0/+37
Previously, analysis-based diagnostics (like -Wconsumed) had to be enabled at file scope in order to be run at the end of each function body. This meant that they did not respect #pragma clang diagnostic enabling or disabling the diagnostic. Now, these pragmas can control the diagnostic emission. Fixes #42199
2025-04-10[RFC] Initial implementation of P2719 (#113510)Oliver Hunt1-0/+1
This is a basic implementation of P2719: "Type-aware allocation and deallocation functions" described at http://wg21.link/P2719 The proposal includes some more details but the basic change in functionality is the addition of support for an additional implicit parameter in operators `new` and `delete` to act as a type tag. Tag is of type `std::type_identity<T>` where T is the concrete type being allocated. So for example, a custom type specific allocator for `int` say can be provided by the declaration of void *operator new(std::type_identity<int>, size_t, std::align_val_t); void operator delete(std::type_identity<int>, void*, size_t, std::align_val_t); However this becomes more powerful by specifying templated declarations, for example template <typename T> void *operator new(std::type_identity<T>, size_t, std::align_val_t); template <typename T> void operator delete(std::type_identity<T>, void*, size_t, std::align_val_t);); Where the operators being resolved will be the concrete type being operated over (NB. A completely unconstrained global definition as above is not recommended as it triggers many problems similar to a general override of the global operators). These type aware operators can be declared as either free functions or in class, and can be specified with or without the other implicit parameters, with overload resolution performed according to the existing standard parameter prioritisation, only with type parameterised operators having higher precedence than non-type aware operators. The only exception is destroying_delete which for reasons discussed in the paper we do not support type-aware variants by default.
2025-04-07[DirectX] Add target builtins (#134439)Farzon Lotfi1-0/+2
- fixes #132303 - Moves dot2add from a language builtin to a target builtin. - Sets the scaffolding for Sema checks for DX builtins - Setup DirectX backend as able to have target builtins - Adds a DX TargetBuiltins emitter in `clang/lib/CodeGen/TargetBuiltins/DirectX.cpp`
2025-04-03[clang] NFC: introduce UnsignedOrNone as a replacement for ↵Matheus Izvekov1-1/+1
std::optional<unsigned> (#134142) This introduces a new class 'UnsignedOrNone', which models a lite version of `std::optional<unsigned>`, but has the same size as 'unsigned'. This replaces most uses of `std::optional<unsigned>`, and similar schemes utilizing 'int' and '-1' as sentinel. Besides the smaller size advantage, this is simpler to serialize, as its internal representation is a single unsigned int as well.
2025-03-11[C++20] [Modules] Instantiate pending instantiations when GMF ends (#126842)Chuanqi Xu1-2/+6
Close https://github.com/llvm/llvm-project/issues/125999 The cause of the problem is, when we instantiate the pending instantiation, the owning module of the TU gets into 'foo' instead of the GMF. The concern of the patch is, I am not sure the point of 'pending' instantiations. I mean, if there is a reason we **must** pending the intantiations to the end of the TU.
2025-02-28[CUDA][HIP] check dtor in deferred diag (#129117)Yaxun (Sam) Liu1-0/+43
Currently the deferred diag fails to diagnose calling of host function in host device function in device compilation triggered by destructors. This can be further divided into two issuse: 1. the deferred diag visitor does not visit dtor of member and parent class when visiting dtor, which it should 2. the deferred diag visitor does not visit virtual dtor of explicit template class instantiation, which it should Due to these issues, some constexpr functions which call host functions are emitted on device side, which causes undefind symbols in linking stage, as revealed by https://github.com/llvm/llvm-project/issues/108548 By fixing these issue, clang will diag the issues early during compilation instead of linking.
2025-02-25[HLSL] Implement default constant buffer $Globals (2nd attempt) (#128589)Helena Kotas1-2/+1
All variable declarations in the global scope that are not resources, static or empty are implicitly added to implicit constant buffer `$Globals`. They are created in `hlsl_constant` address space and collected in an implicit `HLSLBufferDecl` node that is added to the AST at the end of the translation unit. Codegen is the same as for explicit constant buffers. Fixes #123801 This is a second attempt to implement this feature. The first attempt had to be reverted because of memory leaks. The problem was adding a `SmallVector` member on `HLSLBufferDecl` node to represent a list of default buffer declarations. When this vector needed to grow, it allocated memory that was never released, because all memory used by AST nodes must be allocated by `ASTContext` allocator and is released all at once. Destructors on AST nodes are never called. It this change the list of default buffer declarations is collected in a `SmallVector` instance on `SemaHLSL`. The `HLSLBufDecl` representing `$Globals` is created at the end of the translation unit when the number of declarations is known, and the list is copied into an array allocated by the `ASTContext` allocator.
2025-02-20Revert "[HLSL] Implement default constant buffer `$Globals`" (#128112)Helena Kotas1-1/+2
Reverts llvm/llvm-project#125807 Reverting this change because of failing tests.
2025-02-20[HLSL] Implement default constant buffer `$Globals` (#125807)Helena Kotas1-2/+1
All variable declarations in the global scope that are not resources, static or empty are implicitly added to implicit constant buffer `$Globals`. They are created in `hlsl_constant` address space and collected in an implicit `HLSLBufferDecl` node that is added to the AST at the end of the translation unit. Codegen is the same as for explicit constant buffers. Fixes #123801
2025-02-20[clang] print correct context for diagnostics suppressed by deduction (#125453)Matheus Izvekov1-2/+11
This patch makes it so the correct instantiation context is printed for diagnostics suppessed by template argument deduction. The context is saved along with the suppressed diagnostic, and when the declaration they were attached to becomes used, we print the correct context, instead of whatever context was at this point.
2025-02-14[HLSL] Implement HLSL Aggregate splatting (#118992)Sarah Spall1-0/+1
Implement HLSL Aggregate Splat casting that handles splatting for arrays and structs, and vectors if splatting from a vec1. Closes #100609 and Closes #100619 Depends on #118842
2025-01-31[NFC] remove string literals from AArch64SVEACLETypes.def (#125063)Tomas Matheson1-2/+2
Remove string literals from the macro calls.
2025-01-28[clang] Extend diagnose_if to accept more detailed warning information, take ↵Nikolas Klauser1-2/+3
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.
2025-01-06[SPIRV] Add Target Builtins using Distance ext as an example (#121598)Farzon Lotfi1-0/+2
- 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)
2024-12-03[HLSL] get inout/out ABI for array parameters working (#111047)Sarah Spall1-0/+9
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>
2024-11-16[Sema] Remove unused includes (NFC) (#116461)Kazu Hirata1-3/+0
Identified with misc-include-cleaner.
2024-10-24[clang] Use {} instead of std::nullopt to initialize empty ArrayRef (#109399)Jay Foad1-3/+3
Follow up to #109133.
2024-10-18[clang] Deduplicate the logic that only warns once when stack is almost full ↵Boaz Brickner1-10/+2
(#112552) Zero diff in behavior.
2024-10-11[Clang] [Sema] Don't crash on unexpanded pack in invalid block literal (#110762)Sirraide1-4/+5
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.
2024-10-10[clang][frontend] Support applying the annotate attribute to statements ↵Eric Astor1-0/+28
(#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.
2024-10-03[Clang] nonblocking/nonallocating attributes: 2nd pass caller/callee ↵Doug Wyatt1-154/+4
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>
2024-10-01[AMDGPU] Specify width and align for all AMDGPU builtin types. NFC. (#109656)Jay Foad1-1/+1
This will be used in ASTContext::getTypeInfo which needs this information for all builtin types, not just pointers.
2024-09-26Revert "[clang] Extend diagnose_if to accept more detailed warning ↵Kadir Cetinkaya1-3/+2
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.
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-13/+6
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-17[NFC] Move warning from CodeGen to Sema. (#107397)Zahira Ammarguellat1-0/+1
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.
2024-09-16Revert "Fix OOM in FormatDiagnostic" (#108838)Aaron Ballman1-6/+13
Reverting due to build failures found in #108187
2024-09-16Fix OOM in FormatDiagnostic (#108187)Vakhurin Sergei1-13/+6
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-09-14Reapply "Reapply "[clang] Extend diagnose_if to accept more detailed warning ↵Nikolas Klauser1-2/+3
information (#70976)" (#108453)" This reverts commit e1bd9740faa62c11cc785a7b70ec1ad17e286bd1. Fixes incorrect use of the `DiagnosticsEngine` in the clangd tests.
2024-09-13Revert "Reapply "[clang] Extend diagnose_if to accept more detailed warning ↵Florian Mayer1-3/+2
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
2024-09-13Reapply "[clang] Extend diagnose_if to accept more detailed warning ↵Nikolas Klauser1-2/+3
information (#70976)" (#108453) This reverts commit e0cd11eba526234ca14a0b91f5598ca3363b6aca. Update the use of `getWarningOptionForDiag` in flang to use the DiagnosticIDs.
2024-09-12Revert "[clang] Extend diagnose_if to accept more detailed warning ↵Kazu Hirata1-3/+2
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
2024-09-12[clang] Extend diagnose_if to accept more detailed warning information (#70976)Nikolas Klauser1-2/+3
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.
2024-09-08Fix GCC Wimplicit-fallthrough warnings. NFC.Simon Pilgrim1-0/+3
2024-08-17[clang][NFC] Clean up `Sema` headersVlad Serebrennikov1-0/+1
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.
2024-08-09[C++20] [Modules] Emit Errors when compiling a non-module source as module ↵Chuanqi Xu1-0/+12
(#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.
2024-08-02Reland "[Modules] Fix using `va_list` with modules and a precompiled header. ↵Volodymyr Sapsai1-0/+7
(#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
2024-08-02Revert "[Modules] Fix using `va_list` with modules and a precompiled ↵dyung1-7/+0
header." (#101752) Reverts llvm/llvm-project#100837 The test Modules/builtin-vararg.c is failing on AArch64 build bots: - https://lab.llvm.org/buildbot/#/builders/190/builds/3117 - https://lab.llvm.org/buildbot/#/builders/65/builds/2302 - https://lab.llvm.org/buildbot/#/builders/154/builds/2288 Revert to get the bots back to green.
generated by cgit v1.1 at 2025-07-23 13:45:11 +0000