d076608d58d1ec55016eb747a995511e3a3f72aa moved some deps around to avoid cycles and left clang/Frontend/FrontendDiagnostic.h as a shim that simply includes clang/Basic/DiagnosticFrontend.h. This PR inlines it so that nothing in tree still includes clang/Frontend/FrontendDiagnostic.h. Doing this will help prevent future layering issues. See #162865. Frontend already depends on Basic, so no new deps need to be added anywhere except for places that do strict dep checking.
This relands #167348. The original PR was reverted due to a reported build failure, which was later diagnosed as a local issue in the developer’s checkout or build state. See discussion here: https://github.com/llvm/llvm-project/pull/163659#discussion_r2511546964 No additional changes have been made in this reland.
Reverts #163659 due to missing one reference clang/Driver/Options.h in clang/include/clang/Driver/Driver.h. See https://github.com/llvm/llvm-project/pull/163659#issuecomment-3512979187
This change moves option-related code from clangDriver into a new clangOptions library. This refactoring is part of a broader effort to support driver-managed builds for compilations using C++ named modules and/or Clang modules. It is required for linking the dependency scanning tooling against the driver without introducing cyclic dependencies, which would otherwise cause build failures when dynamic linking is enabled. In particular, clangFrontend must no longer depend on clangDriver for this to be possible. This PR is motivated by the following review comment: https://github.com/llvm/llvm-project/pull/152770#discussion_r2430756918
Since https://github.com/llvm/llvm-project/pull/158381 the `CompilerInstance` is aware of the VFS and co-owns it. To reduce scope of that PR, the VFS was being inherited from the `FileManager` during `setFileManager()` if it wasn't configured before. However, the implementation of that setter was buggy. This PR fixes the bug, and moves us closer to the long-term goal of `CompilerInstance` requiring the VFS to be configured explicitly and owned by the instance.
The `CompilerInstance::createSourceManager()` function currently accepts the `FileManager` to be used. However, all clients call `CompilerInstance::createFileManager()` prior to creating the `SourceManager`, and it never makes sense to use a `FileManager` in the `SourceManager` that's different from the rest of the compiler. Passing the `FileManager` explicitly is redundant, error-prone, and deviates from the style of other `CompilerInstance` initialization APIs. This PR therefore removes the `FileManager` parameter from `createSourceManager()` and also stops returning the `FileManager` pointer from `createFileManager()`, since that was its primary use. Now, `createSourceManager()` internally calls `getFileManager()` instead.
This PR is a part of the effort to make the VFS used in the compiler
more explicit and consistent.
Instead of creating the VFS deep within the compiler (in
`CompilerInstance::createFileManager()`), clients are now required to
explicitly call `CompilerInstance::createVirtualFileSystem()` and
provide the base VFS from the outside.
This PR also helps in breaking up the dependency cycle where creating a
properly configured `DiagnosticsEngine` requires a properly configured
VFS, but creating properly configuring a VFS requires the
`DiagnosticsEngine`.
Both `CompilerInstance::create{FileManager,Diagnostics}()` now just use
the VFS already in `CompilerInstance` instead of taking one as a
parameter, making the VFS consistent across the instance sub-object.
…ilation database Currently a hard crash encourages people to report a bug upstream, but this is not really a bug. Instead, print an error and use a reasonable default (the current working directory). Fixes #57264 Co-authored-by: Carlos Gálvez <carlos.galvez@zenseact.com>
Fixes https://github.com/llvm/llvm-project/issues/155545
This commit handles the following types: - clang::ExternalASTSource - clang::TargetInfo - clang::ASTContext - clang::SourceManager - clang::FileManager Part of cleanup #151026