Remove modulelist cas module cache#12568
Open
jasonmolenda wants to merge 3233 commits intoswiftlang:nextfrom
Open
Remove modulelist cas module cache#12568jasonmolenda wants to merge 3233 commits intoswiftlang:nextfrom
jasonmolenda wants to merge 3233 commits intoswiftlang:nextfrom
Conversation
…1406) I introduced a dependency from Host on Core without realizing it in an earlier PR, while adding a setting to disable the new shared cache binary blob scanning/reading in HostInfoMacOSX, which caused build problems. Thanks to Alex for figuring out the build failure I caused. Add a bool to the methods in HostInfoMacOSX, and have the callers (in Core and various plugins etc) all fetch the symbols.shared-cache-binary-loading setting from ModuleList, and pass the result in. The least obvious part of this is in ProcessGDBRemote where we first learn the shared cache filepath & uuid, it calls HostInfoMacOSX::SharedCacheIndexFiles() - this is only called when the shared cache binary loading is enabled, so I conditionalize the call to this method based on the setting. rdar://148939795 (cherry picked from commit d406ce8)
🍒 [utils] modernize llvm-lit verbosity options
[lldb/Breakpoint] Fix condition hash after updating condition text
…lvm#180817) Clang can't handle objc lifetime correctly when casting We reuse the approach similar to lifetime: First remove it before the conversion, then add it back. Add a test Fixes llvm#177478
…use-Core-classes-from-Host [lldb][macOS] Don't fetch settings in Host, to keep layering (llvm#181406)
Cherry pick [lldb/Breakpoint] Fix condition hash after updating condition text and fix TestSwiftConditionalBreakpoint.py
…y-array [lldb] Fix empty array formatting in embedded Swift
Also add optimized implementations for `OnDiskCAS` that can take advantage of file cloning. (cherry picked from commit 382697a)
…ft-release-6.3-Support-Support-5-component-VersionTuples-181275 [Cherry-pick into swift/release/6.3] [Support] Support 5-component VersionTuples (llvm#181275)
When I changed lldb so that the StopInfo's compute their own stop reason data (before it was oddly done in SBThread::GetStopReasonData...) I didn't notice that StopInfoMachException was relying on that routine's default of returning the Value as the 0th exception data, and didn't actually return its own data. This fixes that, and makes us report the exception type, and the code and subcode if the exception has them. I also added a test for this. rdar://169755672 (cherry picked from commit 85d94e1)
The shared cache index only had accessors for getting a file from a shared cache by filename. In some environments like iOS Simulator, a filename can be either the actual realpath name of the framework in an SDK or simulator runtime install location, or rooted on / like /System/LibraryFrameworks/SwiftUI.framework. Because the searches for binaries were by filename, this divergence would be a problem. However, searching for binaries by the binary's UUID can remove that ambiguity. I changed HostInfoMacOSX's store of SharedCacheImageInfo's to have a std::vector of all of the SharedCacheImageInfo's in a shared cache. Then I create a mapping of filename-to-SharedCacheImageInfo* and a mapping of UUID-to-SharedCacheImageInfo*, both pointing into the now-frozen std::vector. I added a HostInfo::GetSharedCacheImageInfo method to fetch an entry by shared-cache UUID + file UUID, in addition to the previous shared-cache UUID + filename. Have HostInfoMacOSX store the filenames it gets from the libdyld SPI in ConstStrings to make it clear that they have infinite lifetime in the process, and we don't need to do anything further. rdar://148939795 --------- Co-authored-by: Jonas Devlieghere <[email protected]> (cherry picked from commit e496e3c)
Implement DenseMapInfo for UUID so that we can use UUIDs as keys in DenseMap and DenseSet. (cherry picked from commit 90d49d3)
…197-6.3 [6.3][gmodule][CAS] Don't generate bogus DW_AT_LLVM_include_path
…script. (swiftlang#11498) (cherry picked from commit bf9af9f)
…ost-processing. NFC intended. (swiftlang#11830) (cherry picked from commit 9c984ff)
…r VFS overlays. (swiftlang#11843) This makes additional VFS overlays usable instead of failing with "file not found" errors. It is achieved by making file references in these extra overlays go through the reproducer VFS overlay as VFS overlays are applied from right to left. I.e., the leftomost CLI argument describes the outermost virtual file system. (cherry picked from commit cff86e5)
…dencies. (llvm#160226) When we add the module map describing the compiled module to the command line, add it to the file dependencies as well. Discovered while working on reproducers where a command line input was missing in the captured files as it wasn't considered a dependency. (cherry picked from commit b39a9db)
…he directory. (swiftlang#11853) The intention is to keep reproducers relocatable. Without redirection we are trying to write output to "/some/path/existing/only/where/reproducer/generated.o" and failing to do so. Instead we redirect the output to the reproducer cache directory which is a relative path that is guaranteed to exist. .pcm files are the output too but we don't redirect them because they should be written and read from a specific place which is controlled by `LookupOutput` callback. (cherry picked from commit 87d0b80)
…ducer cache directory. (swiftlang#11945) It allows to achieve the same behavior in a reproducer as in an original compilation regarding .d dependencies. And it will be required to support CAS-based builds. (cherry picked from commit b1b3016)
…s for explicitly-built modules. (swiftlang#11960) Add API to provide CAS options for reproducer generation and use these options to generate compilation commands. Instead of copying relevant files and providing them through VFS, create a new CAS object storage and copy relevant CAS trees there. rdar://158780270 (cherry picked from commit 8d4bda4)
…e-multiple-shared-caches-correctly-and-file-search-by-uuid R148939795 handle multiple shared caches correctly and file search by UUID
…/lldb/cross-platform-makefile-to-swift-release-6.3 🍒 [lldb] add cross platform test commands in Makefile.rules
…h64 linux
This fails with the error:
```
File "/home/build-user/llvm-project/lldb/test/API/lang/swift/yielding_accessors/TestSwiftYieldingAccessors.py", line 65, in test_step_over_starting_inside_coroutine
self.hit_correct_line(thread, "coroutine call site")
File "/home/build-user/llvm-project/lldb/test/API/lang/swift/yielding_accessors/TestSwiftYieldingAccessors.py", line 31, in hit_correct_line
self.assertTrue(
AssertionError: False is not true : Stepped to line 11 instead of expected 18 with pattern 'coroutine call site'
Backtrace =
frame #0: 0x0000aaaac1b76d04 a.out`S.COMPUTED_PROPERTY.yielding_mutate() at main.swift:11:7
frame swiftlang#1: 0x0000ffffbba884c4 libc.so.6`___lldb_unnamed_symbol_28450 + 116.
```
…#178952) (swiftlang#12354) [Thread Analysis] Fix a bug in context update in alias-analysis Previously, in 'updateLocalVarMapCtx', context was updated to the one immediately after the provided statement 'S'. It is incorrect, because 'S' hasn't been processed at that point. This issue could result in false positives. For example, ``` void f(Lock_t* F) { Lock_t* L = F; // 'L' aliases with 'F' L->Lock(); // 'L' holds the lock // Before the fix, the analyzer saw the definition of 'L' being cleared before 'L' was unlocked. unlock(&L); // unlock (*L) } ``` This commit fixes the issue. rdar://169236809 (cherry picked from commit 37aaff3)
…DK name -isysroot can be an unrecognized value in unusual circumstances. Don't emit an error when checking the triple against such an isysroot, let the user try to do what they're trying to do. rdar://170498582
…vm#156474) In llvm#150213 we made use of the Event Viewer on Windows (equivalent of system logging on Darwin) rather than piping to the standard output. This turned out to be too verbose in practice, as the Event Viewer is developer oriented and not user oriented. This patch swaps the use of `ReportEventW` for `OutputDebugStringA`, allowing to use tools such as `DebugView` to record logs when we are interested in receiving them, rather than continuously writing to the buffer. Please see an example below: <img width="1253" height="215" alt="Screenshot 2025-09-02 at 16 07 03" src="https://github.com/user-attachments/assets/4a326e46-d8a4-4c99-8c96-1bee62da8d55" /> (cherry picked from commit 5070385)
[LLDB] Test that String summary prover hides children
…oviders (llvm#184926) This is driven by the Swift language. In Swift many data types such as Int, and String are structs, and LLDB provides summary formatters and synthetic child providers for them. For String, for example, a summary formatter pulls out the string data from the implementation, while a synthetic child provider hides the implementation details from users, so strings don't expand their children. rdar://171646109 (cherry picked from commit 70509b5)
(cherry picked from commit 3fc27dc)
…rt-in-extern-c [stable/21.x][clang][modules] -Wmodule-import-in-extern-c should not be an error by default
We would previously include the FP80 sources into the Windows build if we built with the GNU driver rather than the `cl` driver. (cherry picked from commit 57f1ec6)
…ildren rdar://171646109
Depending on the `Builtin.Borrow` target type's representation, have LLDB show the value as having either a single `targetValue` child, which presents a borrowed value stored inline, or a single `targetPointer` child, which presents the address of the borrowed value stored elsewhere. This should provide enough baseline functionality for standard-library-level data formatters for the user-facing `Swift.Borrow` type to present the target value.
…s/fix-verbose-health-logs-windows-to-stable-21-x 🍒 [windows][lldb] implement system logging on Windows
[LLDB] Add a synthetic child provider for Swift.String to hide its children
[lldb][swift] Implement loading main module from CAS
When building with the GNU driver, we would pass in `/DELAYLOAD:...` without indicating that this is a linker flag. `clang` does not implictly forward non-consumed options to the linker like `cl` does, and this would cause the build to fail. (cherry picked from commit f34adfe)
…module with config macros (llvm#177078) (swiftlang#12511) When a PCH is compiled with macro definitions on the command line, such as `-DCONFIG1`, an unexpected warning can occur if the macro definitions happen to belong to an imported module's config macros. The warning may look like the following: ``` definition of configuration macro 'CONFIG1' has no effect on the import of 'Mod1'; pass '-DCONFIG1=...' on the command line to configure the module ``` while `-DCONFIG1` is clearly on the command line when `clang` compiles the source that uses the PCH and the module. The reason this can happen is a combination of two things: 1. The logic that checks for config macros is not aware of any command line macros passed through the PCH ([here](https://github.com/llvm/llvm-project/blob/7976ac990000a58a7474269a3ca95e16aed8c35b/clang/lib/Frontend/CompilerInstance.cpp#L1562)). 2. `clang` _replaces_ the predefined macros on the command line with the predefined macros from the PCH, which does not include any builtins ([here](https://github.com/llvm/llvm-project/blob/7976ac990000a58a7474269a3ca95e16aed8c35b/clang/lib/Frontend/CompilerInstance.cpp#L679)). This PR teaches the preprocessor to recognize the command line macro definitions passed transitively through the PCH, so that the error check does not miss these definitions by mistake. The config macro itself works fine, and it is only the error check that needs fixing. rdar://95261458 (cherry picked from commit 668d09b)
builtins: adjust FP80 source management (llvm#183871)
When building with the clang-cl driver, we build PCHs differently, building the headers themselves (/Yc) and then consuming them (/Yu). This exposed a case where we did not feed the content to the depscan phase. The processing of the header would result in a failure to find the current workding directory as that is removed during the caching mode. This allows us to build CoreFoundation's PCH with caching, allowing us to use clang-cl driver with clang-cache and enable the CAS for building the toolchain. Fixes: swiftlang#12512 Co-authored-by: Hiroshi Yamauchi <[email protected]>
…onst 🍒 [LLDB][NativePDB] Add local constant support (llvm#180612)
Lex,Driver: perform depscanning for PCH builds
…is (llvm#178952) (swiftlang#12354)" (swiftlang#12495) This reverts commit aa00047. The reverted fix surfaced conservative behaviors of Wthread-safety which could break our downstream usage. rdar://171657667
…set-kext-loaded-bp-in-corefiles [lldb][Darwin] Don't try to insert breakpoint on corefiles (llvm#184749)
Optimized code may generate an uncoditional branch to the same BB.
…tObject (swiftlang#12546) When an expression uses the new Swift `po` function (`stringForPrintObject(_:mangledTypeName:)`), it does not need to capture `self`. The two arguments are a pointer, and a mangled name (string). After making the initial change to prevent the capture of `self`, through testing and AI review, other steps of the expression setup can and should also be skipped for the context-free `po`. The skippable expression setup steps are: 1. Capturing `self` 2. `RegisterAllVariables` 3. Handling of special variables (`$` prefixed persistent variables) 4. `AddExternalVariables` 5. `AddRequiredAliases` 6. `AddArchetypeTypeAliases` 7. `RegisterTypeAliases` 8. `CanEvaluateExpressionWithoutBindingGenericParams` Avoiding the above work side steps any would be issues with the swift AST context. rdar://169415680
…initeloop_corosplit [CoroSplit] Fix infinite loop in CoroSplit
build: add `LINKER:` modifier to `/DELAYLOAD:` options (llvm#185086)
It seems there may be a formatter bug when there's a time zone difference between the target machine being debugged, and the host the debugger is running on. (cherry picked from commit a585f45)
Remove the CAS id -> ModuleSpec cache, re-fetching an llvm::MemoryBuffer for a CAS id is not an expensive operation. Patch by Steve Wu, separated out from a PR with other changes.
jasonmolenda
requested review from
JDevlieghere,
QuietMisdreavus,
cyndyishida and
snprajwal
as code owners
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.