I can see that for each clang::FileManager::getStatValue it calls clang::FileSystemStatCache::get, which calls llvm::vfs::RedirectingFileSystem::status, which calls RedirectingFileSystem(RedirectingFileSystem(RedirectingFileSystem(RedirectingFileSystem(....)))) and so on, and eventually it leads to RealFileSystem. This can be seen on line 86 on the sample above.
Could it be that stat calls are being slowed down because of this nested RedirectingFileSystem?
Why might it create such deep RedirectingFileSystem hierarchy?
It appears that HEADER_SEARCH_PATHS affects lldb perf. CocoaPods puts there all paths it knows about, and that list gets quite big. I've removed almost everything (159 paths -> 2 paths).
This is just speculation, but if you see stat() showing up in sample and reducing the number of search paths improves the performance, then I would guess it is really the file system that is slow. The fewer search paths we have, the fewer file system lookups we need to do when searching for modules. Do you might be able to create a synthetic benchmark for this with a lot of include paths that reproduces the performance problem?
Does CocoaPods support generating a header map? From a quick search it doesn't look like it. Header maps are an optimization over header search paths. Long search path lists are a build system "smell", and should be avoided for compile perf, and it seems lldb perf too. If header maps can't easily be done with CocoaPods, vfsoverlays another option.
Header maps wouldn't necessarily reduce the number of stats. Looking through a couple of Xcode projects that I have lying around many contained only relative substitutions of the form Header.h -> Dir/Header.h, which wouldn't help reducing the number of places to check for a header. I suppose an absolute substitution might work.
That said, I would really like to get my hands on a reproducer for this, because this could mean that anything from a performance/caching issue in Clang, to a performance issue in the kernel / file system itself, to a bug in LLDB's usage of Clang APIs.
It's possible that this might be related to Lldb performance with clang modules and Swift which was recently fixed. Perhaps the duplicated arguments were causing extra stat calls (not sure if Clang will deduplicate the flags). Likely worth testing with a Swift development snapshot from here.
I took two attempts to create a project to reproduce this perf issue. First with Swift PM, where I added Header Search paths via flags in Package.swift. I took all HSP from main app, put it into SPM, but lldb works fine.
Then I tried to do the same without SPM, manually added this gigantic list to some project, lldb was still fast.
So I guess this is just our story. We use public CocoaPods libraries and quite a few local development pods. Perhaps the way how CocoaPods configures the project file somehow leads to slowness in lldb.
Hitting the exact same issue here as well (have to wait ~15 minutes for lldb to resolve variables on swift code initially, and lldb is fast after the initial wait).
A little bit about the project I am running attaching LLDB to :
A mega app with objc modules and swift modules interdependencies
lldb on swift codes are initially very slow due to it spending time to populate clang module cache dir (2GB in size)
We do pass a lot of .modulemap and .hmap files as extra-clang-arguments to lldb
I am also attaching the time profiler trace : trace file
We also had a Crowdstrike Falcon corporate security tooling, and I have added the local clang module cache paths into the exclusion patterns, but without any signifcant improvement.
If you are experiencing a slow first expression / p / po in LLDB that is caused by implicit Clang module imports (basically the symptoms discussed in this thread) I would strongly encourage you to experiment with converting the project to explicitly built modules.
LLDB needs to compile implicit clang modules from source, before it caches them in its Clang module cache. This can be quite slow.
In contrast, LLDB can import Clang modules explicitly built by the build system directly, without needing to recompile them from source code. By skipping the module compilation in the debugger, this can be much faster.
But that's not all: People with complex project setups might also have run into Clang module compilation errors in LLDB that were caused by conflicting search paths. Because module compilation is skipped, enabling explicit modules also bypasses this entire class of problems.
In contrast, LLDB can import Clang modules explicitly built by the build system directly, without needing to recompile them from source code. By skipping the module compilation in the debugger, this can be much faster.
Migrating to an explicitly built module system is part of our plan and we are very much looking forward to it, but it seems challenging given the build time concerns(Build times regression with Explicitly Built Modules) and the current WIP state of its support in the Bazel ecosystem. With these challenges in mind, I’m curious if some of the stages or optimizations performed in the explicit module system - particularly those that enhance debugger performance - could be adapted or leveraged within the implicit module build system, addressing developer immediate concerns as well as giving us some buffer to migrate to explicitly built modules feature to get other benefits.
For instance, since .o files in the implicit system already reference .pcm files,
is there a way for LLDB to utilize these .pcm files directly instead of recompiling modules from source?
Alternatively, could the build system emit .pcm files into a shared cache that LLDB can access, (assuming its not happening today or for some reason the cache is being invalidated for some reason, if yes, any tooling that can help identify why the cache is being invalidated would be valuable)
Could the work that LLDB performs to build the expression context across debug sessions be cached in some way to improve performance? (relevant components as some components would be invalidated given devs iteration)
The only way to import implicitly-built pcm files is by asking Clang to import a module from source ...
..., but Clang caches the module compilation artifacts in the clang module cache. And you can point LLDB to the clang module cache used by your build. However, the chances that you will end up with the exact same module hash (a hash of the clang compiler flags) between LLDB and your build are very slim.
That's already happening. LLDB uses a persistent Clang module cache (settings show symbols.clang-modules-cache-path) and will reuse what was built in a previous debug session. But again, it's quite easy to end up with slightly different compiler flags, which affect the module hash.
I also would like to get your thoughts on a scenario I’ve observed:
I’ve noticed that when building an app target followed by a test target, they generate different hashes(directory within the clang's module cache), though the majority of the .pcm files within the directories are identical. For instance, both targets include the same variant of SwiftUI-<Hash>.pcm along with many other system modules.
I wanted to ask, in cases where project generator boundaries are rigid, is there any merit to exploring -fdisable-module-hash to reuse existing .pcm files? For example, many details like compiler arguments and target architecture (assuming all other options that contribute to the hash) are already known during the pre-build phases. This allows us to decide whether to continue using the existing cache or wipe it for the target build. If we can align this approach with expectations, it might work effectively. However, I’m unsure if clang/lldb has additional validations that could interfere with this method.
I’m just trying to understand if this has been attempted successfully and whether it’s worth considering.
I would say that short answer is that the efforts to make the different module configurations that have to be built in a project more transparent and to give users control over it have culminated in the explicitly-built modules design we have today.
For one of the app targets that was completely built with explicitly built modules, the initial po time reduced significantly from 1 minute 5 seconds to 9 seconds. This is a cool improvement. However, during this 9-second period, some .pcm files are still being generated, and I am curious to know why this is so and if there are actionable things on our end to further optimize this.
Upon inspecting a .pcm dump for OSLog clang module, I found something surprising:
This is unexpected because the target is explicitly being built for iOS 18, yet these .pcms are being generated for iOS 10.0.0.
If anyone has insights on why this might be happening or how to better debug this issue, I’d appreciate the guidance!
Here’s a .pcm dump output if anyone is interested.
Information for module file '/private/var/folders/ld/c_qy6_c52bd0xj_vz5vqj2tr0000gq/C/clang/ModuleCache/2P5NIYQC76Q6J/OSLog-QZGUL2HW47MZ.pcm':
Module format: obj
Generated by this Clang: (clang-1600.0.26.4)
Module name: OSLog
Module map file: /Applications/Xcode.16.1.0.16B40.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator18.1.sdk/System/Library/Frameworks/OSLog.framework/Modules/module.modulemap
Imports module 'Foundation': /var/folders/ld/c_qy6_c52bd0xj_vz5vqj2tr0000gq/C/clang/ModuleCache/2P5NIYQC76Q6J/Foundation-15BD7VTL9RZT4.pcm
Imports module 'os': /var/folders/ld/c_qy6_c52bd0xj_vz5vqj2tr0000gq/C/clang/ModuleCache/2P5NIYQC76Q6J/os-2QFN3XR4BJXGV.pcm
Language options:
C99: Yes
C11: Yes
C17: No
C2x: No
Microsoft Visual C++ full compatibility mode: No
Kernel mode: No
Microsoft C++ extensions: No
Microsoft inline asm blocks: No
Borland extensions: No
C++: No
C++11: No
C++14: No
C++17: No
C++20: No
C++23: No
C++26: No
Objective-C: Yes
Objective-C App Extension: No
trigraphs: No
'//' comments: Yes
bool, true, and false keywords: No
half keyword: No
wchar_t keyword: No
char8_t keyword: No
__ieee128 keyword: No
__declspec keyword: No
GNU extensions: Yes
GNU keywords: Yes
GNU C compatibility version: 40201
require function types to have a prototype: No
digraphs: Yes
C++ operator name keywords: No
Apple kext support: No
writable string support: No
const-qualified string support: No
lax vector conversions: 2
Altivec source compatibility: 0
Assume convergent functions: No
AltiVec-style vector initializers: No
System z vector extensions: No
exception handling: Yes
Objective-C exceptions: Yes
C++ exceptions: No
C/C++ EH Asynch exceptions: No
exception handling: 0
ignore exceptions: No
Assume extern C functions don't unwind: No
traditional CPP emulation: No
run-time type information: No
emit run-time type information data: No
Microsoft-compatible structure layout: No
Microsoft-compatible volatile loads and stores: No
freestanding implementation: No
disable builtin functions: No
disable math builtin functions: No
GNU-style inline assembly: Yes
C++20 coroutines: No
prefer Aligned Allocation according to P2014 Option 2: No
dllexported classes dllexport inline methods: Yes
C++17 relaxed matching of template template arguments: No
pointer authentication intrinsics: No
function pointer authentication: No
return pointer authentication: No
indirect gotos pointer authentication: No
pointer authentication failure traps: No
incorporate address discrimination in authenticated vtable pointers: No
incorporate type discrimination in authenticated vtable pointers: No
incorporate type and address discrimination in authenticated vtable pointers for std::type_info: No
authentication mode for objc isa: 0
authentication of SEL fields of ObjC interfaces: No
authentication key for SEL fields of ObjC interfaces: No
authentication key for function pointers: No
pre- and post-authentication masking for Objective-C isa pointer: No
software emulation of pointer authentication: No
pointer authentication ABI version: 0
controls whether the pointer auth abi version represents a kernel ABI: No
controls whether the pointer auth abi version should be encoded in the IR: No
enable signed block descriptors: No
Enable unstable and experimental features: No
enable unstable and experimental library features: No
'[[]]' attributes extension for all language standard modes: No
Preserve expressions in AST when encountering errors: Yes
Preserve the type in recovery expressions: Yes
POSIX thread support: No
blocks extension to C: Yes
errno in math functions: No
modules semantics: Yes
C++ modules syntax: No
builtin headers belong to system modules, and _Builtin_ modules are ignored for cstdlib headers: No
require declaration of module uses: No
requiring declaration of module uses and all headers to be in modules: No
local submodule visibility: No
hash out diagnostic errors as part of the module hash: No
enable ODR hash checking for attributes: No
disable ODR hash checking for categories: Yes
disable ODR hash checking for interfaces: Yes
disable ODR hash checking for protocols: No
disable ODR hash checking for records: Yes
disable ODR hash checking for properties: Yes
disable ODR hash checking for ivars: Yes
disable ODR hash checking for methods: Yes
__OPTIMIZE__ predefined macro: Yes
__OPTIMIZE_SIZE__ predefined macro: Yes
__STATIC__ predefined macro (as opposed to __DYNAMIC__): No
default struct packing maximum alignment: 0
default maximum alignment for types: 16
Controls if doubles should be aligned to 8 bytes (x86 only): 0
width of double: 0
width of long double: 0
use IEEE 754 quadruple-precision for long double: No
__EXTABI__ predefined macro: No
Use 16-byte atomic lock free semantics: No
__PIC__ level: 2
is pie: 0
Read-only position independence: No
Read-write position independence: No
GNU inline semantics: No
__NO_INLINE__ predefined macro: No
__DEPRECATED predefined macro: No
fast FP math optimizations, and __FAST_MATH__ predefined macro: No
__FINITE_MATH_ONLY__ predefined macro: No
Unsafe Floating Point Math: No
optimizer honors parentheses when floating-point expressions are evaluated: No
signed char: Yes
width of wchar_t: No
signed or unsigned wchar_t: Yes
member-pointer representation method: 0
default calling convention: 0
short enum types: No
OpenCL: No
OpenCL C version: No
C++ for OpenCL: No
C++ for OpenCL version: No
OpenCL generic keyword: No
OpenCL pipes language constructs and built-ins: No
Native half type support: No
Native half args and returns: No
CUDA: No
HIP: No
OpenMP support and version of OpenMP (31, 40 or 45): No
Enable all Clang extensions for OpenMP directives and clauses: Yes
Use SIMD only OpenMP support.: No
Use TLS for threadprivates or runtime calls: No
Generate code only for OpenMP target device: No
Generate code for OpenMP pragmas in SIMT/SPMD mode: No
Use the experimental OpenMP-IR-Builder codegen path.: No
Number of SMs for CUDA devices.: No
Number of blocks per SM for CUDA devices.: No
Number of the reduction records in the intermediate reduction buffer used for the teams reductions.: Yes
Enable debugging in the OpenMP offloading device RTL: No
Use at most 32 bits to represent the collapsed loop nest counter.: No
Assume work-shared loops do not have more iterations than participating threads.: No
Assume distributed loops do not have more iterations than participating teams.: No
Assume that no thread in a parallel region will modify an ICV.: No
Assume that no thread in a parallel region will encounter a parallel region: No
Assert that offloading is mandatory and do not create a host fallback.: No
Indicate a build without the standard GPU libraries.: No
RenderScript: No
HLSL: No
HLSL Version: 0
compiling for CUDA device: No
allowing variadic functions in CUDA device code: No
treating unattributed constexpr functions as __host__ __device__: Yes
using approximate transcendental functions: No
generate relocatable device code: No
allowing device side global init functions for HIP: No
default max threads per block for kernel launch bounds for HIP: Yes
defer host/device related diagnostic messages for CUDA/HIP: No
always exclude wrong side overloads in overloading resolution for CUDA/HIP: No
use the new driver for generating offloading code.: No
Generate code for SYCL device: No
SYCL host compilation: No
Version of the SYCL standard used: 0
Use new kernel launching API for HIP: No
sized deallocation: No
aligned allocation: No
aligned allocation functions are unavailable: No
maximum alignment guaranteed by '::operator new(size_t)': No
no constant CoreFoundation strings: No
constant Objective-C literals: Yes
no constant number literals: No
no constant array literals: No
no constant dictionary literals: No
hidden visibility for global operator new and delete declaration: No
check availability for target variant platform: No
Treats throwing global C++ operator new as always returning valid memory (annotates with __attribute__((returns_nonnull)) and throw()). This is detectable in source.: No
treating double-precision floating point constants as single precision constants: No
OpenCL fast relaxed math: No
Unsafe Floating Point Math: No
__FINITE_MATH_ONLY__ predefined macro: No
Enable experimental strict floating point: No
Intermediate truncation behavior for Float16 arithmetic: 0
Intermediate truncation behavior for BFloat16 arithmetic: 0
bit-field type alignment: No
hexagon-qdsp6 backward compatibility: No
Objective-C automated reference counting: Yes
__weak support in the ARC runtime: Yes
Objective-C __weak in ARC and MRC files: Yes
Ignore ARC-style __weak instead of erroring: No
Subscripting support in legacy ObjectiveC runtime: No
Disable recognition of objc_direct methods: No
Control-Flow Branch Protection enabled: No
OpenCL fake address space map: No
OpenCL address space map mangling mode: 0
Include default header file for OpenCL: No
Declare OpenCL builtin functions: No
optional blocks runtime: No
Require member pointer base types to be complete at the point where the type's inheritance model would be determined under the Microsoft ABI: No
Objective-C Garbage Collection mode: 0
apply global symbol visibility to external declarations without an explicit visibility: No
set the visiblity of globals from their DLL storage class [-fvisibility-from-dllstorageclass]: No
visibility for functions and variables with dllexport annotations [-fvisibility-from-dllstorageclass]: 2
visibility for functions and variables without an explicit DLL storage class [-fvisibility-from-dllstorageclass]: 0
visibility for external declarations with dllimport annotations [-fvisibility-from-dllstorageclass]: 2
visibility for external declarations without an explicit DLL storage class [-fvisibility-from-dllstorageclass]: 0
stack protector mode: 1
stack checking: No
controls whether to use strong linking for darwin stack checking (x86 only): No
trivial automatic variable initialization: 0
stop trivial automatic variable initialization after the specified number of instances. Must be greater than 0.: 0
Zero initialize only first N bytes of each stack variable.: 0
do not auto-initialize objects initialized by a C++ constructor: No
do not auto-initialize non-POD objects: No
do not auto-initialize variables in STL namespace: No
do not auto-initialize arrays other than arrays of pointers: No
signed integer overflow handling: 0
Thread Model: 0
Microsoft Visual C/C++ Version: 0
How many vtordisps to insert: 1
Apple gcc-compatible #pragma pack handling: No
IBM XL #pragma pack handling: No
retain documentation comments from system headers in the AST: Yes
use external API notes: No
use external API notes: Yes
compilation involves pch: Yes
controls how aggressive is ASan field padding (0: none, 1:least aggressive, 2: more aggressive): No
ARM Security extensions support: No
controls whether to do XRay instrumentation: No
controls whether to always emit intrinsic calls to __xray_customevent(...) builtin.: No
controls whether to always emit intrinsic calls to __xray_typedevent(...) builtin.: No
whether to emit all vtables: No
version of Clang that we should attempt to be ABI-compatible with: 1
Default alignment for functions: 0
Default alignment for loops: 0
fixed point types: No
unsigned fixed point types having one extra padding bit: No
Register C++ static destructors: Yes
Enable or disable the builtin matrix type: No
Rely on strict definition of flexible arrays: 0
Max number of tokens per TU or 0: 0
enable noescape optimized blocks: No
Scope of return address signing: 0
Key used for return address signing: 0
Branch-target enforcement enabled: No
Speculative load hardening enabled: No
Use an ABI-incompatible v-table layout that uses relative references: No
Minimum vscale value: No
Maximum vscale value: No
Controls how scalar integer arguments are extended in calls to unprototyped and varargs functions: 0
Fuchsia API level: 0
Maximum width of a _BitInt: 0
Typed Memory Operations Callsite Rewriting: No
Use typed variants of C++ new(): No
Use typed variants of C++ delete(): No
Allow CWG1423: No
Revert f50d1aca992864d7edd65a449f5368b53727752a and return id for [self alloc]: No
Revert 4257857bf8a508b56f73f61bdf941194913bac92 and do not infer +new availability: No
Revert dafc3106d2069b806a10e072306a2196f1cda585 and do not emit -Wformat: No
Revert 5741d19f046f24450ebda3a421a8ce49043ad2b8 and do not emit -Wformat: No
Revert 7ae1b4a0ce9c7f269cf3069e41496a78e3f28d49 and allow static members in anon unions: No
Revert 7ae1b4a0ce9c7f269cf3069e41496a78e3f28d49 and allow static members in local structs: No
: No
Revert 878a24ee244a24c39d1c57e9af2e88c621f7cce9 and give some implicit member expressions dependent type: Yes
Revert part of c90e198107431f64b73686bdce31c293e3380ac7: No
Revert 536b0ee40ab97f2878dc124a321cf9108ee3d233 and don't check nullptr arithmetic: No
Disable 89b1a463a531dbdb18aa3516d7b8fd7482d1d3a0: No
Disable (part of) 96c899449b61b866b583560a49c4627f561336fc: No
Disable a4a60ad51dd58da2c15ef505d5fe527ef3fecd89: No
Disable ccc4d83cda16bea1d9dfd0967dc7d2cfb24b8e75: No
rdar://67765582: No
Disable (part of) 552c6c232872: Yes
rdar://72363517: No
rdar://72823399: Yes
rdar://67765582: No
rdar://81325777: Yes
rdar://81712146: Yes
rdar://109046920: Yes
: No
Disable ObjCConstantLiterals in projects that do not handle it: No
Suppress conflicting type errors from mismatching declarations: No
True if we want to process statementson the global scope, ignore EOF token and continue later on (thus avoid tearing the Lexer and etc. down). Controlled by -fincremental-extensions.: No
Module features:
swift
Target options:
Triple: arm64-apple-ios10.0.0-simulator
CPU: apple-a12
TuneCPU:
ABI: darwinpcs
Target features:
+v8.3a
+aes
+crc
+fp-armv8
+fullfp16
+lse
+ras
+rcpc
+rdm
+sha2
+neon
+zcm
+zcz
Header search options:
System root [-isysroot=]: '/Applications/Xcode.16.1.0.16B40.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator18.1.sdk'
Resource dir [ -resource-dir=]: '/Applications/Xcode.16.1.0.16B40.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/clang'
Module Cache: '/var/folders/ld/c_qy6_c52bd0xj_vz5vqj2tr0000gq/C/clang/ModuleCache/2P5NIYQC76Q6J'
Use builtin include directories [-nobuiltininc]: Yes
Use standard system include directories [-nostdinc]: Yes
Use standard C++ include directories [-nostdinc++]: Yes
Use libc++ (rather than libstdc++) [-stdlib=]: No
Preprocessor options:
Uses compiler/target-specific predefines [-undef]: Yes
Uses detailed preprocessing record (for indexing): No
Input file: /Applications/Xcode.16.1.0.16B40.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator18.1.sdk/System/Library/Frameworks/OSLog.framework/Modules/module.modulemap [System]
Input file: /Applications/Xcode.16.1.0.16B40.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator18.1.sdk/System/Library/Frameworks/OSLog.framework/Headers/OSLog.h [System]
Input file: /Applications/Xcode.16.1.0.16B40.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator18.1.sdk/System/Library/Frameworks/Foundation.framework/Modules/module.modulemap [System]
Input file: /Applications/Xcode.16.1.0.16B40.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator18.1.sdk/usr/include/os.modulemap [System]
Input file: /Applications/Xcode.16.1.0.16B40.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator18.1.sdk/System/Library/Frameworks/OSLog.framework/Headers/Entry.h [System]
Input file: /Applications/Xcode.16.1.0.16B40.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator18.1.sdk/System/Library/Frameworks/OSLog.framework/Headers/EntryActivity.h [System]
Input file: /Applications/Xcode.16.1.0.16B40.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator18.1.sdk/System/Library/Frameworks/OSLog.framework/Headers/EntryBoundary.h [System]
Input file: /Applications/Xcode.16.1.0.16B40.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator18.1.sdk/System/Library/Frameworks/OSLog.framework/Headers/EntryLog.h [System]
Input file: /Applications/Xcode.16.1.0.16B40.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator18.1.sdk/System/Library/Frameworks/OSLog.framework/Headers/EntrySignpost.h [System]
Input file: /Applications/Xcode.16.1.0.16B40.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator18.1.sdk/System/Library/Frameworks/OSLog.framework/Headers/Enumerator.h [System]
Input file: /Applications/Xcode.16.1.0.16B40.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator18.1.sdk/System/Library/Frameworks/OSLog.framework/Headers/MessageComponent.h [System]
Input file: /Applications/Xcode.16.1.0.16B40.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator18.1.sdk/System/Library/Frameworks/OSLog.framework/Headers/Position.h [System]
Input file: /Applications/Xcode.16.1.0.16B40.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator18.1.sdk/System/Library/Frameworks/OSLog.framework/Headers/Store.h [System]
Module file extension 'swift.lookup' 1.18: Apple Swift version 6.0.2 effective-5.10 (swiftlang-6.0.2.1.2 clang-1600.0.26.4)
Diagnostic options:
IgnoreWarnings: No
NoRewriteMacros: No
Pedantic: No
PedanticErrors: No
ShowLine: Yes
ShowColumn: Yes
ShowLocation: Yes
ShowLevel: Yes
AbsolutePath: No
ShowCarets: Yes
ShowFixits: Yes
ShowSourceRanges: No
ShowParseableFixits: No
ShowPresumedLoc: Yes
ShowOptionNames: Yes
ShowNoteIncludeStack: No
ShowCategories: 0
Format: 0
ShowColors: No
UseANSIEscapeCodes: Yes
ShowOverloads: 0
VerifyDiagnostics: No
VerifyIgnoreUnexpected: 0
ElideType: Yes
ShowTemplateTree: No
ErrorLimit: 19
MacroBacktraceLimit: 6
TemplateBacktraceLimit: 10
ConstexprBacktraceLimit: 10
SpellCheckingLimit: 50
SnippetLineLimit: 16
ShowLineNumbers: 1
TabStop: 8
MessageLength: 0
ShowSafeBufferUsageSuggestions: No
BoundsSafetyAdoptionMode: No
Diagnostic flags:
-Wdeprecated-objc-isa-usage
-Werror=deprecated-objc-isa-usage
-Werror=implicit-function-declaration
-Wno-reorder-init-list
-Wno-implicit-int-float-conversion
-Wno-c99-designator
-Wno-final-dtor-non-final-class
-Wno-extra-semi-stmt
-Wno-misleading-indentation
-Wno-quoted-include-in-framework-header
-Wno-implicit-fallthrough
-Wno-enum-enum-conversion
-Wno-enum-float-conversion
-Wno-elaborated-enum-base
-Wno-reserved-identifier
-Wno-gnu-folding-constant
Header search paths:
User entries:
/Applications/Xcode.16.1.0.16B40.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator18.1.sdk/usr/lib/swift/shims
/Applications/Xcode.16.1.0.16B40.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift
/Applications/Xcode.16.1.0.16B40.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator18.1.sdk/usr/local/include
/Applications/Xcode.16.1.0.16B40.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/clang/include
/Applications/Xcode.16.1.0.16B40.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator18.1.sdk/usr/include
/Applications/Xcode.16.1.0.16B40.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
/private/var/tmp/_bazel_ios/external/some-framework/someFrameworkName.xcframework/macos-arm64_x86_64
/private/var/tmp/_bazel_ios/external/some-framework/someFrameworkName.xcframework/macos-arm64_x86_64
/private/var/tmp/_bazel_ios/external/some-framework/someFrameworkName.xcframework/ios-arm64_x86_64-simulator
/private/var/tmp/_bazel_ios/external/some-framework/someFrameworkName.xcframework/ios-arm64_x86_64-simulator
/private/var/tmp/_bazel_ios/external/some-framework/someFrameworkName.xcframework/ios-arm64_x86_64-simulator
/private/var/tmp/_bazel_ios/external/some-framework/someFrameworkName.xcframework/ios-arm64_x86_64-simulator
/private/var/tmp/_bazel_ios/external/some-framework/someFrameworkName.xcframework/ios-arm64_x86_64-simulator
/private/var/tmp/_bazel_ios/external/some-framework/someFrameworkName.xcframework/ios-arm64_x86_64-simulator
/private/var/tmp/_bazel_ios/external/some-framework/someFrameworkName.xcframework/ios-arm64_x86_64-simulator
/private/var/tmp/_bazel_ios/external/some-framework/someFrameworkName.xcframework/ios-arm64_x86_64-simulator
/private/var/tmp/_bazel_ios/external/some-framework/someFrameworkName.xcframework/macos-arm64_x86_64
/private/var/tmp/_bazel_ios/external/some-framework/someFrameworkName.xcframework/ios-arm64_x86_64-simulator
/private/var/tmp/_bazel_ios/external/some-framework/someFrameworkName.xcframework/ios-arm64_x86_64-simulator
/private/var/tmp/_bazel_ios/external/some-framework/someFrameworkName.xcframework/ios-arm64_i386_x86_64-simulator
/private/var/tmp/_bazel_ios/external/some-framework/someFrameworkName.xcframework/ios-arm64_x86_64-simulator
/private/var/tmp/_bazel_ios/external/some-framework/someFrameworkName.xcframework/ios-arm64_i386_x86_64-simulator
/private/var/tmp/_bazel_ios/external/some-framework/someFrameworkName.xcframework/ios-arm64_x86_64-simulator
/private/var/tmp/_bazel_ios/external/some-framework/someFrameworkName.xcframework/macos-arm64_x86_64
/private/var/tmp/_bazel_ios/external/some-framework/someFrameworkName.xcframework/macos-arm64_x86_64
/private/var/tmp/_bazel_ios/external/some-framework/someFrameworkName.xcframework/macos-arm64_x86_64
/private/var/tmp/_bazel_ios/external/some-framework/someFrameworkName.xcframework/ios-arm64_x86_64-simulator
/private/var/tmp/_bazel_ios/external/some-framework/someFrameworkName.xcframework/ios-arm64_i386_x86_64-simulator
/private/var/tmp/_bazel_ios/external/some-framework/someFrameworkName.xcframework/ios-arm64_x86_64-simulator
/private/var/tmp/_bazel_ios/external/some-framework/someFrameworkName.xcframework/ios-arm64_x86_64-simulator
/private/var/tmp/_bazel_ios/external/some-framework/someFrameworkName.xcframework/ios-arm64_x86_64-simulator
/private/var/tmp/_bazel_ios/external/some-framework/someFrameworkName.xcframework/ios-arm64_x86_64-simulator
/private/var/tmp/_bazel_ios/external/some-framework/someFrameworkName.xcframework/ios-arm64_x86_64-simulator
/private/var/tmp/_bazel_ios/external/some-framework/someFrameworkName.xcframework/ios-arm64_x86_64-simulator
/private/var/tmp/_bazel_ios/external/some-framework/someFrameworkName.xcframework/ios-arm64_x86_64-simulator
/private/var/tmp/_bazel_ios/external/some-framework/someFrameworkName.xcframework/ios-arm64_x86_64-simulator
/private/var/tmp/_bazel_ios/external/some-framework/someFrameworkName.xcframework/macos-arm64_x86_64
/private/var/tmp/_bazel_ios/external/some-framework/someFrameworkName.xcframework/ios-arm64_x86_64-simulator
/private/var/tmp/_bazel_ios/external/some-framework/someFrameworkName.xcframework/ios-arm64_x86_64-simulator
/private/var/tmp/_bazel_ios/external/some-framework/someFrameworkName.xcframework/ios-arm64_x86_64-simulator
/private/var/tmp/_bazel_ios/external/some-framework/someFrameworkName.xcframework/ios-arm64_i386_x86_64-simulator
/private/var/tmp/_bazel_ios/external/some-framework/someFrameworkName.xcframework/macos-arm64_x86_64
/private/var/tmp/_bazel_ios/external/some-framework/someFrameworkName.xcframework/ios-arm64_x86_64-simulator
/private/var/tmp/_bazel_ios/external/some-framework/someFrameworkName.xcframework/ios-arm64_i386_x86_64-simulator
/private/var/tmp/_bazel_ios/external/some-framework/someFrameworkName.xcframework/macos-arm64_x86_64
/private/var/tmp/_bazel_ios/external/some-framework/someFrameworkName.xcframework/ios-arm64_x86_64-simulator
/private/var/tmp/_bazel_ios/external/some-framework/someFrameworkName.xcframework/macos-arm64_x86_64
/private/var/tmp/_bazel_ios/external/some-framework/someFrameworkName.xcframework/macos-arm64_x86_64
/Users/chirag.ramani/Library/Developer/Xcode/DerivedData/helpsampleapp_helpsamplemainlib_49021d/Build/Products/Debug-iphonesimulator
/Users/chirag.ramani/Library/Developer/Xcode/DerivedData/helpsampleapp_helpsamplemainlib_49021d/Build/Products/Debug-iphonesimulator
/Users/chirag.ramani/Uber/ios/.project/includes/HelpSampleMainLib
System header prefixes:
VFS overlay files:
Does this also happen if you just evaluate an expression with --bind-generic-types false? If that fixes the issue @augusto2112 is currently working on a resolution.
