| commit | 32fb8c5f5fdeb20de28846e2fe9e2c7525f62086 | [log] [tgz] |
|---|---|---|
| author | Michael Spencer <[email protected]> | Tue May 06 23:40:01 2025 |
| committer | GitHub <[email protected]> | Tue May 06 23:40:01 2025 |
| tree | 0a3208ff25d811f89f4341f264be96a2970c0751 | |
| parent | a63fd59d95397d236b03e964287728a35efa296b [diff] |
[clang][modules] Lazily load by name lookups in module maps (#132853) Instead of eagerly populating the `clang::ModuleMap` when looking up a module by name, this patch changes `HeaderSearch` to only load the modules that are actually used. This introduces `ModuleMap::findOrLoadModule` which will load modules from parsed but not loaded module maps. This cannot be used anywhere that the module loading code calls into as it can create infinite recursion. This currently just reparses module maps when looking up a module by header. This is fine as redeclarations are allowed from the same file, but future patches will also make looking up a module by header lazy. This patch changes the shadow.m test to use explicitly built modules and `#import`. This test and the shadow feature are very brittle and do not work in general. The test relied on pcm files being left behind by prior failing clang invocations that were then reused by the last invocation. If you clean the cache then the last invocation will always fail. This is because the input module map and the `-fmodule-map-file=` module map are parsed in the same module scope, and `-fmodule-map-file=` is forwarded to implicit module builds. That means you are guaranteed to hit a module redeclaration error if the TU actually imports the module it is trying to shadow. This patch changes when we load A2's module map to after the `A` module has been loaded, which sets the `IsFromModuleFile` bit on `A`. This means that A2's `A` is skipped entirely instead of creating a shadow module, and we get textual inclusion. It is possible to construct a case where this would happen before this patch too. An upcoming patch in this series will rework shadowing to work in the general case, but that's only possible once header -> module lookup is lazy too.
Welcome to the LLVM project!
This repository contains the source code for LLVM, a toolkit for the construction of highly optimized compilers, optimizers, and run-time environments.
The LLVM project has multiple components. The core of the project is itself called “LLVM”. This contains all of the tools, libraries, and header files needed to process intermediate representations and convert them into object files. Tools include an assembler, disassembler, bitcode analyzer, and bitcode optimizer.
C-like languages use the Clang frontend. This component compiles C, C++, Objective-C, and Objective-C++ code into LLVM bitcode -- and from there into object files, using LLVM.
Other components include: the libc++ C++ standard library, the LLD linker, and more.
Consult the Getting Started with LLVM page for information on building and running LLVM.
For information on how to contribute to the LLVM project, please take a look at the Contributing to LLVM guide.
Join the LLVM Discourse forums, Discord chat, LLVM Office Hours or Regular sync-ups.
The LLVM project has adopted a code of conduct for participants to all modes of communication within the project.