commit | f90aa418978748c0613036b0285bb80af40570b7 | [log] [tgz] |
---|---|---|
author | Jan Svoboda <jan_svoboda@apple.com> | Tue Mar 11 08:51:28 2025 -0700 |
committer | GitHub <noreply@github.com> | Tue Mar 11 08:51:28 2025 -0700 |
tree | 22704821484d0a171cf867fa81cafb179c4d763d | |
parent | 93d41d814816d2933735e3d238e6eebb91dfdc30 [diff] |
[Support] Remove output file checks from `LockFileManager` (#130395) Currently, `LockFileManager` assumes the owner of the lock file creates an output file. This is problematic for at least three reasons: 1. It is orthogonal to the main purpose of this class - mutual exclusion. This makes creating an alternative implementation more complicated than it needs to be. 2. Some clients (like the upstream `AMDGPUSplitModule.cpp` file) assume the output file is not necessary. The owner of the lock file does not write the file expected by `LockFileManager` and the processes waiting for the non-owned lock file to be unlocked therefore assume the owner has died. This means that the work gets repeated by each waiting process, serially. 3. The documentation makes it sound like successfully waiting for a non-owned lock file guarantees the output file to be present on the file system. Implicitly-built modules rely on this. However, the module file may disappear between `LockFileManager` performing the check and the compiler loading the module (for example due to module cache pruning with short intervals, or intervention from outside of Clang). The compiler assumes this cannot happen, and fails the build if it does. This PR solves this situation by removing the check, reflecting that in the `LockFileManager` documentation, and fixing the time-of-check time-of-use bug in implicit modules.
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.