ilya-biryukov wrote:
I have spent some time poking at the code and looking at the debugger and came
up with a smaller repro, see https://gcc.godbolt.org/z/6ccPPd6hz:
```cpp
int bar(...);
template struct Int {};
template
constexpr auto foo(T... x) -> decltype(bar(T(x)...)) { return 1; }
temp
@@ -181,9 +187,18 @@ class TimeTraceScope {
Entry = timeTraceProfilerBegin(Name, Detail);
}
TimeTraceScope(StringRef Name,
ilya-biryukov wrote:
We should not use the `TimeTraceScope` for instant events at all.
It does not make much sense to deal with
ilya-biryukov wrote:
@ian-twilightcoder this change seemed to cause our internal builds to run out
of source location space.
```
remark: source manager location address space usage: [-Rsloc-usage]
note: 408559B in local locations, 2146921126B in locations loaded from AST
files, for a total of 2
ilya-biryukov wrote:
It's definitely caused by that change, reverting it fixes the failure.
We use module maps so that some of our `#include` get processed as `#import`, I
believe the same code gets executed for our use-case. Because our setup is so
unusual, producing a repro is hard and make
ilya-biryukov wrote:
Most of the increase seems to be coming from module maps that describe textual
headers:
```
// This describes builtin headers.
Before: gen-crosstool-x86.cppmap:1:1: note: file entered 630 times using
83989080B of space
After: gen-crosstool-x86.cppmap:1:1: note: file entered
https://github.com/ilya-biryukov edited
https://github.com/llvm/llvm-project/pull/88381
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -451,6 +451,7 @@ ParsedAST::build(llvm::StringRef Filename, const
ParseInputs &Inputs,
DiagnosticConsumer *DiagConsumer = &ASTDiags;
IgnoreDiagnostics DropDiags;
if (Preamble) {
+CI->TargetOpts = Preamble->TargetOpts;
Patch = PreamblePatch::createFullPatch(Fi
@@ -451,6 +451,7 @@ ParsedAST::build(llvm::StringRef Filename, const
ParseInputs &Inputs,
DiagnosticConsumer *DiagConsumer = &ASTDiags;
IgnoreDiagnostics DropDiags;
if (Preamble) {
+CI->TargetOpts = Preamble->TargetOpts;
ilya-biryukov wrote:
It'd be
https://github.com/ilya-biryukov commented:
Just to confirm I understand the broader context: we only need it when building
the AST because the rest of the code (completions, signature help) actually
already uses a compile command and FS from preamble inputs, right
https://github.com/llvm/llvm
@@ -768,6 +764,35 @@ TEST(ParsedASTTest, GracefulFailureOnAssemblyFile) {
<< "Should not try to build AST for assembly source file";
}
+TEST(ParsedASTTest, PreambleWithDifferentTarget) {
+ constexpr std::string_view kPreambleTarget = "x86_64";
ilya-biry
https://github.com/ilya-biryukov edited
https://github.com/llvm/llvm-project/pull/88381
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ilya-biryukov wrote:
> Are your `textual` headers meant to be included more than once? If not, do
> they use header guards or `#pragma once`?
As I mentioned, the increase is coming from the module files.
The textual headers are header-guarded and not intended to be included more
than once.
>
ilya-biryukov wrote:
I still don't understand why the number of `FileID`s for module maps has
increased so much. I am observing this increase when compiling a file that has
many module dependencies, it creates only one `FileID` for a module map I
mentioned above, the rest 2259 are from loaded
ilya-biryukov wrote:
The 10x increase in the time spent reading modules does look surprising and I
would need to check if it's related to PCMs becoming larger or is localized to
that particular compile. (Even if on a single example).
@ChuanqiXu9 do you expect alignment to have such a drastic e
ilya-biryukov wrote:
To clarify: we observe this regression on x86, not on Arm. @alexfh is now
trying to profile the compiler to locate what's going wrong and I will try to
poke at PCM files and come up with a reproducer.
However, the regressions is definitely real and will block our internal
ilya-biryukov wrote:
I added a printf into `FindExternalVisibleDeclsByName` where it calls find on
`MultiOnDiskHashTable` to see what names have been causing this and I can see
that we stall on the first name we try to look up. The name `std` is the first
one and was previously processed almos
ilya-biryukov wrote:
In both cases we are condensing `1105` on-disk hash tables, but it took seconds
before and takes multiple minutes after the change.
https://github.com/llvm/llvm-project/pull/92083
___
cfe-commits mailing list
cfe-commits@lists.llv
ilya-biryukov wrote:
I only managed to confirm that the problem is that merging of individual PCMs
into a merged hash table has become much slower with this change.
I tried with #95348 too, but it didn't help.
I will continue my investigations and reductions tomorrow.
https://github.com/llvm/l
ilya-biryukov wrote:
While this looks like a useful optimization, I am still not sure why 2x more
data (is that a correct upper bound?) can lead to a 10x slowdown. I will try to
dig further to understand what's going on here.
https://github.com/llvm/llvm-project/pull/92083
ilya-biryukov wrote:
I got to the bottom of it. The problem is that our hash function for 64 bit
ints is [not very
good](https://github.com/llvm/llvm-project/blob/d5297b72aa32ad3a69563a1fcc61294282f0b379/llvm/include/llvm/ADT/DenseMapInfo.h#L140).
It will have a lot of collision when lower 32
ilya-biryukov wrote:
Oh, I didn't realize you were eager to land this in Clang 19, thanks for
sharing that.
In that case, I think a specialiazed hash function for `GlobalDeclID` is indeed
the way to go.
I was also worried a little there are other performance implications of this
change that w
@@ -230,7 +230,11 @@ template <> struct DenseMapInfo {
}
static unsigned getHashValue(const GlobalDeclID &Key) {
-return DenseMapInfo::getHashValue(Key.get());
+// Our default hash algorithm for 64 bits integer may not be very good.
+// In GlobalDeclID's case,
https://github.com/ilya-biryukov edited
https://github.com/llvm/llvm-project/pull/95730
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -230,7 +230,11 @@ template <> struct DenseMapInfo {
}
static unsigned getHashValue(const GlobalDeclID &Key) {
-return DenseMapInfo::getHashValue(Key.get());
+// Our default hash algorithm for 64 bits integer may not be very good.
ilya-biryukov w
ilya-biryukov wrote:
@ChuanqiXu9 are you still planning to chase this given that fixing the hashing
function would fix performance for the aforementioned patch?
The trade-off we are making here is hard to assess without benchmarks that show
how much latency we win and how much more memory we s
https://github.com/ilya-biryukov approved this pull request.
LGTM, thanks!
https://github.com/llvm/llvm-project/pull/95730
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ilya-biryukov commented:
Looks from the C++ language rules and compiler frontend perspective.
The logic behinds the checks seems solid, there should not be any uncaught
reads.
I am still unsure if we are doing the right thing for Objective C's `-fblocks`,
left a comment aski
https://github.com/ilya-biryukov edited
https://github.com/llvm/llvm-project/pull/94642
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1972,7 +1972,20 @@ void CodeGenFunction::EmitAutoVarInit(const
AutoVarEmission &emission) {
}
if (!constant) {
-initializeWhatIsTechnicallyUninitialized(Loc);
+if (trivialAutoVarInit !=
+LangOptions::TrivialAutoVarInitKind::Uninitialized) {
+ // A
@@ -1972,7 +1972,20 @@ void CodeGenFunction::EmitAutoVarInit(const
AutoVarEmission &emission) {
}
if (!constant) {
-initializeWhatIsTechnicallyUninitialized(Loc);
+if (trivialAutoVarInit !=
+LangOptions::TrivialAutoVarInitKind::Uninitialized) {
+ // A
https://github.com/ilya-biryukov approved this pull request.
https://github.com/llvm/llvm-project/pull/94642
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ilya-biryukov wrote:
LGTM!
https://github.com/llvm/llvm-project/pull/94642
___
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/92511
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -44,10 +44,6 @@ export inline int getA() {
return 43;
}
-export inline int getA2(int) {
ilya-biryukov wrote:
I am not sure why we update the tests here. Could you clarify this, maybe in
the final commit description too?
(I suspect something along the
@@ -3262,17 +3262,18 @@ void ASTWriter::WritePragmaDiagnosticMappings(const
DiagnosticsEngine &Diag,
/// Write the representation of a type to the AST stream.
void ASTWriter::WriteType(QualType T) {
TypeIdx &IdxRef = TypeIdxs[T];
- if (IdxRef.getIndex() == 0) // we haven't
https://github.com/ilya-biryukov commented:
Thanks! With all the explanation, the patch makes a lot of sense.
Generally LG, I just have a few more NITs and feel it's good to go.
I am surprised to hear we have less TypeIDs than DeclIDs. My mental model was
that for every type Decl we introduce,
@@ -6659,13 +6655,22 @@ void ASTWriter::MacroRead(serialization::MacroID ID,
MacroInfo *MI) {
}
void ASTWriter::TypeRead(TypeIdx Idx, QualType T) {
- // Always take the highest-numbered type index. This copes with an
interesting
+ // Always take the type index that comes i
@@ -70,38 +71,51 @@ using DeclID = DeclIDBase::DeclID;
/// An ID number that refers to a type in an AST file.
///
-/// The ID of a type is partitioned into two parts: the lower
-/// three bits are used to store the const/volatile/restrict
-/// qualifiers (as with QualType) and
@@ -7392,27 +7388,28 @@ QualType ASTReader::GetType(TypeID ID) {
return TypesLoaded[Index].withFastQualifiers(FastQuals);
}
-QualType ASTReader::getLocalType(ModuleFile &F, unsigned LocalID) {
+QualType ASTReader::getLocalType(ModuleFile &F, TypeID LocalID) {
---
@@ -70,38 +71,51 @@ using DeclID = DeclIDBase::DeclID;
/// An ID number that refers to a type in an AST file.
///
-/// The ID of a type is partitioned into two parts: the lower
-/// three bits are used to store the const/volatile/restrict
-/// qualifiers (as with QualType) and
@@ -7151,15 +7135,45 @@ TypeSourceInfo *ASTRecordReader::readTypeSourceInfo() {
return TInfo;
}
+static unsigned getIndexForTypeID(serialization::TypeID ID) {
+ return (ID & llvm::maskTrailingOnes(32)) >> Qualifiers::FastWidth;
+ ;
ilya-biryukov wrote:
NI
@@ -7151,15 +7135,45 @@ TypeSourceInfo *ASTRecordReader::readTypeSourceInfo() {
return TInfo;
}
+static unsigned getIndexForTypeID(serialization::TypeID ID) {
+ return (ID & llvm::maskTrailingOnes(32)) >> Qualifiers::FastWidth;
+ ;
+}
+
+static unsigned getModuleFileIndexF
@@ -0,0 +1,68 @@
+// Testing that changing a type in an unused module file won't change
+// the BMI of the current module file.
+//
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+//
+// RUN: %clang_cc1 -std=c++20 %t/m-partA.cppm -emit-reduced-module-interface
-o %t/m-partA.pcm
+/
@@ -7100,14 +7084,25 @@ TypeSourceInfo *ASTRecordReader::readTypeSourceInfo() {
return TInfo;
}
+std::pair
+ASTReader::translateTypeIDToIndex(serialization::TypeID ID) const {
+ unsigned Index =
+ (ID & llvm::maskTrailingOnes(32)) >> Qualifiers::FastWidth;
+
+ ModuleF
@@ -0,0 +1,68 @@
+// Testing that changing a type in an unused module file won't change
+// the BMI of the current module file.
+//
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+//
+// RUN: %clang_cc1 -std=c++20 %t/m-partA.cppm -emit-reduced-module-interface
-o %t/m-partA.pcm
+/
@@ -44,10 +44,6 @@ export inline int getA() {
return 43;
}
-export inline int getA2(int) {
ilya-biryukov wrote:
Makes sense, thanks for the explanation. +1 to making the test code simpler.
https://github.com/llvm/llvm-project/pull/92511
_
https://github.com/ilya-biryukov approved this pull request.
Thanks! The thing with the types does make sense now, I am (expectedly) just
bad at statistical reasoning. It does make sense that there are many
declarations that share the types. I suspect we won't see any significant
increases in
ilya-biryukov wrote:
> Yeah, I think this patch may be conceptually good except the extra memory
> using. But benchmarking, I tried it locally but didn't find observable
> effects. So I'd like to land this after 19's branching to give it more baking
> time.
Do you mean that no large increases
https://github.com/ilya-biryukov created
https://github.com/llvm/llvm-project/pull/96292
We have been running into source location exhaustion recently and want to use
the statistics to monitor the usage in various files to be able to anticipate
where the next problem will happen.
I picked `St
ilya-biryukov wrote:
cc @aeubanks @jyknight
https://github.com/llvm/llvm-project/pull/96292
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ilya-biryukov requested changes to this pull request.
Could we rewrite the description and documentation to capture what the type
trait is doing now?
We have a lot of references to the `is_trivially_copyable`, which is almost
fully irrelevant to the current implementation.
https://github.com/ilya-biryukov edited
https://github.com/llvm/llvm-project/pull/86512
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1120,6 +1120,14 @@ class QualType {
/// Return true if this is a trivially copyable type (C++0x [basic.types]p9)
bool isTriviallyCopyableType(const ASTContext &Context) const;
+ /// Return true if the type is safe to bitwise copy by memcpy.
+ ///
+ /// This is an ex
@@ -2749,6 +2749,17 @@ bool QualType::isTriviallyCopyableType(const ASTContext
&Context) const {
/*IsCopyConstructible=*/false);
}
+bool QualType::isBitwiseCloneableType(const ASTContext & Context) const {
+ if (const auto *RD = getCanoni
@@ -4016,6 +4016,34 @@ Note that the `size` argument must be a compile time
constant.
Note that this intrinsic cannot yet be called in a ``constexpr`` context.
+``__is_bitwise_cloneable``
+--
+
+A type trait is used to check whether a type can be safe
https://github.com/ilya-biryukov updated
https://github.com/llvm/llvm-project/pull/79875
>From 6e474e393e63fd1cb5f3b0bea3c971b96591c57f Mon Sep 17 00:00:00 2001
From: Ilya Biryukov
Date: Mon, 29 Jan 2024 18:55:53 +0100
Subject: [PATCH 1/3] [Serialization] Check for stack exhaustion when reading
@@ -4099,7 +4099,9 @@ Decl *ASTReader::ReadDeclRecord(DeclID ID) {
// calls to Decl::getASTContext() by Decl's methods will find the
// TranslationUnitDecl without crashing.
D->setDeclContext(Context.getTranslationUnitDecl());
- Reader.Visit(D);
+
+ // Reading some decl
ilya-biryukov wrote:
> Yeah, I was hoping to have it in the text of the discussion here without
> having to do it myself since you've already got the repro locally,
> presumably... so we can all see/discuss it. But perhaps it's not sufficiently
> helpful/constructive to worry about - not sure.
ilya-biryukov wrote:
> there's a couple of tests that use `ulimit`
> (`clang/test/SemaCXX/PR51712-large-array-constexpr-check-oom.cpp` and
> `clang/test/PCH/leakfiles.test`) - so that technique could be used to test
> this in a way that's fast enough to check in?
oh, I didn't realize I can us
https://github.com/ilya-biryukov edited
https://github.com/llvm/llvm-project/pull/86512
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ilya-biryukov approved this pull request.
LGTM with a few NITs to fix before submitting.
https://github.com/llvm/llvm-project/pull/86512
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/l
@@ -1120,6 +1120,22 @@ class QualType {
/// Return true if this is a trivially copyable type (C++0x [basic.types]p9)
bool isTriviallyCopyableType(const ASTContext &Context) const;
+ /// Return true if the type is safe to bitwise copy using memcpy/memmove.
+ ///
+ /// Th
@@ -4016,6 +4016,34 @@ Note that the `size` argument must be a compile time
constant.
Note that this intrinsic cannot yet be called in a ``constexpr`` context.
+``__is_bitwise_cloneable``
+--
+
+A type trait is used to check whether a type can be safe
@@ -2749,6 +2749,41 @@ bool QualType::isTriviallyCopyableType(const ASTContext
&Context) const {
/*IsCopyConstructible=*/false);
}
+bool QualType::isBitwiseCloneableType(const ASTContext & Context) const {
+ auto CanonicalType = getCanoni
ilya-biryukov wrote:
Also, we need to fix formatting errors and make sure the CI is green.
E.g. the newly added test fails (needs an update to capture some notes).
https://github.com/llvm/llvm-project/pull/86512
___
cfe-commits mailing list
cfe-commits
@@ -9403,6 +9404,20 @@ DiagnosticBuilder ASTReader::Diag(SourceLocation Loc,
unsigned DiagID) const {
return Diags.Report(Loc, DiagID);
}
+void ASTReader::warnStackExhausted(SourceLocation Loc) {
+ // When Sema is available, avoid duplicate errors. This should be rare.
---
https://github.com/ilya-biryukov updated
https://github.com/llvm/llvm-project/pull/79875
>From 6e474e393e63fd1cb5f3b0bea3c971b96591c57f Mon Sep 17 00:00:00 2001
From: Ilya Biryukov
Date: Mon, 29 Jan 2024 18:55:53 +0100
Subject: [PATCH 1/4] [Serialization] Check for stack exhaustion when reading
ilya-biryukov wrote:
I have tried `ulimit` and found that Clang relies on a very intricate balance
between the stack size, the desired stack size (the cutoff at which we create a
new thread with a larger stack) and the points in code where we call
`runWithSufficientStackSpace`.
If the stack l
https://github.com/ilya-biryukov updated
https://github.com/llvm/llvm-project/pull/79875
>From db8b091568c924a9550052ea643f718ac11d3e73 Mon Sep 17 00:00:00 2001
From: Ilya Biryukov
Date: Mon, 29 Jan 2024 18:55:53 +0100
Subject: [PATCH 1/4] [Serialization] Check for stack exhaustion when reading
https://github.com/ilya-biryukov closed
https://github.com/llvm/llvm-project/pull/79875
___
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/88893
If the same module map is passed to multiple compilation actions that build
PCMs and later load them, we currently create a new FileID for it every time a
PCM gets built.
This is not very problematic in t
https://github.com/ilya-biryukov edited
https://github.com/llvm/llvm-project/pull/88893
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ilya-biryukov wrote:
> Have you tried changing the behavior of the existing `-fmodule-map-file=` to
> load the file after we load module files? If so, what kinds of things do you
> see breaking or changing? If we can avoid it, I think it would be better to
> only have a single mode here, and l
ilya-biryukov wrote:
There's quite a few failures:
https://gist.github.com/ilya-biryukov/380d84dfe53f839f449231eb9a2dd46c
The logic that sets up module structure from module maps before starting to
load PCMs definitely needs to be reworked (and I'm not sure if it can be in the
first place). I
@@ -112,7 +112,10 @@ struct UpdateIndexCallbacks : public ParsingCallbacks {
// Index outlives TUScheduler (declared first)
FIndex(FIndex),
// shared_ptr extends lifetime
- Stdlib(Stdlib)]() mutable {
+
ilya-biryukov wrote:
All good from my side, but asked @sam-mccall or @usx95 to check the context
propagation bit as I'm missing context to make sure it's correct.
https://github.com/llvm/llvm-project/pull/88381
___
cfe-commits mailing list
cfe-commits
ilya-biryukov wrote:
> @ilya-biryukov can you check that this fixes your running out of source
> location space problem please?
Just tried it. The patch as is did not help.
I've also tried changing the previous line to `getExistingFileInfo(,
/*WantExternal=*/false)` and it didn't help either.
https://github.com/ilya-biryukov edited
https://github.com/llvm/llvm-project/pull/88381
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Ilya Biryukov
Date: 2024-07-23T12:28:59+02:00
New Revision: 363e036ac002d5af4bb82e303052b806a98086a1
URL:
https://github.com/llvm/llvm-project/commit/363e036ac002d5af4bb82e303052b806a98086a1
DIFF:
https://github.com/llvm/llvm-project/commit/363e036ac002d5af4bb82e303052b806a98086a1.diff
https://github.com/ilya-biryukov updated
https://github.com/llvm/llvm-project/pull/99880
>From ad2d2f42282d5493761fa0af13b77dc7aab73bba Mon Sep 17 00:00:00 2001
From: Ilya Biryukov
Date: Mon, 22 Jul 2024 15:19:07 +0200
Subject: [PATCH 1/2] [Sema] Default arguments for template parameters affect
@@ -61,27 +61,43 @@ TemplateParameterList::TemplateParameterList(const
ASTContext& C,
bool IsPack = P->isTemplateParameterPack();
if (const auto *NTTP = dyn_cast(P)) {
- if (!IsPack && NTTP->getType()->containsUnexpandedParameterPack())
-ContainsUnexpande
@@ -61,27 +61,43 @@ TemplateParameterList::TemplateParameterList(const
ASTContext& C,
bool IsPack = P->isTemplateParameterPack();
if (const auto *NTTP = dyn_cast(P)) {
- if (!IsPack && NTTP->getType()->containsUnexpandedParameterPack())
-ContainsUnexpande
https://github.com/ilya-biryukov updated
https://github.com/llvm/llvm-project/pull/99880
>From ad2d2f42282d5493761fa0af13b77dc7aab73bba Mon Sep 17 00:00:00 2001
From: Ilya Biryukov
Date: Mon, 22 Jul 2024 15:19:07 +0200
Subject: [PATCH 1/3] [Sema] Default arguments for template parameters affect
ilya-biryukov wrote:
> @ilya-biryukov I'm a bit torn about how we would proceed: if Corentin insists
> on the current (which my patch continues the effort) implementation, do you
> think it feasible for me to merge part of your codes (specifically, the way
> we propagate up unexpanded flags fo
https://github.com/ilya-biryukov updated
https://github.com/llvm/llvm-project/pull/99880
>From ad2d2f42282d5493761fa0af13b77dc7aab73bba Mon Sep 17 00:00:00 2001
From: Ilya Biryukov
Date: Mon, 22 Jul 2024 15:19:07 +0200
Subject: [PATCH 1/4] [Sema] Default arguments for template parameters affect
@@ -61,27 +68,34 @@ TemplateParameterList::TemplateParameterList(const
ASTContext& C,
bool IsPack = P->isTemplateParameterPack();
if (const auto *NTTP = dyn_cast(P)) {
- if (!IsPack && NTTP->getType()->containsUnexpandedParameterPack())
-ContainsUnexpande
https://github.com/ilya-biryukov closed
https://github.com/llvm/llvm-project/pull/99882
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ilya-biryukov wrote:
> My main concern is this line which seems very artificial
> https://github.com/llvm/llvm-project/pull/99882/files#diff-10901a3bb08d903a57820f09c2eb5f40cb4cd47c54ca3cad472106814c4bf15dR359
Yeah, I can see your point. My north-start vision for that issue is that is
should a
ilya-biryukov wrote:
I am generally supportive of the idea to expose this for more easily
reproducing bugs in source tools, and clangd, in particular.
However, I think it'd be useful to make sure the Clang maintainers are on board.
@cor3ntin, @AaronBallman do you have any objection to exposing
@@ -0,0 +1,8 @@
+// Trivial check to ensure skip-function-bodies flag is propagated.
+//
+// RUN: %clang_cc1 -verify -skip-function-bodies -pedantic-errors %s
ilya-biryukov wrote:
Could you also check in the test that this flag is not available outside of
`-cc1`
https://github.com/ilya-biryukov edited
https://github.com/llvm/llvm-project/pull/100135
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ilya-biryukov commented:
Let's give other folks a chance to reply before landing this.
https://github.com/llvm/llvm-project/pull/100135
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/li
ilya-biryukov wrote:
Could you reformat the code so that the clang-format presubmit is happy?
Otherwise LG.
https://github.com/llvm/llvm-project/pull/100124
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/
https://github.com/ilya-biryukov created
https://github.com/llvm/llvm-project/pull/100144
Not for submission yet. Will eventually aim to fix #100095. The current
approach should not be correct as it would have *too* much sugar in turn. We
should also make sure the final substitution arguments
@@ -688,10 +688,7 @@ DeduceTemplateSpecArguments(Sema &S, TemplateParameterList
*TemplateParams,
// FIXME: To preserve sugar, the TST needs to carry sugared resolved
// arguments.
- ArrayRef PResolved =
- TP->getCanonicalTypeInternal()
- ->castAs()
-
https://github.com/ilya-biryukov edited
https://github.com/llvm/llvm-project/pull/100144
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ilya-biryukov wrote:
> This would be excellent, but I think we would still need that just because
> building a lambda is an horrible state machine.
Yeah, unfortunately there probably isn't a way to get rid of the state machine.
I can only see a path towards getting rid of that single flag. But
@@ -44,6 +44,13 @@ using namespace clang;
// TemplateParameterList Implementation
//===--===//
+namespace {
+template
+bool DefaultArgumentContainsUnexpandedPack(const TemplateParam &P) {
il
https://github.com/ilya-biryukov updated
https://github.com/llvm/llvm-project/pull/99880
>From ad2d2f42282d5493761fa0af13b77dc7aab73bba Mon Sep 17 00:00:00 2001
From: Ilya Biryukov
Date: Mon, 22 Jul 2024 15:19:07 +0200
Subject: [PATCH 1/5] [Sema] Default arguments for template parameters affect
https://github.com/ilya-biryukov updated
https://github.com/llvm/llvm-project/pull/99880
>From ad2d2f42282d5493761fa0af13b77dc7aab73bba Mon Sep 17 00:00:00 2001
From: Ilya Biryukov
Date: Mon, 22 Jul 2024 15:19:07 +0200
Subject: [PATCH 1/5] [Sema] Default arguments for template parameters affect
801 - 900 of 1434 matches
Mail list logo
