@@ -4381,11 +4381,13 @@ class PackIndexingExpr final
PackIndexingExpr(QualType Type, SourceLocation EllipsisLoc,
SourceLocation RSquareLoc, Expr *PackIdExpr, Expr
*IndexExpr,
- ArrayRef SubstitutedExprs = {})
+
@@ -7963,6 +7968,154 @@ static Attr *getCCTypeAttr(ASTContext , ParsedAttr
) {
llvm_unreachable("unexpected attribute kind!");
}
+std::optional
+Sema::ActOnEffectExpression(Expr *CondExpr, StringRef AttributeName) {
+ auto BadExpr = [&]() {
+
@@ -5028,3 +5060,263 @@ void AutoType::Profile(llvm::FoldingSetNodeID ,
const ASTContext ) {
Profile(ID, Context, getDeducedType(), getKeyword(), isDependentType(),
getTypeConstraintConcept(), getTypeConstraintArguments());
}
+
+FunctionEffect::Kind
@@ -7963,6 +7968,154 @@ static Attr *getCCTypeAttr(ASTContext , ParsedAttr
) {
llvm_unreachable("unexpected attribute kind!");
}
+std::optional
+Sema::ActOnEffectExpression(Expr *CondExpr, StringRef AttributeName) {
+ auto BadExpr = [&]() {
+
@@ -5028,3 +5060,263 @@ void AutoType::Profile(llvm::FoldingSetNodeID ,
const ASTContext ) {
Profile(ID, Context, getDeducedType(), getKeyword(), isDependentType(),
getTypeConstraintConcept(), getTypeConstraintArguments());
}
+
+FunctionEffect::Kind
@@ -4639,6 +4645,303 @@ class FunctionNoProtoType : public FunctionType, public
llvm::FoldingSetNode {
}
};
+//
--
+
+/// Represents an abstract function effect, using just an enumeration
@@ -3649,6 +3649,35 @@ FunctionProtoType::FunctionProtoType(QualType result,
ArrayRef params,
auto = *getTrailingObjects();
EllipsisLoc = epi.EllipsisLoc;
}
+
+ if (!epi.FunctionEffects.empty()) {
+auto = *getTrailingObjects();
+const size_t EffectsCount
@@ -2743,3 +2759,153 @@ bool Sema::isDeclaratorFunctionLike(Declarator ) {
});
return Result;
}
+
+FunctionEffectDifferences::FunctionEffectDifferences(
+const FunctionEffectsRef , const FunctionEffectsRef ) {
+
+ FunctionEffectsRef::iterator POld = Old.begin();
+
@@ -4639,6 +4645,303 @@ class FunctionNoProtoType : public FunctionType, public
llvm::FoldingSetNode {
}
};
+//
--
+
+/// Represents an abstract function effect, using just an enumeration
@@ -0,0 +1,134 @@
+// RUN: %clang_cc1 -fsyntax-only -fblocks -fcxx-exceptions -verify %s
+// RUN: %clang_cc1 -fsyntax-only -fblocks -verify -x c -std=c23 %s
+
+#if !__has_attribute(clang_nonblocking)
+#error "the 'nonblocking' attribute is not available"
+#endif
+
+// ---
@@ -4669,6 +4679,13 @@ class BlockDecl : public Decl, public DeclContext {
SourceRange getSourceRange() const override LLVM_READONLY;
+ FunctionEffectsRef getFunctionEffects() const {
+if (TypeSourceInfo *TSI = getSignatureAsWritten())
+ if (auto *FPT =
@@ -2743,3 +2759,153 @@ bool Sema::isDeclaratorFunctionLike(Declarator ) {
});
return Result;
}
+
+FunctionEffectDifferences::FunctionEffectDifferences(
+const FunctionEffectsRef , const FunctionEffectsRef ) {
+
+ FunctionEffectsRef::iterator POld = Old.begin();
+
@@ -1870,6 +1870,27 @@ bool Sema::IsFunctionConversion(QualType FromType,
QualType ToType,
FromFn = QT->getAs();
Changed = true;
}
+
+// For C, when called from checkPointerTypesForAssignment,
+// we need not to alter FromFn, or else even an innocuous
@@ -4639,6 +4645,303 @@ class FunctionNoProtoType : public FunctionType, public
llvm::FoldingSetNode {
}
};
+//
--
+
+/// Represents an abstract function effect, using just an enumeration
@@ -1870,6 +1870,28 @@ bool Sema::IsFunctionConversion(QualType FromType,
QualType ToType,
FromFn = QT->getAs();
Changed = true;
}
+
+// For C, when called from checkPointerTypesForAssignment,
+// we need not to alter FromFn, or else even an innocuous
@@ -0,0 +1,14 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -x c -std=c11 %s
AaronBallman wrote:
```suggestion
// RUN: %clang_cc1 -fsyntax-only -verify -std=c89 %s
```
https://github.com/llvm/llvm-project/pull/84983
@@ -5028,3 +5060,263 @@ void AutoType::Profile(llvm::FoldingSetNodeID ,
const ASTContext ) {
Profile(ID, Context, getDeducedType(), getKeyword(), isDependentType(),
getTypeConstraintConcept(), getTypeConstraintArguments());
}
+
+FunctionEffect::Kind
@@ -4639,6 +4645,303 @@ class FunctionNoProtoType : public FunctionType, public
llvm::FoldingSetNode {
}
};
+//
--
+
+/// Represents an abstract function effect, using just an enumeration
@@ -5028,3 +5060,263 @@ void AutoType::Profile(llvm::FoldingSetNodeID ,
const ASTContext ) {
Profile(ID, Context, getDeducedType(), getKeyword(), isDependentType(),
getTypeConstraintConcept(), getTypeConstraintArguments());
}
+
+FunctionEffect::Kind
@@ -5028,3 +5060,263 @@ void AutoType::Profile(llvm::FoldingSetNodeID ,
const ASTContext ) {
Profile(ID, Context, getDeducedType(), getKeyword(), isDependentType(),
getTypeConstraintConcept(), getTypeConstraintArguments());
}
+
+FunctionEffect::Kind
@@ -4639,6 +4645,303 @@ class FunctionNoProtoType : public FunctionType, public
llvm::FoldingSetNode {
}
};
+//
--
+
+/// Represents an abstract function effect, using just an enumeration
@@ -1435,6 +1435,38 @@ def CXX11NoReturn : InheritableAttr {
let Documentation = [CXX11NoReturnDocs];
}
+def NonBlocking : TypeAttr {
+ let Spellings = [CXX11<"clang", "nonblocking">,
AaronBallman wrote:
Generally speaking, these would use the `Clang`
https://github.com/AaronBallman approved this pull request.
The changes should come with a release note so that users know about the
behavioral change, but otherwise LGTM.
https://github.com/llvm/llvm-project/pull/90877
___
cfe-commits mailing list
@@ -14574,9 +14574,17 @@ bool FloatExprEvaluator::VisitCallExpr(const CallExpr
*E) {
default:
return false;
+ case Builtin::BI__builtin_frexpl:
+// AIX library function `frexpl` has 'long double' type and not
+// PPCDoubleDouble type. To make sure we generate
@@ -10698,7 +10698,7 @@ C++ defect report implementation
status
https://cplusplus.github.io/CWG/issues/1815.html;>1815
CD4
Lifetime extension in aggregate initialization
-Clang 19
+Yes
AaronBallman wrote:
It's usually better to apply the
@@ -45,6 +45,34 @@ void fallthrough(int n) {
#endif
}
+namespace cwg2428 { // cwg2428: 19
+#if __cplusplus >= 202002L
+template
+concept C [[deprecated]] = true; // #C
AaronBallman wrote:
I'd like an additional test for rejecting:
```
template
@@ -10698,7 +10698,7 @@ C++ defect report implementation
status
https://cplusplus.github.io/CWG/issues/1815.html;>1815
CD4
Lifetime extension in aggregate initialization
-Clang 19
+Yes
AaronBallman wrote:
Unrelated changes snuck in.
https://github.com/AaronBallman commented:
Please be sure to add a release note about implementing the DR.
https://github.com/llvm/llvm-project/pull/92295
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/92295
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -215,3 +215,10 @@ namespace PR20735 {
// fix-it:"{{.*}}":{[[@LINE-9]]:20-[[@LINE-9]]:20}:")"
}
}
+
+void consecutive_builtin_compare(int x, int y, int z) {
+ (void)(x < y < z); // expected-warning {{comparisons like 'X<=Y<=Z' don't
have their mathematical meaning}}
@@ -14878,6 +14878,11 @@ ExprResult Sema::CreateBuiltinBinOp(SourceLocation
OpLoc,
case BO_GT:
ConvertHalfVec = true;
ResultTy = CheckCompareOperands(LHS, RHS, OpLoc, Opc);
+
+if (const auto *BI = dyn_cast(LHSExpr))
+ if (BI->isComparisonOp())
+
@@ -5143,6 +5143,10 @@ static bool EvaluateUnaryTypeTrait(Sema , TypeTrait
UTT,
case UTT_IsFloatingPoint:
return T->isFloatingType();
case UTT_IsArray:
+// zero-sized arrays aren't considered arrays in partial specializations,
AaronBallman wrote:
@@ -5143,6 +5143,10 @@ static bool EvaluateUnaryTypeTrait(Sema , TypeTrait
UTT,
case UTT_IsFloatingPoint:
return T->isFloatingType();
case UTT_IsArray:
+// zero-sized arrays aren't considered arrays in partial specializations,
+// so __is_array shouldn't
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/86652
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman approved this pull request.
Realistically, I don't think we can deprecate the extension in general:
https://sourcegraph.com/search?q=context:global+%5BA-Za-z0-9_%5D%2B%5Cs%5BA-Za-z0-9_%5D%2B%5C%5B0%5C%5D%3B+-file:.*test.*+-file:.*clang.*+count:10=regexp=0
I
AaronBallman wrote:
> Set the warning to DefaultIgnore, although -Wparentheses is enabled by
> default
Do we know why GCC elected to go that route? This seems like something that
should be enabled by default because the false positive rate should be quite
low.
AaronBallman wrote:
Btw, it seems that precommit CI found some valid issues to be addressed
https://github.com/llvm/llvm-project/pull/88265
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
AaronBallman wrote:
> > I don't think we should allow it for C++11 and later modes
>
> To clarify, should we allow enabling them in e.g. `c++03` mode if
> `-fraw-string-literals` is passed? I don’t see why not, but I’m not entirely
> sure whether you’re saying we should not support that flag
AaronBallman wrote:
> Thanks for everyone's input so far. Let me try to summarize discussions in
> this PR so we can set on an approach and give advice to our CIR community
> (and encode on our webpage) on how to move forward in upcoming patches.
> Useful resources:
>
> * [LLVM Coding
@@ -42,6 +47,14 @@ CreateFrontendBaseAction(CompilerInstance ) {
StringRef Action("unknown");
(void)Action;
+ auto UseCIR = CI.getFrontendOpts().UseClangIRPipeline;
AaronBallman wrote:
> Nit: technically the coding standard does not say that, I believe
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/92007
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman approved this pull request.
LGTM aside from a potential improvement to the test for clarity.
https://github.com/llvm/llvm-project/pull/92007
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -0,0 +1,23 @@
+// RUN: %clang_cc1 -x c++ -std=c++11 -triple x86_64-pc-linux -fsyntax-only
+// RUN: %clang_cc1 -x c++ -std=c++11 -triple x86_64-windows-msvc -fsyntax-only
+
+// Check we return non-zero values for supported attributes as per
+// wg21.link/p2552r3.pdf
@@ -14,13 +14,18 @@ void __builtin_va_copy(double d);
// expected-error@+2 {{cannot redeclare builtin function '__builtin_va_end'}}
// expected-note@+1 {{'__builtin_va_end' is a builtin with type}}
void __builtin_va_end(__builtin_va_list);
-// RUN: %clang_cc1 %s -fsyntax-only
AaronBallman wrote:
The changes seem reasonable to me, but I'd like to hear from @jcranmer-intel
and/or @hubert-reinterpretcast in terms of whether they agree with this
direction.
https://github.com/llvm/llvm-project/pull/90588
___
cfe-commits
https://github.com/AaronBallman approved this pull request.
LGTM! CC @rjmccall for any last-minute concerns.
https://github.com/llvm/llvm-project/pull/89086
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
AaronBallman wrote:
> For publicly-available code, it's not clear to me how much of the burden
> should fall on people that identify the problem. I want to do as much of this
> work as I can, it's difficult to balance the urgency of providing some
> reproducer (it gets hard to push for a fix
Jim M. R. =?utf-8?q?Teichgräber?=,Jim M. R. =?utf-8?q?Teichgräber?Message-ID:
In-Reply-To:
AaronBallman wrote:
> > > Btw, you can probably move this PR out of Draft status, it seems awfully
> > > close to finished
> >
> >
> > I'll finish implementing your suggestions, run the tests again
Jim M. R. =?utf-8?q?Teichgräber?=,Jim M. R. =?utf-8?q?Teichgräber?Message-ID:
In-Reply-To:
AaronBallman wrote:
> > Please be sure to add a release note to clang/docs/ReleaseNotes.rst so
> > users know about the fix.
>
> Oh, sorry, I didn't find anything know how release notes were handled -
@@ -107,6 +107,24 @@
///The 2nd source tile. Max size is 1024 Bytes.
#define _tile_cmmrlfp16ps(dst, a, b) __builtin_ia32_tcmmrlfp16ps(dst, a, b)
+/// Perform matrix multiplication of two tiles containing complex elements and
AaronBallman wrote:
Is this
@@ -533,6 +533,8 @@ __rdtscp(unsigned int *__A) {
/// \see __rdpmc
#define _rdpmc(A) __rdpmc(A)
+;
AaronBallman wrote:
This is quite surprising; I'm guessing this is so that the previous comment
does not associate with the function declared below, but this
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/88367
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman commented:
Because doxygen supports documenting macros
(https://www.doxygen.nl/manual/commands.html#cmddef), I am worried how often
this will cause us to associate comments incorrectly on the declaration.
I wonder if we should be a bit smarter and check for
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/90603
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/90603
>From 9b1fe59633b5404281b5b9fd754b8a81fae411d0 Mon Sep 17 00:00:00 2001
From: Chris Warner
Date: Tue, 23 Apr 2024 10:48:44 -0700
Subject: [PATCH 1/5] Load queries and matchers from file during REPL cycle
@@ -0,0 +1,14 @@
+// RUN: rm -rf %/t
+// RUN: mkdir %/t
+// RUN: cp %/S/Inputs/file.script %/t/file.script
+// RUN: cp %/S/Inputs/runtime_file.script %/t/runtime_file.script
+// Need to embed the correct temp path in the actual JSON-RPC requests.
+// RUN: sed -e
@@ -0,0 +1,14 @@
+// RUN: rm -rf %/t
+// RUN: mkdir %/t
+// RUN: cp %/S/Inputs/file.script %/t/file.script
+// RUN: cp %/S/Inputs/runtime_file.script %/t/runtime_file.script
+// Need to embed the correct temp path in the actual JSON-RPC requests.
+// RUN: sed -e
@@ -281,5 +282,26 @@ const QueryKind SetQueryKind::value;
const QueryKind SetQueryKind::value;
#endif
+bool FileQuery::run(llvm::raw_ostream , QuerySession ) const {
+ auto Buffer = llvm::MemoryBuffer::getFile(StringRef{File}.trim());
+ if (!Buffer) {
+if
https://github.com/AaronBallman approved this pull request.
LGTM! I'll add the newline to the file when landing so you don't have to mess
with another round of updating the PR. Thank you for the addition!
https://github.com/llvm/llvm-project/pull/90603
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/90603
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman commented:
Btw, you can probably move this PR out of Draft status, it seems awfully close
to finished
https://github.com/llvm/llvm-project/pull/91891
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/91891
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify -fblocks -pedantic %s
+// RUN: %clang_cc1 -fsyntax-only -verify -fblocks -pedantic -Wno-comment %s
AaronBallman wrote:
Ah! That's a perfectly fine reason to use `-Wno-comment` and you can leave the
test
@@ -3371,6 +3371,8 @@ def err_field_with_address_space : Error<
"field may not be qualified with an address space">;
def err_compound_literal_with_address_space : Error<
"compound literal in function scope may not be qualified with an address
space">;
+def
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/91891
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify -fblocks -pedantic %s
+// RUN: %clang_cc1 -fsyntax-only -verify -fblocks -pedantic -Wno-comment %s
AaronBallman wrote:
Why did this test need to add `-Wno-comment`?
https://github.com/AaronBallman commented:
Oops, we used to diagnose this until Clang 17 (I think I accidentally regressed
this behavior when implementing empty inits for C23). Thank you for the fix!
Please be sure to add a release note to clang/docs/ReleaseNotes.rst so users
know about the
https://github.com/AaronBallman approved this pull request.
Sorry for the delayed review, this fell off my radar. No release note needed
because this is fixing an issue introduced in this release. LGTM with a small
testing request.
https://github.com/llvm/llvm-project/pull/87793
@@ -19,8 +19,12 @@ f5 *e;
f6 *f;
f7 *g;
+enum E : long;
AaronBallman wrote:
Another test that would be helpful would be a test not using a fixed underlying
type but still produces a type compatible with `long`, as in:
```
enum E {
Big = __LONG_MAX__
};
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/87793
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman commented:
Sorry, this fell off my radar for a while. The only concern I have is with
accidentally allowing `[0]` to mean something; it would be good to reject
that and add a test for that situation. Otherwise, this looks reasonable to me.
@@ -437,6 +442,16 @@ namespace {
MostDerivedArraySize = 2;
MostDerivedPathLength = Entries.size();
}
+void addVectorUnchecked(QualType EltTy, uint64_t Size, uint64_t Idx) {
+ Entries.push_back(PathEntry::ArrayIndex(Idx));
+
+ // This is
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/72607
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1 @@
+m functionDecl()
AaronBallman wrote:
Can you add a few more commands to the file to show that we execute all of the
commands rather than just one?
It would also be good to have a test where the file is not found and a test
where the file is
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/90603
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -281,5 +282,26 @@ const QueryKind SetQueryKind::value;
const QueryKind SetQueryKind::value;
#endif
+bool FileQuery::run(llvm::raw_ostream , QuerySession ) const {
+ auto Buffer = llvm::MemoryBuffer::getFile(StringRef{File}.trim());
+ if (!Buffer) {
+if
https://github.com/AaronBallman commented:
Thank you for working on this, I think it's a good new feature! You should also
add a release note for it to `clang-tools-extra/docs/ReleaseNotes.rst` so users
know about the improvement.
https://github.com/llvm/llvm-project/pull/90603
@@ -149,6 +149,63 @@ class TextTokenRetokenizer {
addToken();
}
+ /// Check if this line starts with @par or \par
+ bool startsWithParCommand() {
+unsigned Offset = 1;
+
+/// Skip all whitespace characters at the beginning.
+/// This needs to backtrack
AaronBallman wrote:
Is this still in Draft status or should this be marked as ready for review?
https://github.com/llvm/llvm-project/pull/88367
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/90237
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1753,91 +1742,93 @@ Possible Questions
How modules speed up compilation
-A classic theory for the reason why modules speed up the compilation is:
-if there are ``n`` headers and ``m`` source files and each header is included
by each
@@ -8,109 +8,91 @@ Standard C++ Modules
Introduction
-The term ``modules`` has a lot of meanings. For the users of Clang, modules may
-refer to ``Objective-C Modules``, ``Clang C++ Modules`` (or ``Clang Header
Modules``,
-etc.) or ``Standard C++ Modules``. The
AaronBallman wrote:
> I think we should apply @ChuanqiXu9 suggestion and merge that without tests.
> At worse it's harmless, at best it solves an actual issue for users. We have
> precedent for not being able to test resource exhaustion fixes.
I would not be opposed to landing with a test,
Author: Aaron Ballman
Date: 2024-05-08T08:03:22-04:00
New Revision: 943617d12ccbd3cf317f0bbec03d9efc700f3953
URL:
https://github.com/llvm/llvm-project/commit/943617d12ccbd3cf317f0bbec03d9efc700f3953
DIFF:
https://github.com/llvm/llvm-project/commit/943617d12ccbd3cf317f0bbec03d9efc700f3953.diff
AaronBallman wrote:
I think I've addressed all of the feedback (thank you all for the
improvements!), except for the suggestion from @Endilll to switch to using
italics rather than code font. I think the suggestion is a good one, but it's a
time-consuming edit that doesn't change the meaning
@@ -8,109 +8,91 @@ Standard C++ Modules
Introduction
-The term ``modules`` has a lot of meanings. For the users of Clang, modules may
-refer to ``Objective-C Modules``, ``Clang C++ Modules`` (or ``Clang Header
Modules``,
-etc.) or ``Standard C++ Modules``. The
@@ -925,45 +923,41 @@ In that case, you need to convert your source files (.cpp
files) to module imple
// Following off should be unchanged.
...
-The module implementation unit will import the primary module implicitly.
-We don't include any headers in the module
@@ -738,22 +736,21 @@ the following style significantly:
import M;
... // use declarations from module M.
-The key part of the tip is to reduce the duplications from the text includes.
+Reducing the duplication from textual includes is what improves compile-time
@@ -400,24 +389,27 @@ And the compilation process for module units are like:
mod1.cppm -> clang++ mod1.cppm ... -> mod1.pcm --,--> clang++
mod1.pcm ... -> mod1.o -+
src2.cpp +> clang++
src2.cpp --->
@@ -8,109 +8,91 @@ Standard C++ Modules
Introduction
-The term ``modules`` has a lot of meanings. For the users of Clang, modules may
-refer to ``Objective-C Modules``, ``Clang C++ Modules`` (or ``Clang Header
Modules``,
-etc.) or ``Standard C++ Modules``. The
@@ -1391,17 +1381,17 @@ with the following one:
$ clang++ -std=c++20 -xc++-system-header --precompile iostream -o
iostream.pcm
$ clang++ -std=c++20 -fmodule-file=iostream.pcm --precompile M.cppm -o M.cpp
-In the latter example, the Clang could find the BMI for the
@@ -633,36 +631,36 @@ example:
// module M's interface, so is discarded
int c = use_h(); // OK
-In the above example, the function definition of ``N::g`` is elided from the
Reduced
-BMI of ``M.cppm``. Then the use of ``use_g`` in
@@ -400,24 +389,27 @@ And the compilation process for module units are like:
mod1.cppm -> clang++ mod1.cppm ... -> mod1.pcm --,--> clang++
mod1.pcm ... -> mod1.o -+
src2.cpp +> clang++
src2.cpp --->
@@ -312,75 +300,76 @@ So all of the following name is not valid by default:
__test
// and so on ...
-If you still want to use the reserved module names for any reason, use
-``-Wno-reserved-module-identifier`` to suppress the warning.
+Using a reserved module name is
@@ -8,79 +8,60 @@ Standard C++ Modules
Introduction
-The term ``modules`` has a lot of meanings. For the users of Clang, modules may
-refer to ``Objective-C Modules``, ``Clang C++ Modules`` (or ``Clang Header
Modules``,
-etc.) or ``Standard C++ Modules``. The
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/90237
>From a75aa14fcad6f346a3073ae88e91fa890e803422 Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Fri, 26 Apr 2024 13:12:51 -0400
Subject: [PATCH 1/2] Revise the modules document for clarity
The intention
AaronBallman wrote:
> Thank you everyone for the reviews!
Thank you for the improvement!
https://github.com/llvm/llvm-project/pull/90012
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -111,6 +111,13 @@ Clang Frontend Potentially Breaking Changes
$ clang --target= -print-target-triple
+- The ``getTypeAsWritten`` member function has been removed from
``ClassTemplateSpecializationDecl`` and
+ ``VarTemplateSpecializationDecl``, and a new member
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/90012
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/90012
>From 9007597af4f138d2744405bb7980fce4555d7508 Mon Sep 17 00:00:00 2001
From: Andrew Sukach
Date: Wed, 24 Apr 2024 22:50:50 -0400
Subject: [PATCH 1/3] [clang] MangledSymbol: remove pointless copy of vector
801 - 900 of 5456 matches
Mail list logo
