ilya-biryukov wrote:
Here's a small repro:
```cpp
export module Foo;
export template
struct Wrapper {
double value;
};
export constexpr Wrapper Compute() {
return Wrapper{1.0};
}
export template
Wrapper ComputeInFloat() {
const Wrapper a = Compute();
return a;
}
```
it fails when as
https://github.com/ilya-biryukov approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/137163
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ilya-biryukov wrote:
> My first thought is that this has tried to use more stack than its allowed.
that's probably the case, the test is a complete overkill, I just wanted to
make sure we do hit the issue with upstream Clang when adding it.
The buildbot in question is using asan for sure (based
https://github.com/ilya-biryukov approved this pull request.
LG from my side, but I would wait for another approval just to make sure people
are on board with a relatively-large NFC refactoring.
Code style is a subjective matter, so having a little more backing from
@AaronBallman or someone el
https://github.com/ilya-biryukov closed
https://github.com/llvm/llvm-project/pull/145734
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ilya-biryukov edited
https://github.com/llvm/llvm-project/pull/145734
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ilya-biryukov created
https://github.com/llvm/llvm-project/pull/145734
The function already exposes a work list to avoid deep recursion, this commit
starts utilizing it in a helper that could also lead to a deep recursion.
We have observed this crash on `clang/test/C/C99/n59
ilya-biryukov wrote:
I have started picking this back up after a break, sorry for the delays. I will
address the comments in the coming days and send an updated version. #139730
also didn't really pick up, so I'm going to abandon the simpler attempt and
double down on this PR.
https://github.
@@ -6484,6 +6499,57 @@ class SubstTemplateTypeParmType final
}
};
+/// Represents the result of substituting a set of types as a template argument
+/// that needs to be expanded later.
+///
+/// These types are always dependent and produced depending on the situations:
+///
@@ -5054,95 +5089,128 @@ bool
TreeTransform::TransformTemplateArguments(
}
if (In.getArgument().isPackExpansion()) {
- // We have a pack expansion, for which we will be substituting into
- // the pattern.
- SourceLocation Ellipsis;
- UnsignedOrNone
https://github.com/ilya-biryukov requested changes to this pull request.
Thanks, I believe we've seen some related breakages in the past and had to
workaround the module structure because of this. It would definitely save some
cycles for us in the future!
My only request is to keep this change
https://github.com/ilya-biryukov edited
https://github.com/llvm/llvm-project/pull/144796
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -828,7 +828,23 @@ void ODRHash::AddDecl(const Decl *D) {
return;
}
- AddDeclarationName(ND->getDeclName());
+ // For template parameters, use depth+index instead of name, because type
+ // canonicalization can change the name of the template parameter.
+ if (auto
@@ -5164,6 +5164,29 @@ namespace A {
A::X x;
#endif
+namespace TemplateDecltypeOperator {
+
+#if defined(FIRST) || defined(SECOND)
+template
+T6 func();
+#endif
+
+#if defined(SECOND)
+template
+using UnrelatedAlias = decltype(func())();
+#endif
+
+#if defined(FIRST) || defi
ilya-biryukov wrote:
> It's just that a canonical template parameter type doesn't refer to a
> particular template parameter declaration.
The particular statement is that Clang canonicalizes `decltype(func())` to
`decltype(func())`. If we don't
change that, we end up with spurious false posi
ilya-biryukov wrote:
> So far we are still aiming for a more principled solution. For example, if
> support of a header in multiple modules is a supported feature, then some
> kind of a spec with a more comprehensive testing would be appropriate. It is
> up to you but personally I feel like th
ilya-biryukov wrote:
> I'm sorry that my replies came across as hostile and snarky, I didn't mean it
> that way. Though I'll admit I'm not thrilled about your current approach,
> that's what I was communicating. But that's what you have right now and there
> is no easy way to change it fast.
ilya-biryukov wrote:
Many thanks for engaging in this discussion and sorry for the delays in my
responses too.
https://github.com/llvm/llvm-project/pull/138227
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mail
ilya-biryukov wrote:
> In general, though, I share the same concern as @vsapsai about leaving this
> patch reverted for too long.
I have a concrete proposal to move forward, #141792. I have checked that the
failure we've seen in our infrastructure goes away with both changes applied.
Given t
ilya-biryukov wrote:
This change will fix the breakages we've had internally with #138227,
unblocking it.
https://github.com/llvm/llvm-project/pull/141792
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/l
https://github.com/ilya-biryukov created
https://github.com/llvm/llvm-project/pull/141792
Currently, Clang picks a module where the header is non-private even when the
header is textual and the other is modular. This change makes it prefer a
module where the header is modular instead. Access c
ilya-biryukov wrote:
> Can you clarify, are you saying this pattern of having a header in two
> different modules has to keep working indefinitely, or are you willing to
> migrate off of it?
> I don't understand what the reason is for the header to be in two different
> modules in the first pl
ilya-biryukov wrote:
Back to the original issue.
> I'm willing to help figure out how to achieve the desired result in a
> different way. But for that need to know what is the desired result.
We would need to example I shared above to keep working. We rely on an
optimization that picks a modu
ilya-biryukov wrote:
> Ok, I'm going to revert the change to help you out. But I'm going to re-land
> it in a week or when you are ready, whichever comes first.
>
> There was no indication there is anything wrong with the change or if the
> issue is wide-spread. And if a single company relies o
ilya-biryukov wrote:
> And I'm not sure such a use case is worth supporting.
> But I understand that is only my own interpretation which can be incorrect.
> And I want to believe you have a better use case that doesn't rely on
> accessing private headers
The code I shared compiles with no er
ilya-biryukov wrote:
> What is your timeframe for stopping putting the same header ("wrap_foo.h")
> into multiple modules? If you do that it was never guaranteed which module
> would be used for a header. I'm willing to unblock you but I'd like to know
> if you are committed to fixing the issu
ilya-biryukov wrote:
Here's a reproducer for our breakage:
```cpp
// RUN: rm -rf %t
// RUN: split-file %s %t
//
// First, build a module with a header.
//
// RUN: %clang_cc1 -fmodules -fmodule-map-file=%t/modules1.map -fmodule-name=a
-emit-module -xc++ -fmodules-embed-all-files -o %t/a.pcm %t/mo
ilya-biryukov wrote:
I can confirm that we routinely rely on the same header being part of multiple
modules and results of that being combined in all kinds of ways imaginable.
Moreover, the same header can be a modular header in some modules, textual in
others and the resulting PCMs may also b
@@ -1666,6 +1685,21 @@ namespace {
return inherited::TransformTemplateArgument(Input, Output, Uneval);
}
+using TreeTransform::TransformTemplateSpecializationType;
+QualType
+TransformTemplateSpecializationType(TypeLocBuilder &TLB,
+
ilya-biryukov wrote:
> Because this isn't for correctness but is for performance, I think there
> isn't a pressing need to land something ASAP from the community perspective
> (or is the performance truly bad enough that you think the feature is not
> really usable without doing something?). S
@@ -6484,6 +6499,57 @@ class SubstTemplateTypeParmType final
}
};
+/// Represents the result of substituting a set of types as a template argument
+/// that needs to be expanded later.
+///
+/// These types are always dependent and produced depending on the situations:
+///
https://github.com/ilya-biryukov edited
https://github.com/llvm/llvm-project/pull/106730
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ilya-biryukov edited
https://github.com/llvm/llvm-project/pull/106730
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1666,6 +1685,21 @@ namespace {
return inherited::TransformTemplateArgument(Input, Output, Uneval);
}
+using TreeTransform::TransformTemplateSpecializationType;
+QualType
+TransformTemplateSpecializationType(TypeLocBuilder &TLB,
+
@@ -5054,95 +5089,128 @@ bool
TreeTransform::TransformTemplateArguments(
}
if (In.getArgument().isPackExpansion()) {
- // We have a pack expansion, for which we will be substituting into
- // the pattern.
- SourceLocation Ellipsis;
- UnsignedOrNone
https://github.com/ilya-biryukov created
https://github.com/llvm/llvm-project/pull/139730
Deduplicating types via standard C++ can be a huge compile-time hog, we have
observed that on some of the large targets we have internally this can be up to
25%.
This builtin can be used to improve compi
ilya-biryukov wrote:
Note to people reviewing this: please ensure you "hide whitespace" via `git
diff -w` or the corresponding setting on GitHub. For your own sanity when
looking at changes in `TreeTransform.h`, which are otherwise really complicated
to validate. I've deliberately kept the cod
https://github.com/ilya-biryukov updated
https://github.com/llvm/llvm-project/pull/106730
>From e2d345d490d73f46d969b9a5945d9bfe11e148f9 Mon Sep 17 00:00:00 2001
From: Ilya Biryukov
Date: Fri, 23 Aug 2024 17:27:26 +0200
Subject: [PATCH 1/2] [Clang] Add builtins that deduplicate and sort types
https://github.com/ilya-biryukov edited
https://github.com/llvm/llvm-project/pull/106730
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ilya-biryukov wrote:
This is a simple initial version of a builtin in #106730 that does **not**
introduce new kind of packs that can be produced by builtins rather than
variadic template parameters and instead relies on features already available
in C++.
This makes the implementation much sim
ilya-biryukov wrote:
I have made quite a bit of progress here, but we also need the deduplication
builting urgently to help ease the pain for
some of the big compilations that started hitting our infrastructure limits
internally.
I have created #139730 with the initial and simple version of th
https://github.com/ilya-biryukov approved this pull request.
Approving to land this and unblock our internal releases.
Obviously, I encourage to address the issues raised by other reviewers in the
follow-ups.
In particular, the most easily actionable one is about the naming of the getter
from
@@ -3602,6 +3602,10 @@ class MemberPointerType : public Type, public
llvm::FoldingSetNode {
}
NestedNameSpecifier *getQualifier() const { return Qualifier; }
+ CXXRecordDecl *getCXXRecordDecl() const;
ilya-biryukov wrote:
Could you make this private for
@@ -3610,7 +3611,7 @@ class MemberPointerType : public Type, public
llvm::FoldingSetNode {
}
void Profile(llvm::FoldingSetNodeID &ID) {
-Profile(ID, getPointeeType(), getQualifier(),
getMostRecentCXXRecordDecl());
+Profile(ID, getPointeeType(), getQualifier(), ge
@@ -4522,6 +4523,38 @@ static CompleteObject findCompleteObject(EvalInfo &Info,
const Expr *E,
BaseVal = MTE->getOrCreateValue(false);
assert(BaseVal && "got reference to unevaluated temporary");
+ } else if (const CompoundLiteralExpr *CLE =
+
@@ -9125,9 +9126,25 @@ bool
LValueExprEvaluator::VisitCompoundLiteralExpr(const CompoundLiteralExpr *E) {
assert((!Info.getLangOpts().CPlusPlus || E->isFileScope()) &&
"lvalue compound literal in c++?");
- // Defer visiting the literal until the lvalue-to-rvalue con
ilya-biryukov wrote:
@kadircet and I have spent some time on this.
The `LValueExprEvaluator` decides to "defer" the evaluation of compound
literals to conversions, but does this in a way that assumes the evaluation
happens inside the same expression.
https://github.com/llvm/llvm-project/blob/
ilya-biryukov wrote:
@kadircet let's team up tomorrow and poke at what's happening with the smaller
reproducer to figure out if this is the right fix?
@AaronBallman I was initially concerned that it would be incorrect to consider
the compound literal expression a full expression even if it fix
https://github.com/ilya-biryukov updated
https://github.com/llvm/llvm-project/pull/132387
>From ef63166c24f7328af8177220be706a573d97009e Mon Sep 17 00:00:00 2001
From: Ilya Biryukov
Date: Fri, 21 Mar 2025 11:42:32 +0100
Subject: [PATCH 1/2] [NFC] [ASTMatchers] Share code of
`forEachArgumentWit
https://github.com/ilya-biryukov created
https://github.com/llvm/llvm-project/pull/134361
Fix #134356.
We accidentally skipped checking derived-to-base conversions because deduction
did not strip sugar in the relevant code. This caused deduction failures when a
parameter type had an attribute
https://github.com/ilya-biryukov created
https://github.com/llvm/llvm-project/pull/134228
Before this change the code used to add extra qualifiers, e.g.
`std::unique_ptr _Nonnull` became `::std::std::unique_ptr _Nonnull`
when adding a global namespace qualifier was requested.
>From 7edb987104cf
@@ -29096,6 +29096,17 @@ TEST_F(FormatTest, BreakBeforeClassName) {
"ArenaSafeUniquePtr {};");
}
+TEST_F(FormatTest, DoesNotCrashOnNonNullTerminatedStringRefs) {
+ llvm::StringRef TwoLines = "namespace foo {}\n"
+ "namespace bar
@@ -49,6 +51,135 @@ LLVM_INSTANTIATE_REGISTRY(FrontendPluginRegistry)
namespace {
+/// Dumps deserialized declarations.
+class DeserializedDeclsLineRangePrinter : public
DelegatingDeserializationListener, public ASTConsumer {
+public:
+ explicit DeserializedDeclsLineRangePr
https://github.com/ilya-biryukov edited
https://github.com/llvm/llvm-project/pull/133910
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,18 @@
+// RUN: %clang_cc1 -std=c++20 -Wno-ignored-attributes -Wno-unused-value
-verify %s
+// expected-no-diagnostics
+namespace std {
+template
+constexpr const T& as_const(T&) noexcept;
+
+// We need two declarations to see the error for some reason *shrug*
@@ -49,6 +51,135 @@ LLVM_INSTANTIATE_REGISTRY(FrontendPluginRegistry)
namespace {
+/// Dumps deserialized declarations.
ilya-biryukov wrote:
I still see the old version. Did the push succeed?
https://github.com/llvm/llvm-project/pull/133910
https://github.com/ilya-biryukov updated
https://github.com/llvm/llvm-project/pull/132387
>From ef63166c24f7328af8177220be706a573d97009e Mon Sep 17 00:00:00 2001
From: Ilya Biryukov
Date: Fri, 21 Mar 2025 11:42:32 +0100
Subject: [PATCH 1/3] [NFC] [ASTMatchers] Share code of
`forEachArgumentWit
https://github.com/ilya-biryukov approved this pull request.
https://github.com/llvm/llvm-project/pull/131997
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ilya-biryukov updated
https://github.com/llvm/llvm-project/pull/134228
>From 7edb987104cf59b106a1f13ae0bad0c5ecd4627b Mon Sep 17 00:00:00 2001
From: Ilya Biryukov
Date: Thu, 3 Apr 2025 12:22:39 +0200
Subject: [PATCH 1/3] [Tooling] Handle AttributedType in getFullyQualifiedTyp
@@ -49,6 +51,150 @@ LLVM_INSTANTIATE_REGISTRY(FrontendPluginRegistry)
namespace {
+/// DeserializedDeclsLineRangePrinter dumps ranges of deserialized declarations
+/// to aid debugging and bug minimization. It implements ASTConsumer and
+/// ASTDeserializationListener, so tha
https://github.com/ilya-biryukov closed
https://github.com/llvm/llvm-project/pull/132387
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -49,6 +51,150 @@ LLVM_INSTANTIATE_REGISTRY(FrontendPluginRegistry)
namespace {
+/// DeserializedDeclsLineRangePrinter dumps ranges of deserialized declarations
+/// to aid debugging and bug minimization. It implements ASTConsumer and
+/// ASTDeserializationListener, so tha
@@ -49,6 +51,150 @@ LLVM_INSTANTIATE_REGISTRY(FrontendPluginRegistry)
namespace {
+/// DeserializedDeclsLineRangePrinter dumps ranges of deserialized declarations
+/// to aid debugging and bug minimization. It implements ASTConsumer and
+/// ASTDeserializationListener, so tha
https://github.com/ilya-biryukov commented:
Thanks, the implementation mostly looks good. I've left a lot of comments, but
they are mostly NITs. One major thing that we need to change is the way we test
this, see the comment about relying on `jq`.
Another thought that crossed my mind is that w
https://github.com/ilya-biryukov edited
https://github.com/llvm/llvm-project/pull/133910
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -49,6 +51,150 @@ LLVM_INSTANTIATE_REGISTRY(FrontendPluginRegistry)
namespace {
+/// DeserializedDeclsLineRangePrinter dumps ranges of deserialized declarations
+/// to aid debugging and bug minimization. It implements ASTConsumer and
+/// ASTDeserializationListener, so tha
@@ -49,6 +51,150 @@ LLVM_INSTANTIATE_REGISTRY(FrontendPluginRegistry)
namespace {
+/// DeserializedDeclsLineRangePrinter dumps ranges of deserialized declarations
+/// to aid debugging and bug minimization. It implements ASTConsumer and
+/// ASTDeserializationListener, so tha
@@ -121,6 +267,26 @@ FrontendAction::CreateWrappedASTConsumer(CompilerInstance
&CI,
if (!Consumer)
return nullptr;
+ std::vector> Consumers;
+ llvm::StringRef DumpDeserializedDeclarationRangesPath =
+ CI.getFrontendOpts().DumpDeserializedDeclarationRangesPath;
+
ilya-biryukov wrote:
Could you also update the PR description and change `[WIP]` to `[Clang]` in the
title so that we don't accidentally forget this before comitting?
https://github.com/llvm/llvm-project/pull/133910
___
cfe-commits mailing list
cfe-co
@@ -49,6 +51,150 @@ LLVM_INSTANTIATE_REGISTRY(FrontendPluginRegistry)
namespace {
+/// DeserializedDeclsLineRangePrinter dumps ranges of deserialized declarations
+/// to aid debugging and bug minimization. It implements ASTConsumer and
+/// ASTDeserializationListener, so tha
@@ -121,6 +267,26 @@ FrontendAction::CreateWrappedASTConsumer(CompilerInstance
&CI,
if (!Consumer)
return nullptr;
+ std::vector> Consumers;
ilya-biryukov wrote:
NIT: `llvm::SmallVector, 1> Consumers` is a good choice here
since we have 1 consumer m
@@ -49,6 +51,150 @@ LLVM_INSTANTIATE_REGISTRY(FrontendPluginRegistry)
namespace {
+/// DeserializedDeclsLineRangePrinter dumps ranges of deserialized declarations
+/// to aid debugging and bug minimization. It implements ASTConsumer and
+/// ASTDeserializationListener, so tha
@@ -49,6 +51,150 @@ LLVM_INSTANTIATE_REGISTRY(FrontendPluginRegistry)
namespace {
+/// DeserializedDeclsLineRangePrinter dumps ranges of deserialized declarations
+/// to aid debugging and bug minimization. It implements ASTConsumer and
+/// ASTDeserializationListener, so tha
@@ -49,6 +51,150 @@ LLVM_INSTANTIATE_REGISTRY(FrontendPluginRegistry)
namespace {
+/// DeserializedDeclsLineRangePrinter dumps ranges of deserialized declarations
+/// to aid debugging and bug minimization. It implements ASTConsumer and
+/// ASTDeserializationListener, so tha
@@ -49,6 +51,150 @@ LLVM_INSTANTIATE_REGISTRY(FrontendPluginRegistry)
namespace {
+/// DeserializedDeclsLineRangePrinter dumps ranges of deserialized declarations
+/// to aid debugging and bug minimization. It implements ASTConsumer and
+/// ASTDeserializationListener, so tha
@@ -49,6 +51,150 @@ LLVM_INSTANTIATE_REGISTRY(FrontendPluginRegistry)
namespace {
+/// DeserializedDeclsLineRangePrinter dumps ranges of deserialized declarations
+/// to aid debugging and bug minimization. It implements ASTConsumer and
+/// ASTDeserializationListener, so tha
@@ -49,6 +51,150 @@ LLVM_INSTANTIATE_REGISTRY(FrontendPluginRegistry)
namespace {
+/// DeserializedDeclsLineRangePrinter dumps ranges of deserialized declarations
+/// to aid debugging and bug minimization. It implements ASTConsumer and
+/// ASTDeserializationListener, so tha
@@ -49,6 +51,150 @@ LLVM_INSTANTIATE_REGISTRY(FrontendPluginRegistry)
namespace {
+/// DeserializedDeclsLineRangePrinter dumps ranges of deserialized declarations
+/// to aid debugging and bug minimization. It implements ASTConsumer and
+/// ASTDeserializationListener, so tha
https://github.com/ilya-biryukov closed
https://github.com/llvm/llvm-project/pull/134361
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ilya-biryukov wrote:
Friendly ping @AaronBallman to take a look.
And also add @usx95 to get another pair of eyes and faster review in case Aaron
is busy.
https://github.com/llvm/llvm-project/pull/132387
___
cfe-commits mailing list
cfe-commits@lists.l
@@ -139,16 +283,17 @@ FrontendAction::CreateWrappedASTConsumer(CompilerInstance
&CI,
return nullptr;
// If there are no registered plugins we don't need to wrap the consumer
- if (FrontendPluginRegistry::begin() == FrontendPluginRegistry::end())
-return Consumer;
+
@@ -139,16 +283,17 @@ FrontendAction::CreateWrappedASTConsumer(CompilerInstance
&CI,
return nullptr;
// If there are no registered plugins we don't need to wrap the consumer
- if (FrontendPluginRegistry::begin() == FrontendPluginRegistry::end())
-return Consumer;
+
@@ -7968,6 +7968,10 @@ def print_dependency_directives_minimized_source :
Flag<["-"],
"print-dependency-directives-minimized-source">,
HelpText<"Print the output of the dependency directives source minimizer">;
}
+def print_deserialized_declarations : Joined<["-"],
+ "pri
https://github.com/ilya-biryukov closed
https://github.com/llvm/llvm-project/pull/134228
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ilya-biryukov updated
https://github.com/llvm/llvm-project/pull/134228
>From 7edb987104cf59b106a1f13ae0bad0c5ecd4627b Mon Sep 17 00:00:00 2001
From: Ilya Biryukov
Date: Thu, 3 Apr 2025 12:22:39 +0200
Subject: [PATCH 1/2] [Tooling] Handle AttributedType in getFullyQualifiedTyp
@@ -139,16 +283,17 @@ FrontendAction::CreateWrappedASTConsumer(CompilerInstance
&CI,
return nullptr;
// If there are no registered plugins we don't need to wrap the consumer
- if (FrontendPluginRegistry::begin() == FrontendPluginRegistry::end())
-return Consumer;
+
https://github.com/ilya-biryukov requested changes to this pull request.
Thanks, this looks like a good start! I have left a few comments and also feel
there are a few things missing:
- basic tests
- the code registering deserialization listener
- suggestion: a commit message could benefit from
@@ -49,6 +51,135 @@ LLVM_INSTANTIATE_REGISTRY(FrontendPluginRegistry)
namespace {
+/// Dumps deserialized declarations.
+class DeserializedDeclsLineRangePrinter : public
DelegatingDeserializationListener, public ASTConsumer {
+public:
+ explicit DeserializedDeclsLineRangePr
@@ -7968,6 +7968,10 @@ def print_dependency_directives_minimized_source :
Flag<["-"],
"print-dependency-directives-minimized-source">,
HelpText<"Print the output of the dependency directives source minimizer">;
}
+def print_deserialized_declarations : Joined<["-"],
+ "pri
@@ -49,6 +51,135 @@ LLVM_INSTANTIATE_REGISTRY(FrontendPluginRegistry)
namespace {
+/// Dumps deserialized declarations.
ilya-biryukov wrote:
NIT: remove this comment as the class name already makes it clear what it's
doing.
If you want, you might use a com
@@ -7968,6 +7968,10 @@ def print_dependency_directives_minimized_source :
Flag<["-"],
"print-dependency-directives-minimized-source">,
HelpText<"Print the output of the dependency directives source minimizer">;
}
+def print_deserialized_declarations : Joined<["-"],
+ "pri
@@ -121,6 +252,19 @@ FrontendAction::CreateWrappedASTConsumer(CompilerInstance
&CI,
if (!Consumer)
return nullptr;
+ std::vector> Consumers;
+ llvm::StringRef PrintDeserializedDeclarationsPath =
CI.getFrontendOpts().PrintDeserializedDeclarationsPath;
+ if (!PrintDes
@@ -121,6 +252,19 @@ FrontendAction::CreateWrappedASTConsumer(CompilerInstance
&CI,
if (!Consumer)
return nullptr;
+ std::vector> Consumers;
+ llvm::StringRef PrintDeserializedDeclarationsPath =
CI.getFrontendOpts().PrintDeserializedDeclarationsPath;
+ if (!PrintDes
@@ -57,6 +59,8 @@ class ASTDeserializationListener {
/// A module import was read from the AST file.
virtual void ModuleImportRead(serialization::SubmoduleID ID,
SourceLocation ImportLoc) {}
+ /// The deserialization of the AST file was fini
ilya-biryukov wrote:
The small-scale benchmarks we had show 10% improvement in CPU and 23%
improvement in memory usage for some compilations!
We did hit one compiler error that does not reproduce without modules, however:
```error: use of overloaded operator '=' is ambiguous```
We're in the pr
https://github.com/ilya-biryukov approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/133424
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ilya-biryukov wrote:
> I'm happy to split the patch. I agree that (2) requires more thought and
> careful consideration. I'm not sure I'll have time to finish it before my
> leave, so I might have to leave it to you. But I can take care of (1).
Yeah, I feel it makes sense to abandon this until
@@ -103,15 +120,30 @@ class DeserializedDeclsDumper : public
DelegatingDeserializationListener {
: DelegatingDeserializationListener(Previous, DeletePrevious) {}
void DeclRead(GlobalDeclID ID, const Decl *D) override {
-llvm::outs() << "PCH DECL: " << D->getDeclKi
@@ -57,6 +59,8 @@ class ASTDeserializationListener {
/// A module import was read from the AST file.
virtual void ModuleImportRead(serialization::SubmoduleID ID,
SourceLocation ImportLoc) {}
+ /// The deserialization of the AST file was fini
@@ -27,6 +27,8 @@ class MacroInfo;
class Module;
class SourceLocation;
+// IMPORTANT: when you add a new interface to this class, please update the
+// DelegatingDeserializationListener in FrontendAction.cpp
ilya-biryukov wrote:
Future idea: maybe we could mo
1 - 100 of 1456 matches
Mail list logo
