https://github.com/benlangmuir approved this pull request.
https://github.com/llvm/llvm-project/pull/125111
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/benlangmuir created
https://github.com/llvm/llvm-project/pull/125098
This reverts commit d6524c8dfa37634257050ca71d16e117b802181c. This reverts
commit b1bd73700a1fb6f450e0f6f9c405a9c8bde2cae7.
This was causing bot failures on Darwin
https://green.lab.llvm.org/job/llvm.org/j
@@ -0,0 +1,141 @@
+//===- ModuleMapFile.h - Parsing and representation -*- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
https://github.com/benlangmuir edited
https://github.com/llvm/llvm-project/pull/119740
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -3157,25 +2140,18 @@ bool ModuleMap::parseModuleMapFile(FileEntryRef File,
bool IsSystem,
assert((!Offset || *Offset <= Buffer->getBufferSize()) &&
"invalid buffer offset");
- // Parse this module map file.
- Lexer L(SourceMgr.getLocForStartOfFile(ID), MMapLan
@@ -0,0 +1,141 @@
+//===- ModuleMapFile.h - Parsing and representation -*- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
https://github.com/benlangmuir commented:
I'm happy with the way this split of the code worked out!
> Currently this has no effect other than slightly changing diagnostics.
Can you say more about the ordering changes? I understand we can't always emit
diagnostics in source order, but it's help
https://github.com/benlangmuir created
https://github.com/llvm/llvm-project/pull/124003
With the changes in 48d0eb518, the CodeGenOptions used to emit .pcm files with
-fmodule-format=obj (-gmodules) were the ones from the original invocation,
rather than the ones specifically crafted for outpu
benlangmuir wrote:
There's probably a better way, but I just built my first clang normally then
built a second one with
`-DCMAKE_C_COMPILER` and `-DCMAKE_CXX_COMPILER` pointing to the first one, and
`-DLLVM_ENABLE_MODULES=1` to enable modules.
https://github.com/llvm/llvm-project/pull/122726
_
benlangmuir wrote:
I see that this change has already been reverted by @ilya-biryukov , but FYI
before this is re-applied: I am seeing crashes from this change if I attempt to
bootstrap a build of clang with modules enabled on Darwin. I haven't yet
managed to minimize a test case, but compili
https://github.com/benlangmuir created
https://github.com/llvm/llvm-project/pull/122955
When we mark a module visible, we normally mark all of its non-explicit
submodules and other exports as visible. However, when we first enter a
submodule we should not make them visible to the submodule its
@@ -248,39 +236,14 @@ LockFileManager::LockFileManager(StringRef FileName)
// There is a lock file that nobody owns; try to clean it up and get
// ownership.
-if ((EC = sys::fs::remove(LockFileName))) {
- std::string S("failed to remove lockfile ");
- S.a
https://github.com/benlangmuir approved this pull request.
https://github.com/llvm/llvm-project/pull/131940
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -739,6 +748,12 @@ ModuleDepCollectorPP::handleTopLevelModule(const Module
*M) {
MDC.ScanInstance.getASTReader()->visitInputFileInfos(
*MF, /*IncludeSystem=*/true,
[&](const serialization::InputFileInfo &IFI, bool IsSystem) {
+if (MD.IsInSysroot) {
+
https://github.com/benlangmuir approved this pull request.
https://github.com/llvm/llvm-project/pull/131193
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/benlangmuir edited
https://github.com/llvm/llvm-project/pull/130634
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -739,6 +795,12 @@ ModuleDepCollectorPP::handleTopLevelModule(const Module
*M) {
MDC.ScanInstance.getASTReader()->visitInputFileInfos(
*MF, /*IncludeSystem=*/true,
[&](const serialization::InputFileInfo &IFI, bool IsSystem) {
+if (MD.IsShareable) {
+
@@ -157,6 +157,32 @@ static void optimizeCWD(CowCompilerInvocation
&BuildInvocation, StringRef CWD) {
}
}
+/// Check a subset of invocation options to determine whether the current
+/// context can safely be considered as shareable.
+static bool areOptionsInSharedDir(CowCom
https://github.com/benlangmuir approved this pull request.
https://github.com/llvm/llvm-project/pull/130634
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/benlangmuir approved this pull request.
https://github.com/llvm/llvm-project/pull/132063
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -48,7 +48,7 @@ void ASTMergeAction::ExecuteAction() {
/*ShouldOwnClient=*/true));
std::unique_ptr Unit = ASTUnit::LoadFromASTFile(
ASTFiles[I], CI.getPCHContainerReader(), ASTUnit::LoadEverything,
Diags,
-CI.getFileSys
@@ -116,7 +116,7 @@ class ASTUnit {
std::shared_ptr PP;
IntrusiveRefCntPtr Ctx;
std::shared_ptr TargetOpts;
- std::shared_ptrHSOpts;
+ std::unique_ptr HSOpts;
benlangmuir wrote:
Is there still a reason to keep this a poi
https://github.com/benlangmuir approved this pull request.
Sounds great, thanks for explaining!
https://github.com/llvm/llvm-project/pull/133467
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cf
@@ -569,7 +569,7 @@
CrossTranslationUnitContext::ASTLoader::loadFromDump(StringRef ASTDumpPath) {
return ASTUnit::LoadFromASTFile(
ASTDumpPath, CI.getPCHContainerOperations()->getRawReader(),
ASTUnit::LoadEverything, Diags, CI.getFileSystemOpts(),
- CI.getHe
https://github.com/benlangmuir edited
https://github.com/llvm/llvm-project/pull/132984
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/benlangmuir commented:
Basically LGTM but there are two clients that I'm not familiar with.
https://github.com/llvm/llvm-project/pull/132984
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailm
@@ -0,0 +1,44 @@
+//===--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apac
https://github.com/benlangmuir commented:
I have a similar concern to @jansvoboda11 that we probably need to check the
invocation paths as well.
> I would think that if ModuleDepCollector only found dependency inputs that
> resolve to sysroot locations, the command line for building the spec
@@ -835,6 +850,13 @@ void ModuleDepCollectorPP::addAllSubmoduleDeps(
});
}
+void ModuleDepCollectorPP::addClangModule(const Module *M, const ModuleID ID,
benlangmuir wrote:
How about something like "addOneModuleDep"? If find it hard to guess from the
name
https://github.com/benlangmuir edited
https://github.com/llvm/llvm-project/pull/130634
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -157,42 +157,35 @@ class RemoveUniqueLockFileOnSignal {
} // end anonymous namespace
-LockFileManager::LockFileManager(StringRef FileName)
-{
- this->FileName = FileName;
- if (std::error_code EC = sys::fs::make_absolute(this->FileName)) {
-std::string S("failed to o
@@ -739,6 +748,12 @@ ModuleDepCollectorPP::handleTopLevelModule(const Module
*M) {
MDC.ScanInstance.getASTReader()->visitInputFileInfos(
*MF, /*IncludeSystem=*/true,
[&](const serialization::InputFileInfo &IFI, bool IsSystem) {
+if (MD.IsInSysroot) {
+
https://github.com/benlangmuir approved this pull request.
https://github.com/llvm/llvm-project/pull/135405
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/benlangmuir approved this pull request.
https://github.com/llvm/llvm-project/pull/130627
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/benlangmuir approved this pull request.
https://github.com/llvm/llvm-project/pull/130395
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/benlangmuir closed
https://github.com/llvm/llvm-project/pull/129774
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/benlangmuir closed
https://github.com/llvm/llvm-project/pull/127110
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/benlangmuir created
https://github.com/llvm/llvm-project/pull/127110
When using the clang dependency scanner with an arbitrary DiagnosticConsumer,
it is important that we always call finish(). Previously, if there was an error
preventing us from reaching the scanning action,
https://github.com/benlangmuir commented:
There's another call to finish() in DependencyScanningWorker that should be
removed if we do this.
https://github.com/llvm/llvm-project/pull/100681
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https
https://github.com/benlangmuir closed
https://github.com/llvm/llvm-project/pull/122955
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -130,11 +130,11 @@ class DependencyScanningWorker {
DependencyActionController &Controller,
StringRef ModuleName);
- bool shouldEagerLoadModules() const { return EagerLoadModules; }
-
llvm::vfs::FileSys
https://github.com/benlangmuir approved this pull request.
https://github.com/llvm/llvm-project/pull/128959
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/benlangmuir approved this pull request.
https://github.com/llvm/llvm-project/pull/119740
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/benlangmuir approved this pull request.
https://github.com/llvm/llvm-project/pull/134404
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
benlangmuir wrote:
Are you planning to do the same for LangOpts and HSOpts? What's the ultimate
goal here?
There's also this comment on `CompilerInvocationBase`:
```
/// ... It keeps individual option objects
/// behind reference-counted pointers, which is useful for clients that want to
/// ke
https://github.com/benlangmuir approved this pull request.
https://github.com/llvm/llvm-project/pull/134284
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/benlangmuir edited
https://github.com/llvm/llvm-project/pull/139751
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/benlangmuir approved this pull request.
Nice find, thanks for fixing.
https://github.com/llvm/llvm-project/pull/139751
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commit
@@ -0,0 +1,49 @@
+// This test checks that the module cache gets invalidated when the
SDKSettings.json file changes.
+
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+
+//--- AppleTVOS15.0.sdk/SDKSettings-old.json
+{
+ "DisplayName": "tvOS 15.0",
+ "Version": "15.0",
+ "Canonica
benlangmuir wrote:
> I don't think we can ever get rid of that pattern and we will keep relying on
> Clang supporting this.
> We would need to example I shared above to keep working.
> I think the change we want is to always prioritize modular over textual,
> before we look at non-private vs p
benlangmuir wrote:
> I don't think we can ever get rid of that pattern and we will keep relying on
> Clang supporting this.
> We would need to example I shared above to keep working.
I don't have a strong opinion on the best path forward here, but I'm not clear
if you're actually willing to
401 - 451 of 451 matches
Mail list logo