@@ -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
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
@@ -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
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
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
@@ -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
ilya-biryukov wrote:
> I'm currently dealing with downstream conflicts with your previous patch.
> Please do not merge this PR this week, otherwise it may slow down our CI.
> Thanks!
Sure! There is no urgency in landing this.
Please let me know when it'd be a good time to land this.
@AaronBa
ilya-biryukov wrote:
> Can you add a reproducer?
I'm not sure I can do better than the test I've added.
My colleague caught this by accidentally getting an assertion failure when
using this API downstream.
The test illustrates how it got used and I'm not sure if `clang-format` binary
or any ot
https://github.com/ilya-biryukov updated
https://github.com/llvm/llvm-project/pull/131299
>From 1acb9b0717c0f55e59abca104bbb710375a67610 Mon Sep 17 00:00:00 2001
From: Ilya Biryukov
Date: Fri, 14 Mar 2025 10:53:09 +0100
Subject: [PATCH 1/3] [Format] Do not crash on non-null terminated strings
@@ -29096,6 +29096,17 @@ TEST_F(FormatTest, BreakBeforeClassName) {
"ArenaSafeUniquePtr {};");
}
+TEST_F(FormatTest, DoesNotCrashOnNonNullTerminatedStringRefs) {
+ llvm::StringRef TwoLines = "namespace foo {}\n"
ilya-biryukov wrote:
Done.
@@ -29096,6 +29096,17 @@ TEST_F(FormatTest, BreakBeforeClassName) {
"ArenaSafeUniquePtr {};");
}
+TEST_F(FormatTest, DoesNotCrashOnNonNullTerminatedStringRefs) {
+ llvm::StringRef TwoLines = "namespace foo {}\n"
+ "namespace bar
@@ -316,6 +316,7 @@ Bug Fixes in This Version
- Fixed a modules crash where exception specifications were not propagated
properly (#GH121245, relanded in #GH129982)
- Fixed a problematic case with recursive deserialization within
``FinishedDeserializing()`` where
``PassInte
https://github.com/ilya-biryukov requested changes to this pull request.
There are two parts to this patch:
1. forwarding more methods properly
2. updating the interface, adding new callbacks and changing the behavior of
`-dump-deserialized-decls``
I think (1) is a no-brainer. I would be very
@@ -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
https://github.com/ilya-biryukov edited
https://github.com/llvm/llvm-project/pull/133395
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -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
@@ -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
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
@@ -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
@@ -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
@@ -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
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
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
@@ -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
@@ -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;
+
@@ -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 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:
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
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
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
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
@@ -1666,6 +1685,21 @@ namespace {
return inherited::TransformTemplateArgument(Input, Output, Uneval);
}
+using TreeTransform::TransformTemplateSpecializationType;
+QualType
+TransformTemplateSpecializationType(TypeLocBuilder &TLB,
+
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
@@ -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 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,
+
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:
+///
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:
> 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:
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
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
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:
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
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:
> 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:
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:
> 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:
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
1401 - 1465 of 1465 matches
Mail list logo
