[clang] [llvm] [MC,llvm-readobj,yaml2obj] Support CREL relocation format (PR #91280)
dwblaikie wrote: > Switched to 0x4014 (generic range) to retain linker errors while making > the experimental status stand out. Add a comment to make the intention > clearer. Seems a bit weird/problematic, using something in the reserved range/not in a user extension space, but I guess so long as you're comfy breaking it in the future (& it's not like the current allocated numbers are anywhere near... so by the time anyone is using this allocated number for an official purposes, this experiment will be long gone & hopefully have an official number) until it gets an official number, I guess that works for me. Thanks! https://github.com/llvm/llvm-project/pull/91280 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [MC,clang,llvm-readobj,yaml2obj] Support CREL relocation format (PR #91280)
dwblaikie wrote: > This approahc parallels the strategy used for > [-enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang](https://reviews.llvm.org/D125142), > albeit a nicer name. Fair enough - yeah, if we're wordsmithing this. Maybe "allow" would be a good word, rather than "enable" (or no verb at all), as in `-allow-experimental-crel`? > While ELF allows extension space for processor/OS/application-specific > section types, using them introduces challenges since we want linker errors when SHT_CREL is unsupported (see isKnownSpecificSectionType in https://github.com/llvm/llvm-project/pull/85173): > > [SHT_LOUSER,SHT_HIUSER]: Not applicable as static relocation sections do not > have the SHF_ALLOC flag. I missed a step here - why is this range only applicable for SHF_ALLOC sections? Ah, from the patch you linked earlier, linkers don't fail on SHT_*USER range unless it's allocated... that seems a bit tenuous, though. Seems like this the range intended for this kind of experimentation, with the cost that it doesn't produce an error from existing linkers (though it could, but they're trying to be conservative/allow for extensions that don't need linker-awareness). Guess I'll leave that up to other folks to comment on. > [SHT_LOOS,SHT_HIOS]: Requires annoying SHF_OS_NONCONFORMING. We want psABI > documents to be willing to accept CREL when toolchain becomes ready, > especially if their relocatable files are huge due to linker relaxation (e.g. > RISC-V, LoongArch), we want to avoid GNUism / LLVMism. So in this case each OS would have to allocate their own number in in the SHT_*OS range? Yeah, that seems unfortunate. > [SHT_LOPROC,SHT_HIPROC]: Processor-specific and not applicable. Similar to the *OS case above, I guess. > We will unlikely change the format. I think we should start with the theory that the format will change - even if it doesn't, we wouldn't want to introduce this new thing and avoid change because we've made it hard to change if we discover in early testing that there's things we could do better. > Solaris-specific SHF_ORDERED and SHF_EXCLUDE, without a SunOS/Solaris name > infix/prefix/suffix, make them into glibc elf.h. > SHF_EXCLUDE gets picked due to its linker semantics but SHF_ORDERED is never > used. > A generic name SHT_CREL might not be fundamentally different from SHF_EXCLUDE. Got links to the history here, about how SHF_ORDERED/EXCLUDE came to be? https://github.com/llvm/llvm-project/pull/91280 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [MC,clang,llvm-readobj,yaml2obj] Support CREL relocation format (PR #91280)
dwblaikie wrote: Oh, and I take it there's no /official/ extension space in the SHT_* space? The intent is to standardize it where it lies? (like use 20 for the shipped version? Or eventually get some lower designation?) I understand tnhe hesitance to use "SHT_LLVM" or the like (though equally, it does seem suitable (to try to use a name less likely to collide), if this is an experiment ,but I understand other projects may have some not-invented-here negative sentiment to such a thing), perhaps "SHT_EXP" wouldn't be too bad? https://github.com/llvm/llvm-project/pull/91280 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [MC,clang,llvm-readobj,yaml2obj] Support CREL relocation format (PR #91280)
dwblaikie wrote: Presumably this'll be split out into separate reviews for the components here? (I'd guess llvm-mc then clang integrated assembler, with readobj and yaml2obj in any order/don't have dependencies, unless they're needed for testing, in which case I guess they come first?) I hesitate to comment on the specifics while it's all together as I imagine it'll become hard to follow the different commentary across the larger patch/different project areas, etc. (though the flag design seems strange to me - having --crel and --experimental-crel, rather than having only the latter (and renaming it in the future, rather than using two flags now and removing one in the future)) https://github.com/llvm/llvm-project/pull/91280 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Modules] Detect ODR mismatches for enums in non-C++ like in C++. (PR #90298)
dwblaikie wrote: > Though we detect when the types aren't identical and don't try to use them > interchangeably. The change extends the existing behavior for structs/unions > to enums. OK, still a bit confused though - "like in C++", I assume in C++ we reject mismatched types coming from different modules. But it sounds like in C you're suggesting that we (moreso with this patch) detect mismatches and silently allow different type definitions to work? Which would presumably be the right thing for C. So, I guess, maybe my concern is only with a confusing title/description... https://github.com/llvm/llvm-project/pull/90298 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] Add option to generate additional debug info for expression dereferencing pointer to pointers. (PR #81545)
@@ -5636,6 +5636,84 @@ void
CGDebugInfo::EmitExternalVariable(llvm::GlobalVariable *Var,
Var->addDebugInfo(GVE);
}
+void CGDebugInfo::EmitPseudoVariable(CGBuilderTy ,
+ llvm::Instruction *Value, QualType Ty) {
+ // Only when -g2 or above is specified, debug info for variables will be
+ // generated.
+ if (CGM.getCodeGenOpts().getDebugInfo() <=
+ llvm::codegenoptions::DebugLineTablesOnly)
+return;
+
+ llvm::DIFile *Unit = Builder.getCurrentDebugLocation()->getFile();
+ llvm::DIType *Type = getOrCreateType(Ty, Unit);
+
+ // Check if Value is already a declared variable and has debug info, in this
+ // case we have nothing to do. Clang emits declared variable as alloca, and
+ // it is loaded upon use, so we identify such pattern here.
+ if (llvm::LoadInst *Load = dyn_cast(Value)) {
+llvm::Value *Var = Load->getPointerOperand();
+if (llvm::Metadata *MDValue = llvm::ValueAsMetadata::getIfExists(Var)) {
+ if (llvm::Value *DbgValue = llvm::MetadataAsValue::getIfExists(
+ CGM.getLLVMContext(), MDValue)) {
+for (llvm::User *U : DbgValue->users()) {
+ if (llvm::CallInst *DbgDeclare = dyn_cast(U)) {
+if (DbgDeclare->getCalledFunction()->getIntrinsicID() ==
+llvm::Intrinsic::dbg_declare &&
+DbgDeclare->getArgOperand(0) == DbgValue) {
+ // There can be implicit type cast applied on a variable if it is
+ // an opaque ptr, in this case its debug info may not match the
+ // actual type of object being used as in the next instruction,
so
+ // we will need to emit a pseudo variable for type-casted value.
+ llvm::DILocalVariable *MDNode = dyn_cast(
+ dyn_cast(DbgDeclare->getOperand(1))
+ ->getMetadata());
+ if (MDNode->getType() == Type)
+return;
+}
+ }
+}
+ }
+}
+ }
+
+ // Find the correct location to insert a sequence of instructions to
+ // materialize Value on the stack.
+ auto SaveInsertionPoint = Builder.saveIP();
+ if (llvm::InvokeInst *Invoke = dyn_cast(Value))
+Builder.SetInsertPoint(Invoke->getNormalDest()->begin());
+ else if (llvm::Instruction *Next = Value->getIterator()->getNextNode())
+Builder.SetInsertPoint(Next);
+ else
+Builder.SetInsertPoint(Value->getParent());
+ auto SaveDebugLoc = Builder.getCurrentDebugLocation();
+ llvm::DebugLoc DL = Value->getDebugLoc();
+ if (DL.get())
+Builder.SetCurrentDebugLocation(DL);
+
+ llvm::AllocaInst *PseudoVar = Builder.CreateAlloca(Value->getType());
+ Address PseudoVarAddr(PseudoVar, Value->getType(),
+CharUnits::fromQuantity(PseudoVar->getAlign()));
+ llvm::LoadInst *Load = Builder.CreateLoad(PseudoVarAddr);
+ Value->replaceAllUsesWith(Load);
+ Builder.SetInsertPoint(Load);
+ Builder.CreateStore(Value, PseudoVarAddr);
+
+ // Emit debug info for materialized Value.
+ unsigned Line = Builder.getCurrentDebugLocation().getLine();
dwblaikie wrote:
Hmm - what breaks? I tried this with some hand-modified IR and it seems to
produce the desired DWARF:
https://godbolt.org/z/n8a5Ef1Yj - `i` local has had the file/line removed, `j`
local has not. Oh, and it even works if the name is removed - which might save
a few bytes too? (I think if a name is going to be included, I'd expect it to
be a reserved name, starting with `__`)
Ah, I see, you're also using the location for the DILocation of the debug
intrinsic - I meant to refer only to the location (file, line, and column) of
the DILocalVariable created by `createAutoVariable` (ie, I'm suggesting: `
DBuilder.createAutoVariable(LexicalBlockStack.back(), "", nullptr, 0, Type)`)
https://github.com/llvm/llvm-project/pull/81545
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Add support for builtin_verbose_trap (PR #79230)
@@ -27,6 +27,9 @@ namespace llvm {
}
}
+// Prefix for __builtin_verbose_trap.
+#define CLANG_VERBOSE_TRAP_PREFIX "__llvm_verbose_trap"
dwblaikie wrote:
& not sure it being a compile time constant regex is super important - the
regex compilation probably dwarfs the string concatenation required to add the
`^` and `:`?
https://github.com/llvm/llvm-project/pull/79230
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Add support for builtin_verbose_trap (PR #79230)
@@ -27,6 +27,9 @@ namespace llvm {
}
}
+// Prefix for __builtin_verbose_trap.
+#define CLANG_VERBOSE_TRAP_PREFIX "__llvm_verbose_trap"
dwblaikie wrote:
I think we usually use some llvm or clang prefix in these sort of things, to
reduce the chance of conflict with some other implementation's reserved names?
Could be worth a quick grepping for other similar symbol names in clang/llvm to
see what we do/if there's some pattern to follow?
https://github.com/llvm/llvm-project/pull/79230
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Fall back to DW_TAG_typedef for instantiation dependent template aliases (PR #90032)
dwblaikie wrote: > > Comment in the code should probably mention this as a FIXME and include a > > reference to the issue? > > Sure, added in > [f78949a](https://github.com/llvm/llvm-project/commit/f78949a07e33017a798c410a102c95455685a9b1) Thanks! > > Also, there's another bug here - the DW_TAG_typedef is in the CU scope, > > instead of the struct scope. But if the struct is a non-template, the > > typedef is in the struct scope as it should be, not the CU scope... > > That does looks odd - I can reproduce it with normal (language-level) > typedefs too (rather than with template aliases): > https://godbolt.org/z/GsGKqhKzz. I can open a separate issue? Yep! https://github.com/llvm/llvm-project/pull/90032 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] 1cb3371 - Ensure test writes objects to test temp dir
Author: David Blaikie Date: 2024-04-29T23:50:18Z New Revision: 1cb33713910501c6352d0eb2a15b7a15e6e18695 URL: https://github.com/llvm/llvm-project/commit/1cb33713910501c6352d0eb2a15b7a15e6e18695 DIFF: https://github.com/llvm/llvm-project/commit/1cb33713910501c6352d0eb2a15b7a15e6e18695.diff LOG: Ensure test writes objects to test temp dir Added: Modified: clang/test/CodeGenCoroutines/coro-elide-thinlto.cpp Removed: diff --git a/clang/test/CodeGenCoroutines/coro-elide-thinlto.cpp b/clang/test/CodeGenCoroutines/coro-elide-thinlto.cpp index 293aef6781677f..790899486ec9d1 100644 --- a/clang/test/CodeGenCoroutines/coro-elide-thinlto.cpp +++ b/clang/test/CodeGenCoroutines/coro-elide-thinlto.cpp @@ -2,10 +2,10 @@ // This test is adapted from coro-elide.cpp and splits functions into two files. // // RUN: split-file %s %t -// RUN: %clang --target=x86_64-linux -std=c++20 -O2 -flto=thin -I %S -c %t/coro-elide-callee.cpp -o coro-elide-callee.o -// RUN: %clang --target=x86_64-linux -std=c++20 -O2 -flto=thin -I %S -c %t/coro-elide-caller.cpp -o coro-elide-caller.o -// RUN: llvm-lto -thinlto coro-elide-callee.o coro-elide-caller.o -o summary -// RUN: %clang_cc1 -O2 -x ir coro-elide-caller.o -fthinlto-index=summary.thinlto.bc -emit-llvm -o - | FileCheck %s +// RUN: %clang --target=x86_64-linux -std=c++20 -O2 -flto=thin -I %S -c %t/coro-elide-callee.cpp -o %t/coro-elide-callee.o +// RUN: %clang --target=x86_64-linux -std=c++20 -O2 -flto=thin -I %S -c %t/coro-elide-caller.cpp -o %t/coro-elide-caller.o +// RUN: llvm-lto -thinlto %t/coro-elide-callee.o %t/coro-elide-caller.o -o summary +// RUN: %clang_cc1 -O2 -x ir %t/coro-elide-caller.o -fthinlto-index=summary.thinlto.bc -emit-llvm -o - | FileCheck %s //--- coro-elide-task.h #pragma once ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Modules] Detect ODR mismatches for enums in non-C++ like in C++. (PR #90298)
dwblaikie wrote: > > C doesn't have an odr, does it? > > For non-C++ "ODR" has a meaning more like "ODR-inspired checks". But there is > no language rule that would require enforcement and there is no impact on > linkage (at least during deserialization). Not sure I'm following the response here - but I guess what I'm trying to say, with more words, is that my understanding was that C doesn't have an ODR, and you can have different definitions of a type, with the same name, in C and that's OK. And it sounds like this change makes that not OK in some way? (either by diagnosing/erroring on such divergent types, or assuming they won't diverge and carrying on silently) https://github.com/llvm/llvm-project/pull/90298 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Fall back to DW_TAG_typedef for instantiation dependent template aliases (PR #90032)
dwblaikie wrote: Comment in the code should probably mention this as a FIXME and include a reference to the issue? Also, there's another bug here - the DW_TAG_typedef is in the CU scope, instead of the struct scope. But if the struct is a non-template, the typedef is in the struct scope as it should be, not the CU scope... https://github.com/llvm/llvm-project/pull/90032 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Modules] Detect ODR mismatches for enums in non-C++ like in C++. (PR #90298)
dwblaikie wrote: C doesn't have an odr, does it? https://github.com/llvm/llvm-project/pull/90298 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Add support for builtin_verbose_trap (PR #79230)
@@ -3379,6 +3379,60 @@ Query for this feature with ``__has_builtin(__builtin_debugtrap)``. Query for this feature with ``__has_builtin(__builtin_trap)``. +``__builtin_verbose_trap`` dwblaikie wrote: Ah, OK - that seems like more reason the prefix should be singular. Like we shouldn't add a new/distinct prefix for array bounds? Or other things we want to error out on - because it'd be an ongoing maintenance problem updating consumers like lldb each time we add one? So maybe we should have a generic prefix we'll always use (`__builtin_trap`, say) and then maybe some identifier after that in a known format (eg: space, identifier, space) that can be used? then an error message string? https://github.com/llvm/llvm-project/pull/79230 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Add support for builtin_verbose_trap (PR #79230)
@@ -0,0 +1,28 @@
+// RUN: %clang_cc1 -std=c++11 -fsyntax-only -fcxx-exceptions -verify %s
+
+#if !__has_builtin(__builtin_verbose_trap)
+#error
+#endif
+
+constexpr char const* constMsg1 = "hello";
+char const* const constMsg2 = "hello";
+char const constMsg3[] = "hello";
+
+template
+void f(const char * arg) {
+ __builtin_verbose_trap("Argument_must_not_be_null");
dwblaikie wrote:
FWIW, I've seen multiple MB symbol names :) so I probably wouldn't be too
worried that any user would write a description that's longer than the symbols
that complex templates can create...
https://github.com/llvm/llvm-project/pull/79230
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Add support for builtin_verbose_trap (PR #79230)
@@ -3424,6 +3445,26 @@ llvm::DIMacroFile *CGDebugInfo::CreateTempMacroFile(llvm::DIMacroFile *Parent, return DBuilder.createTempMacroFile(Parent, Line, FName); } +llvm::DILocation *CGDebugInfo::CreateTrapFailureMessageFor( dwblaikie wrote: I think I agree with https://github.com/llvm/llvm-project/pull/79230/files#r1529429173 then - the prefix should be a parameter and I don't think it needs to be a #defined constant (CLANG_VERBOSE_TRAP_PREFIX) - and can instead be written as a literal in the caller in CGBuiltin.cpp? https://github.com/llvm/llvm-project/pull/79230 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] Add option to generate additional debug info for expression dereferencing pointer to pointers. (PR #81545)
@@ -5636,6 +5636,84 @@ void
CGDebugInfo::EmitExternalVariable(llvm::GlobalVariable *Var,
Var->addDebugInfo(GVE);
}
+void CGDebugInfo::EmitPseudoVariable(CGBuilderTy ,
+ llvm::Instruction *Value, QualType Ty) {
+ // Only when -g2 or above is specified, debug info for variables will be
+ // generated.
+ if (CGM.getCodeGenOpts().getDebugInfo() <=
+ llvm::codegenoptions::DebugLineTablesOnly)
+return;
+
+ llvm::DIFile *Unit = Builder.getCurrentDebugLocation()->getFile();
+ llvm::DIType *Type = getOrCreateType(Ty, Unit);
+
+ // Check if Value is already a declared variable and has debug info, in this
+ // case we have nothing to do. Clang emits declared variable as alloca, and
+ // it is loaded upon use, so we identify such pattern here.
+ if (llvm::LoadInst *Load = dyn_cast(Value)) {
+llvm::Value *Var = Load->getPointerOperand();
+if (llvm::Metadata *MDValue = llvm::ValueAsMetadata::getIfExists(Var)) {
+ if (llvm::Value *DbgValue = llvm::MetadataAsValue::getIfExists(
+ CGM.getLLVMContext(), MDValue)) {
+for (llvm::User *U : DbgValue->users()) {
+ if (llvm::CallInst *DbgDeclare = dyn_cast(U)) {
+if (DbgDeclare->getCalledFunction()->getIntrinsicID() ==
+llvm::Intrinsic::dbg_declare &&
+DbgDeclare->getArgOperand(0) == DbgValue) {
+ // There can be implicit type cast applied on a variable if it is
+ // an opaque ptr, in this case its debug info may not match the
+ // actual type of object being used as in the next instruction,
so
+ // we will need to emit a pseudo variable for type-casted value.
+ llvm::DILocalVariable *MDNode = dyn_cast(
+ dyn_cast(DbgDeclare->getOperand(1))
+ ->getMetadata());
+ if (MDNode->getType() == Type)
+return;
+}
+ }
+}
+ }
+}
+ }
+
+ // Find the correct location to insert a sequence of instructions to
+ // materialize Value on the stack.
+ auto SaveInsertionPoint = Builder.saveIP();
+ if (llvm::InvokeInst *Invoke = dyn_cast(Value))
+Builder.SetInsertPoint(Invoke->getNormalDest()->begin());
+ else if (llvm::Instruction *Next = Value->getIterator()->getNextNode())
+Builder.SetInsertPoint(Next);
+ else
+Builder.SetInsertPoint(Value->getParent());
+ auto SaveDebugLoc = Builder.getCurrentDebugLocation();
+ llvm::DebugLoc DL = Value->getDebugLoc();
+ if (DL.get())
+Builder.SetCurrentDebugLocation(DL);
+
+ llvm::AllocaInst *PseudoVar = Builder.CreateAlloca(Value->getType());
+ Address PseudoVarAddr(PseudoVar, Value->getType(),
+CharUnits::fromQuantity(PseudoVar->getAlign()));
+ llvm::LoadInst *Load = Builder.CreateLoad(PseudoVarAddr);
+ Value->replaceAllUsesWith(Load);
+ Builder.SetInsertPoint(Load);
+ Builder.CreateStore(Value, PseudoVarAddr);
+
+ // Emit debug info for materialized Value.
+ unsigned Line = Builder.getCurrentDebugLocation().getLine();
dwblaikie wrote:
Any chance we can omit the line/column/file/name? (if LLVM currently thinks
variables must have these properties, perhaps we could relax those requirements
first)
https://github.com/llvm/llvm-project/pull/81545
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] Add option to generate additional debug info for expression dereferencing pointer to pointers. (PR #81545)
@@ -5636,6 +5636,84 @@ void
CGDebugInfo::EmitExternalVariable(llvm::GlobalVariable *Var,
Var->addDebugInfo(GVE);
}
+void CGDebugInfo::EmitPseudoVariable(CGBuilderTy ,
+ llvm::Instruction *Value, QualType Ty) {
+ // Only when -g2 or above is specified, debug info for variables will be
+ // generated.
+ if (CGM.getCodeGenOpts().getDebugInfo() <=
+ llvm::codegenoptions::DebugLineTablesOnly)
+return;
+
+ llvm::DIFile *Unit = Builder.getCurrentDebugLocation()->getFile();
+ llvm::DIType *Type = getOrCreateType(Ty, Unit);
+
+ // Check if Value is already a declared variable and has debug info, in this
+ // case we have nothing to do. Clang emits declared variable as alloca, and
+ // it is loaded upon use, so we identify such pattern here.
+ if (llvm::LoadInst *Load = dyn_cast(Value)) {
+llvm::Value *Var = Load->getPointerOperand();
+if (llvm::Metadata *MDValue = llvm::ValueAsMetadata::getIfExists(Var)) {
+ if (llvm::Value *DbgValue = llvm::MetadataAsValue::getIfExists(
+ CGM.getLLVMContext(), MDValue)) {
+for (llvm::User *U : DbgValue->users()) {
+ if (llvm::CallInst *DbgDeclare = dyn_cast(U)) {
+if (DbgDeclare->getCalledFunction()->getIntrinsicID() ==
+llvm::Intrinsic::dbg_declare &&
+DbgDeclare->getArgOperand(0) == DbgValue) {
+ // There can be implicit type cast applied on a variable if it is
+ // an opaque ptr, in this case its debug info may not match the
+ // actual type of object being used as in the next instruction,
so
+ // we will need to emit a pseudo variable for type-casted value.
+ llvm::DILocalVariable *MDNode = dyn_cast(
dwblaikie wrote:
Given the next line unconditionally dereferences this pointer, this should be a
`cast` instead of a `dyn_cast`, I think?
https://github.com/llvm/llvm-project/pull/81545
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] Add option to generate additional debug info for expression dereferencing pointer to pointers. (PR #81545)
@@ -1787,7 +1787,26 @@ Value *ScalarExprEmitter::VisitMemberExpr(MemberExpr *E)
{
}
}
- return EmitLoadOfLValue(E);
+ llvm::Value *Result = EmitLoadOfLValue(E);
+
+ // If -fdebug_info_for_profiling is specified, emit a pseudo variable and its
dwblaikie wrote:
`-fdebug-info-for-profiling` (dashes rather than underscores)
https://github.com/llvm/llvm-project/pull/81545
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Reapply "[Clang][Sema] placement new initializes typedef array with correct size (#83124)" (PR #89036)
dwblaikie wrote: > Yes it's fixed now. Please include details of the fix I the patch description https://github.com/llvm/llvm-project/pull/89036 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Reapply "[Clang][Sema] placement new initializes typedef array with correct size (#83124)" (PR #89036)
dwblaikie wrote: > The original patch pointed out a regression: > > https://github.com/llvm/llvm-project/pull/83124#issuecomment-2060090590 > > Please contact that person and get a reproducer and make sure you aren't > breaking them. Repro was provided further down: https://github.com/llvm/llvm-project/pull/83124#issuecomment-2062540922 Please include test coverage and a fix before approval/recommit. https://github.com/llvm/llvm-project/pull/89036 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][Sema] placement new initializes typedef array with correct size (PR #83124)
dwblaikie wrote:
Simplified a bit more:
```
template
void f1() {
int (*x)[1] = new int[1][1]; // fails
}
template void f1();
void f2() {
int (*x)[1] = new int[1][1]; // passes
}
```
https://godbolt.org/z/MhaYbvefG - yeah seems pretty clear this is a regression.
Compiles with GCC, fails with clang, and the non-dependent context passes with
either.
https://github.com/llvm/llvm-project/pull/83124
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [Clang] Emit DW_TAG_template_alias for template aliases (PR #87623)
dwblaikie wrote:
> Thanks @dwblaikie
>
> > Bit unfortunate to store template parameters in different ways (in the
> > extraData for the alias template, but in the templateParams for the
> > composite types) - but I guess it'd be more invasive to try to represent
> > alias templates as composite types?
>
> I hadn't actually tried using DICompsiteType. I didn't choose DIDerivedType
> for any particularly principled reasons: typedefs use derived types which
> made it very easy to find places that needed updating, and an alias "felt"
> more like a derived type than composite type. Having looked only briefly, I
> don't _think_ it'd be any more invasive to use composite types instead (not
> 100% sure without diving in). I'm happy to give that a go if that is your
> preference?
Eh, I guess if we've already got DIGlobalVariable having template params, we
aren't going to unify all 3 cases - not sure if unifying 2 out of three is
particularly valuable, especially if it ends up with a different conflict (that
alias templates look less like aliases & so need special casing in that
direction)
But perhaps at least you could add named accessors to DIDerivedType for the
template params, same as DIGlobalVariable/DICompositeType have?
(oh, and in case anyone hasn't mentioned it already - this would generally be
committed in smaller pieces upstream - adding the LLVM functionality first,
then adding clang patches that use that functionality)
> I've just found an input that causes an assertion failure in
> `CollectTemplateParams` with my implementation:
>
> ```
> template
> struct X {
> Y m1;
> Z m2;
> };
>
> template
> using A = X;
>
> A a;
> ```
>
> There's a mismatch between the template parameter list and template argument
> list sizes, created here:
>
> ```
> if (CGM.getCodeGenOpts().DebugTemplateAlias) {
> TemplateArgs Args = {TD->getTemplateParameters(),
> Ty->template_arguments()}; // <--- here
> ```
>
> I notice that we emit `DW_TAG_GNU_template_parameter_pack` for, e.g.,
> variadic template struct instantiations. I've not figured out how to fix this
> just yet, but thought I'd bring it up in case there's something obvious.
yeah, probably worth checking the APIs that we use for building the template
args for classes and variable templates, they probably have some handling for
this - would be good to share/reuse that code, rather than duplicating it, once
you find it
https://github.com/llvm/llvm-project/pull/87623
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [Clang] Emit DW_TAG_template_alias for template aliases (PR #87623)
dwblaikie wrote: Re: code: Looks about right. Bit unfortunate to store template parameters in different ways (in the `extraData` for the alias template, but in the `templateParams` for the composite types) - but I guess it'd be more invasive to try to represent alias templates as composite types? https://github.com/llvm/llvm-project/pull/87623 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [C++20] [Modules] Introduce -fexperimental-modules-reduced-bmi (PR #85050)
https://github.com/dwblaikie edited https://github.com/llvm/llvm-project/pull/85050 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [C++20] [Modules] Introduce -fexperimental-modules-reduced-bmi (PR #85050)
https://github.com/dwblaikie approved this pull request. Give it a go https://github.com/llvm/llvm-project/pull/85050 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [C++20] [Modules] Introduce -fexperimental-modules-reduced-bmi (PR #85050)
@@ -1061,6 +1070,16 @@ CodeGenAction::CreateASTConsumer(CompilerInstance ,
StringRef InFile) {
CI.getPreprocessor().addPPCallbacks(std::move(Callbacks));
}
+ if (CI.getFrontendOpts().GenReducedBMI &&
+ !CI.getFrontendOpts().ModuleOutputPath.empty()) {
+std::vector> Consumers{2};
+Consumers[0] = std::make_unique(
+CI.getPreprocessor(), CI.getModuleCache(),
+CI.getFrontendOpts().ModuleOutputPath);
+Consumers[1] = std::move(Result);
+return std::make_unique(std::move(Consumers));
+ }
dwblaikie wrote:
Why is this new code, rather than an alternative codepath of existing code?
(like some code that was producing the BMI would go from producing the
unreduced BMI to producing the reduced BMI)
Figuring this out would help me unedrstand why `ModuleOutputPath` is new (this
patch doesn't add the functionality to output a module to a path - we had that
already, this just changes the content that goes there)
I guess because maybe this patch is changing the way we output the BMI - or
that the reduced BMI is being output in a different way than the non-reduced
BMI?
Should we address that? Make the current full BMI emission work the same way as
the reduced BMI? (or, more precisely, in a pre-patch, change the full BMI
emission to use a mechanism that can then be reused for the reduced BMI?)
https://github.com/llvm/llvm-project/pull/85050
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [Clang] Emit DW_TAG_template_alias for template aliases (PR #87623)
dwblaikie wrote: > > I'm a little uncomfortable with adding a new user-facing option for > > template aliases. Even with that in place, we should not warn and refuse to > > do what the user asked for, based on DWARF version. -gdwarf-2 -gsplit-dwarf > > generates a .dwo file claiming to be v2, for example. > > I don't have strong feelings about the flag setup and am happy to change it. > @dwblaikie mentioned that we might not want to have the debugger tuning be > the only way of controlling whether or not we emit this DIE, so adding > `-gtemplate-alias` which has its default set based on debugger tuning seemed > like a reasonable way of doing it. What would be the best way of controlling > this feature in your opinion (bearing in mind that GCC doesn't emit it, and > GDB and LLDB don't the DIE)? @pogo59 Hmm - I thought you held a strong preference that debugger tuning never be the only way to access a certain feature, and that we should always have direct control of these features via flags (but with default (or explicit) debugger tuning setting some of these flag defaults based on the preferred content for that debugger). Perhaps i'm misremembering? https://github.com/llvm/llvm-project/pull/87623 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] Add option to generate additional debug info for expression dereferencing pointer to pointers. (PR #81545)
dwblaikie wrote: > As for impact, I believe @namhyung did some measurement for building the > Linux kernel, and it does not have a significant impact. That'd surprise me quite a bit - perhaps a self-host build of clang (ideally in Google's build config, that being the one you and I care about the most) - opt with fission? measuring the size of object and dwo files (linker action inputs, but ideally more fine-grained per-section size comparisons would be good) and the linked executable/dwp. https://github.com/llvm/llvm-project/pull/81545 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][Sema] Ignore the parentheses in the guard of DiagnoseUnexpandedParameterPack (PR #86401)
dwblaikie wrote: Thanks for continuing to look into this! @cor3ntin - perhaps you've got some more thoughts on this too? https://github.com/llvm/llvm-project/pull/86401 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [C++20] [Modules] [Itanium ABI] Generate the vtable in the module unit of dynamic classes (PR #75912)
@@ -1483,10 +1483,15 @@ void ASTDeclWriter::VisitCXXRecordDecl(CXXRecordDecl
*D) {
if (D->isThisDeclarationADefinition())
Record.AddCXXDefinitionData(D);
- // Store (what we currently believe to be) the key function to avoid
- // deserializing every method so we can compute it.
- if (D->isCompleteDefinition())
-Record.AddDeclRef(Context.getCurrentKeyFunction(D));
+ if (D->isCompleteDefinition()) {
+if (D->getOwningModule() && D->getOwningModule()->isInterfaceOrPartition())
+ Writer.ModularCodegenDecls.push_back(Writer.GetDeclRef(D));
+else {
+ // Store (what we currently believe to be) the key function to avoid
dwblaikie wrote:
Small/isolated patches help with review, reverting, understanding the code in
the future etc - please separate things when practical, and this looks like
such a case.
Changing the ABI is one thing, then optimizing the key function querying for
un-homed vtables seems like a quite different/separate thing (indeed they
aren't ordered, even, right? Like either of these changes could be made
separately and would stand on their own/be beneficial without the other?)
https://github.com/llvm/llvm-project/pull/75912
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [C++20] [Modules] [Itanium ABI] Generate the vtable in the module unit of dynamic classes (PR #75912)
@@ -41,9 +43,10 @@ Base::~Base() {}
// CHECK: @_ZTSW3Mod4Base = constant
// CHECK: @_ZTIW3Mod4Base = constant
-// CHECK-INLINE: @_ZTVW3Mod4Base = linkonce_odr {{.*}}unnamed_addr constant
-// CHECK-INLINE: @_ZTSW3Mod4Base = linkonce_odr {{.*}}constant
-// CHECK-INLINE: @_ZTIW3Mod4Base = linkonce_odr {{.*}}constant
+// With the new Itanium C++ ABI, the linkage of vtables in modules don't need
to be linkonce ODR.
dwblaikie wrote:
right, sorry, was misreading the linkages - I guess `weak` might be applicable?
> “weak” linkage has the same merging semantics as linkonce linkage, except
> that unreferenced globals with weak linkage may not be discarded.
But maybe just normal external linkage is the right thing & we let the linker
GC things if the user asks it to. Fair enough.
https://github.com/llvm/llvm-project/pull/75912
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [C++20] [Modules] Introduce -fexperimental-modules-reduced-bmi (PR #85050)
@@ -3017,6 +3017,7 @@ defm prebuilt_implicit_modules : BoolFOption<"prebuilt-implicit-modules", def fmodule_output_EQ : Joined<["-"], "fmodule-output=">, Flags<[NoXarchOption]>, Visibility<[ClangOption, CC1Option]>, + MarshallingInfoString>, dwblaikie wrote: What's the motivation to include this change in this patch? Could it be separated? https://github.com/llvm/llvm-project/pull/85050 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [C++20] [Modules] Introduce -fexperimental-modules-reduced-bmi (PR #85050)
@@ -193,6 +193,20 @@ DwarfFissionKind getDebugFissionKind(const Driver , const llvm::opt::ArgList , llvm::opt::Arg *); +// Calculate the output path of the module file when compiling a module unit +// with the `-fmodule-output` option or `-fmodule-output=` option specified. +// The behavior is: +// - If `-fmodule-output=` is specfied, then the module file is +// writing to the value. +// - Otherwise if the output object file of the module unit is specified, the +// output path +// of the module file should be the same with the output object file except +// the corresponding suffix. This requires both `-o` and `-c` are specified. +// - Otherwise, the output path of the module file will be the same with the +// input with the corresponding suffix. +llvm::SmallString<256> +getCXX20NamedModuleOutputPath(const llvm::opt::ArgList , dwblaikie wrote: Pulling this work out into a named function could probably be a preliminary NFC commit? https://github.com/llvm/llvm-project/pull/85050 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [DebugInfo] Add flag to only emit referenced member functions (PR #87018)
dwblaikie wrote: Cleaning up some old branches - @pogo59 @rnk who commented on the original https://reviews.llvm.org/D152017 I think the only outstanding thing was the flag name, I've renamed it from `-gincomplete-types` to `-gomit-unreferenced-members` to try to address the feedback. It's not totally precise (it's only member functions that are affected, not member variables, for instance) but seems close enough. https://github.com/llvm/llvm-project/pull/87018 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [DebugInfo] Add flag to only emit referenced member functions (PR #87018)
https://github.com/dwblaikie created
https://github.com/llvm/llvm-project/pull/87018
Complete C++ type information can be quite expensive - and there's
limited value in representing every member function, even those that
can't be called (we don't do similarly for every non-member function
anyway). So add a flag to opt out of this behavior for experimenting
with this more terse behavior.
I think Sony already does this by default, so perhaps with a change to
the defaults, Sony can migrate to this rather than a downstream patch.
This breaks current debuggers in some expected ways - but those
breakages are visible without this feature too. Consider member function
template instantiations - they can't be consistently enumerated in every
translation unit:
a.h:
```
struct t1 {
template
static int f1() {
return i;
}
};
namespace ns {
template
int f1() {
return i;
}
} // namespace ns
```
a.cpp:
```
void f1() {
t1::f1<0>();
ns::f1<0>();
}
```
b.cpp:
```
void f1();
int main() {
f1();
t1::f1<1>();
ns::f1<1>();
}
```
```
(gdb) p ns::f1<0>()
$1 = 0
(gdb) p ns::f1<1>()
$2 = 1
(gdb) p t1::f1<0>()
Couldn't find method t1::f1<0>
(gdb) p t1::f1<1>()
$3 = 1
(gdb) s
f1 () at a.cpp:3
3 t1::f1<0>();
(gdb) p t1::f1<0>()
$4 = 0
(gdb) p t1::f1<1>()
Couldn't find method t1::f1<1>
(gdb)
```
(other similar non-canonical features are implicit special members
(copy/move ctor/assignment operator, default ctor) and nested types (eg:
pimpl idiom, where the nested type is declared-but-not-defined in one
TU, and defined in another TU))
lldb can't parse the template expressions above, so I'm not sure how to
test it there, but I'd guess it has similar problems. (
https://stackoverflow.com/questions/64602475/how-to-print-value-returned-by-template-member-function-in-gdb-lldb-debugging
so... I guess that's just totally not supported in lldb, how
unfortunate. And implicit special members are instantiated implicitly by
lldb, so missing those doesn't tickle the same issue)
Some very rudimentary numbers for a clang debug build:
.debug_info section size:
-g: 476MiB
-g -fdebug-types-section: 357MiB
-g -gomit-unreferenced-members: 340MiB
Though it also means a major reduction in .debug_str size,
-fdebug-types-section doesn't reduce string usage (so the first two
examples have the same .debug_str size, 247MiB), down to 175MiB.
So for total clang binary size (I don't have a quick "debug section size
reduction" on-hand): 1.45 (no type units) GiB -> 1.34 -> 1.22, so it
saves about 120MiB of binary size.
Also open to any riffing on the flag name for sure.
@probinson - would this be an accurate upstreaming of your internal
handling/would you use this functionality? If it wouldn't be useful to you,
it's maybe not worth adding upstream yet - not sure we'll use it at Google, but
if it was useful to you folks and meant other folks could test with it it
seemed maybe useful.
Original Differential Revision: https://reviews.llvm.org/D152017
>From 6834c245205d1e38a615e97217dada3cd941ed03 Mon Sep 17 00:00:00 2001
From: David Blaikie
Date: Fri, 2 Jun 2023 15:04:14 +
Subject: [PATCH] [DebugInfo] Add flag to only emit referenced member functions
Complete C++ type information can be quite expensive - and there's
limited value in representing every member function, even those that
can't be called (we don't do similarly for every non-member function
anyway). So add a flag to opt out of this behavior for experimenting
with this more terse behavior.
I think Sony already does this by default, so perhaps with a change to
the defaults, Sony can migrate to this rather than a downstream patch.
This breaks current debuggers in some expected ways - but those
breakages are visible without this feature too. Consider member function
template instantiations - they can't be consistently enumerated in every
translation unit:
a.h:
```
struct t1 {
template
static int f1() {
return i;
}
};
namespace ns {
template
int f1() {
return i;
}
} // namespace ns
```
a.cpp:
```
void f1() {
t1::f1<0>();
ns::f1<0>();
}
```
b.cpp:
```
void f1();
int main() {
f1();
t1::f1<1>();
ns::f1<1>();
}
```
```
(gdb) p ns::f1<0>()
$1 = 0
(gdb) p ns::f1<1>()
$2 = 1
(gdb) p t1::f1<0>()
Couldn't find method t1::f1<0>
(gdb) p t1::f1<1>()
$3 = 1
(gdb) s
f1 () at a.cpp:3
3 t1::f1<0>();
(gdb) p t1::f1<0>()
$4 = 0
(gdb) p t1::f1<1>()
Couldn't find method t1::f1<1>
(gdb)
```
(other similar non-canonical features are implicit special members
(copy/move ctor/assignment operator, default ctor) and nested types (eg:
pimpl idiom, where the nested type is declared-but-not-defined in one
TU, and defined in another TU))
lldb can't parse the template expressions above, so I'm not sure how to
test it there, but I'd guess it has similar problems. (
https://stackoverflow.com/questions/64602475/how-to-print-value-returned-by-template-member-function-in-gdb-lldb-debugging
so... I guess that's just totally not supported in lldb, how
[clang] [llvm] Add option to generate additional debug info for expression dereferencing pointer to pointers. (PR #81545)
dwblaikie wrote: > > Reading LLVM IR lit CHECK lines from clang codegen is a bit difficult - > > could you include some simple examples (perhaps from the new clang tests in > > this patch) showing the DWARF output just as comments in this review for > > something more easily glanceable? > > Attached is the output of the following command > > `clang ~/llvm-project/clang/test/CodeGenCXX/debug-info-ptr-to-ptr.cpp > -fdebug-info-for-pointer-type -g2 -S -O3 -o /tmp/debug-info-ptr-to-ptr.txt` > > [debug-info-ptr-to-ptr.txt](https://github.com/llvm/llvm-project/files/14659111/debug-info-ptr-to-ptr.txt) Thanks - OK, so this only applies to intermediate structures and arrays (is it useful for arrays? You can't really reorder them - learning that the hot part of an array is the 5th-10th element might be of limited (or at least sufficiently different from the struct layout stuff) value - and it's a more dynamic property/has a runtime parameter component that might be harder to use?) Do you have size impact numbers for this? I wouldn't put this under a (possibly cc1) flag for now unless we've got some pretty compelling data that this doesn't substantially change debug info size, which would be a bit surprising to me - I'd assume this would be quite expensive, but it's just a guess. https://github.com/llvm/llvm-project/pull/81545 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [C++20] [Modules] [Itanium ABI] Generate the vtable in the module unit of dynamic classes (PR #75912)
@@ -60,11 +63,11 @@ int use() {
// CHECK-NOT: @_ZTSW3Mod4Base = constant
// CHECK-NOT: @_ZTIW3Mod4Base = constant
-// CHECK: @_ZTVW3Mod4Base = external unnamed_addr
+// CHECK: @_ZTVW3Mod4Base = external
-// CHECK-INLINE: @_ZTVW3Mod4Base = linkonce_odr {{.*}}unnamed_addr constant
-// CHECK-INLINE: @_ZTSW3Mod4Base = linkonce_odr {{.*}}constant
-// CHECK-INLINE: @_ZTIW3Mod4Base = linkonce_odr {{.*}}constant
+// CHECK-INLINE-NOT: @_ZTSW3Mod4Base = constant
dwblaikie wrote:
`NOT` checks should be pretty broad - for instance these `NOT` checks would've
passed with the old code too (since it was linkonce_odr, not constant) -
perhaps these should just be non-NOT checks, affirmatively checking for the
linkage of these globals (which I assume they are emitted, as declarations - if
they aren't emitted at all, then `NOT: @foo` might be enough, without the ` =
constant`?)
https://github.com/llvm/llvm-project/pull/75912
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [C++20] [Modules] [Itanium ABI] Generate the vtable in the module unit of dynamic classes (PR #75912)
@@ -41,9 +43,10 @@ Base::~Base() {}
// CHECK: @_ZTSW3Mod4Base = constant
// CHECK: @_ZTIW3Mod4Base = constant
-// CHECK-INLINE: @_ZTVW3Mod4Base = linkonce_odr {{.*}}unnamed_addr constant
-// CHECK-INLINE: @_ZTSW3Mod4Base = linkonce_odr {{.*}}constant
-// CHECK-INLINE: @_ZTIW3Mod4Base = linkonce_odr {{.*}}constant
+// With the new Itanium C++ ABI, the linkage of vtables in modules don't need
to be linkonce ODR.
dwblaikie wrote:
Would they benefit from still being linkonce? What if the vtable is never used?
Or do we leave that up to `--gc-sections` linker behavior? (I'm not clear on
when we use linkage to let things be dropped, and when we use the linker
function-sections/data-sections/gc-sections behavior to drop unused stuff)
https://github.com/llvm/llvm-project/pull/75912
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [C++20] [Modules] [Itanium ABI] Generate the vtable in the module unit of dynamic classes (PR #75912)
@@ -1483,10 +1483,15 @@ void ASTDeclWriter::VisitCXXRecordDecl(CXXRecordDecl
*D) {
if (D->isThisDeclarationADefinition())
Record.AddCXXDefinitionData(D);
- // Store (what we currently believe to be) the key function to avoid
- // deserializing every method so we can compute it.
- if (D->isCompleteDefinition())
-Record.AddDeclRef(Context.getCurrentKeyFunction(D));
+ if (D->isCompleteDefinition()) {
+if (D->getOwningModule() && D->getOwningModule()->isInterfaceOrPartition())
+ Writer.ModularCodegenDecls.push_back(Writer.GetDeclRef(D));
+else {
+ // Store (what we currently believe to be) the key function to avoid
dwblaikie wrote:
This seems like a serialization optimization that'd be separate/good to go in
its own PR (make it easier to see what the change is, how it's tested, etc)
separate from this one?
https://github.com/llvm/llvm-project/pull/75912
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [C++20] [Modules] Introduce -fmodules-reduced-bmi (PR #85050)
dwblaikie wrote: > > > > > @iains @dwblaikie Understood. And I thought the major problem is that > > > > > there are a lot flags from clang modules. And it is indeed confusing. > > > > > But given we have to introduce new flags in this case, probably we > > > > > can only try to make it more clear by better documents. > > > > > > > > > > > > So you do not think it possible to restrict the new flag to be > > > > "internal" (i.e. cc1-only) and to put some _temporary_ driver > > > > processing to handle that? (I agree that this is an unusual mechanism, > > > > but the idea is to recognise that the driver-side processing is only > > > > expected to me temporary). > > > > > > > > > I have no idea how can we make that. We still need the users to provide > > > something to enable reduced BMI. And I think it is symmetric to a new > > > flag. > > > > > > What I mean is that (a) we need the internal 'cc1' flag permanently; but > > (b) we do not expect to need a user-facing driver flag permanently. and (c) > > We want to allow users to try this out. > > I am suggesting we could say "to try this out use -Xclang > > -fmodules-reduced-bmi" and have _temporary_ code in the driver to deal with > > the changes needed to phasing. > > If this is not possible. then I suppose I am a bit sad that we keep saying > > 'there are too many modules options' - but yet still add more. however - we > > need to make progress, so if the suggestion here is really a non-starter .. > > then such is life. > > Perhaps the second suggestion (-fexperimental-x options) could be > > discussed at the project level. > > Got your point. But I feel the `-Xclang xxx` style or the > `-fexperimental-xxx` style may make people feel, "oh, this is not ready, > let's wait". Then we may lose more testing opportunity. That seems good to me - these are pretty experimental directions we're going in. We haven't figured out how this stuff should work long term - we are experimenting. > Also I feel such options are symmetric to the existing one. What do you mean by "symmetric"? The difference @iains is trying to highlight is that adding driver flags is a long-term commitment burden - adding cc1 flags, clarifying that these are not long term supported/guaranteed parts of the interface, but a way to experiment with some things until we figure out what the long term supported interface is. Especially if we think the long-term future is always (or, at least by default) reduced BMIs, experimenting with it under a flag until we have confidence in that direction - then maybe just changing the Clang behavior (again, perhaps with a cc1 flag to opt-out as an escape hatch that's intended to be short-term while we figure out whatever bugs lead to the need to use that escape hatch - then when we fixt he bugs and remove the flag, the people on the bleeding edge will need to remove the flag, which is fine/good - rather than leaving these weird flags around forever). https://github.com/llvm/llvm-project/pull/85050 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][Sema] Ignore the parentheses in the guard of DiagnoseUnexpandedParameterPack (PR #86401)
dwblaikie wrote: Yep, the original code still crashes with this PR applied, and the reduced test case comes down to something identical to the code shown in https://github.com/llvm/llvm-project/pull/86401#issuecomment-2024151742 with a stack trace that looks the same as the one caused by the test case this patch is addressing. I tend to think this patch is insufficiently general - that there's any number of ways an unexpanded pack could appear inside an expression and ignoring parens is only one fairly narrow case of a broader issue? https://github.com/llvm/llvm-project/pull/86401 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][Sema] Ignore the parentheses in the guard of DiagnoseUnexpandedParameterPack (PR #86401)
dwblaikie wrote:
> @dwblaikie Feel free to checkout this patch locally and see if it resolves
> the original issue - I won't merge it until you confirm it works or discover
> another issue that goes beyond the scope of this patch. (e.g. another
> aforementioned issue)
First glance it seems it does not resolve the original issue (still seeing a
crash, with this patch applied, on the original source). I'll try to reduce
another test case.
> > Hmm, actually - does this fix address /other/ ways a pack could appear,
> > like this? https://godbolt.org/z/oez8TbGqM
> > Presumably a pack could appear in a variety of expressions, not just
> > wrapped in parens - could be in a function call (as in the above example),
> > or nested arbitrarily more deeply in the expression in any number of other
> > expressions?
>
> It fixes it as well, although with an unused-expression warning.
Oh, that surprises me - not sure how ignoring parens could help the case where
it's a function call...
Oh, I was looking at the wrong parens, it's the line 9 `(ts)` parens. OK,
change /that/ into a function call (and this time I've actually applied this
patch locally and tested this, and it does seem to still crash, even with this
patch applied):
```
template
void f1(Ts... ts);
template
void f1(Ts... ts) {
[&](auto... indexes) {
([&] {
f1(ts);
indexes;
}, ...);
};
}
void f2() { f1(); }
```
But perhaps this ^ is what you're referring to \/ when you mention "if you turn
the capture of the inner lambda to a pack, e.g. `ts`"
> Aside: it crashes again if you turn the capture of the inner lambda to a
> pack, e.g. `ts` - that is a different story and is being tracked in #18873,
> which indicates that the capture of packs is still broken as of now.
But is it a different story? Whet I run the above example, with this patch
applied, I get an identical stack trace:
```
...
#12 0x5637d1f3b0f1
clang::Sema::DiagnoseUnexpandedParameterPack(clang::Expr*,
clang::Sema::UnexpandedParameterPackContext)
#13 0x5637d155c166 clang::Sema::ActOnFinishFullExpr(clang::Expr*,
clang::SourceLocation, bool, bool, bool)
#14 0x5637d19cf202
clang::Sema::ActOnExprStmt(clang::ActionResult, bool)
#15 0x5637d1e352f8 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformStmt(clang::Stmt*,
clang::TreeTransform<(anonymous namespace)::TemplateIn
stantiator>::StmtDiscardKind)
...
```
https://github.com/llvm/llvm-project/pull/86401
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
dwblaikie wrote: > For those files in the repository that do need CRLF endings, I've adopted a > policy of eol=crlf which means that git will store them in history with LF, > but regardless of user config, they'll be checked out in tree with CRLF. This ^ seems a bit problematic to me, though (where the contents of the repo isn't representative of the bits we want - but perhaps it's schrodinger's line endings & it doesn't matter if it's always checked out as crlf - though if we one day converted to another source control system, would that be a problem? are there some things that examine the underlying/"real" repo contents?) - what would be the cost to using `eol=input` as you've done for the mixed line ending case? below \= > There also appears to be a single test, clang/test/Frontend/rewrite-includes-mixed-eol-crlf.[ch] which needs mixed line endings. This one uses eol=input to preserve it as-is. https://github.com/llvm/llvm-project/pull/86318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][Sema] Ignore the parentheses in the guard of DiagnoseUnexpandedParameterPack (PR #86401)
dwblaikie wrote: Hmm, actually - does this fix address /other/ ways a pack could appear, like this? https://godbolt.org/z/oez8TbGqM Presumably a pack could appear in a variety of expressions, not just wrapped in parens - could be in a function call (as in the above example), or nested arbitrarily more deeply in the expression in any number of other expressions? https://github.com/llvm/llvm-project/pull/86401 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][Sema] Ignore the parentheses in the guard of DiagnoseUnexpandedParameterPack (PR #86401)
https://github.com/dwblaikie approved this pull request. LGTM, seems consistent with the previous patch - thanks! https://github.com/llvm/llvm-project/pull/86401 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [C++20] [Modules] Introduce -fgen-reduced-bmi (PR #85050)
dwblaikie wrote: +1 to @iains's comments about being careful about the introduction and naming of driver flags & probably avoid it in this case, if possible, or try to make it clearly experimental. https://github.com/llvm/llvm-project/pull/85050 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] Add option to generate additional debug info for expression dereferencing pointer to pointers. (PR #81545)
dwblaikie wrote: Reading LLVM IR lit CHECK lines from clang codegen is a bit difficult - could you include some simple examples (perhaps from the new clang tests in this patch) showing the DWARF output just as comments in this review for something more easily glanceable? As for flags - I assume this will be way too expensive (do you have some numbers, eg: for a clang build inside google in a release config, or at least optimizations+debug info) to enable by default where we currently enable debug info and debug-info-for-profiling. I'd expect this to be a fairly experimental feature - that it might not be feasible to make this compact enough to enable by default/maybe it's just infeasible to make this compact enough at all at which point we'd want to remove all this functionality. So maybe it goes under a -Xclang/cc1 flag only to start with, to allow exploration/experimentation, but with the expectation that folks won't depend on this until/unless it's able to be made compact enough. https://github.com/llvm/llvm-project/pull/81545 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][Sema] Skip the RequiresExprBodyDecls for lambda dependencies (PR #83997)
dwblaikie wrote: FWIW, @jyknight's example fails to compile with GCC - succeeds with clang 18 release but assert-fails with clang 18 +Asserts build. (not sure about the original/full internal reproduction - we have a way to run compile with assertions enaled, but I'm not sure I'm holding it right... ) https://github.com/llvm/llvm-project/pull/83997 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] f15a790 - Remove use of reference lifetime extension introduced in cdde0d9
Author: David Blaikie
Date: 2024-03-13T16:03:16Z
New Revision: f15a790fd383665ec4defa0711e975476fd8b18b
URL:
https://github.com/llvm/llvm-project/commit/f15a790fd383665ec4defa0711e975476fd8b18b
DIFF:
https://github.com/llvm/llvm-project/commit/f15a790fd383665ec4defa0711e975476fd8b18b.diff
LOG: Remove use of reference lifetime extension introduced in cdde0d9
Rather than dealing with which is more readable, the named variable
doesn't seem to add value here - so omit it.
Added:
Modified:
clang/lib/AST/Interp/Interp.h
Removed:
diff --git a/clang/lib/AST/Interp/Interp.h b/clang/lib/AST/Interp/Interp.h
index bb220657c2dadc..db80e2d59753f8 100644
--- a/clang/lib/AST/Interp/Interp.h
+++ b/clang/lib/AST/Interp/Interp.h
@@ -846,8 +846,7 @@ bool CMP3(InterpState , CodePtr OpPC, const
ComparisonCategoryInfo *CmpInfo) {
CmpInfo->getValueInfo(CmpInfo->makeWeakResult(CmpResult));
assert(CmpValueInfo);
assert(CmpValueInfo->hasValidIntValue());
- const APSInt = CmpValueInfo->getIntValue();
- return SetThreeWayComparisonField(S, OpPC, P, IntValue);
+ return SetThreeWayComparisonField(S, OpPC, P, CmpValueInfo->getIntValue());
}
template ::T>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [llvm] [llvm][Support] Add and use errnoAsErrorCode (PR #84423)
dwblaikie wrote: Cool cool - thanks for the extra context! https://github.com/llvm/llvm-project/pull/84423 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [llvm] [llvm][Support] Add and use errnoAsErrorCode (PR #84423)
https://github.com/dwblaikie approved this pull request. Sounds OK to me. (though several other instances of system_category are touched in this patch - out of curiosity, how are those different from the one fixed case you called out in JSONTransport.cpp? Are the other uses of system_category sort of more benign in some way? Or equally buggy/fixed? Guess there's no practical test coverage for this? Not worth unit testing JSONTransport to inspect its error code, etc, probably) https://github.com/llvm/llvm-project/pull/84423 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CLANG][DWARF] Do not emit -ggnu-pubnames for LLDB tuning, unless -ggnu-pubnames is specified. (PR #83331)
https://github.com/dwblaikie approved this pull request. Yeah, still not sure why something like `%clang -### -c -target x86_64 -g -gsplit-dwarf %s` wouldn't change behavior on a darwin host and cause the check for gnu-pubnames to fail there but if you say that works, guess that's OK & if it doesn't, buildbots will tell us. https://github.com/llvm/llvm-project/pull/83331 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [lld] [lldb] [llvm] [mlir] Rename llvm::ThreadPool -> llvm::DefaultThreadPool (NFC) (PR #83702)
dwblaikie wrote: Oh, maybe issues related to layered patches - this is intended to be submitted after the introduction of the ThreadPoolInterface? But includes those changes in this review at the moment (I still haven't figured out what we're doing for dependent changes - and I thought the ThreadPoolInterface-introducing patch was already in - so not sure why it appears in this patch too) https://github.com/llvm/llvm-project/pull/83702 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [lld] [lldb] [llvm] [mlir] Rename llvm::ThreadPool -> llvm::DefaultThreadPool (NFC) (PR #83702)
dwblaikie wrote: > I did the first part of the renaming @dwblaikie : looks good? Hmm - this patch still seems to have both renamings in it, if I'm reading the PR correctly? I take it from the subject that isn't the intent/the intent is that his patch only does the ThreadPool->DefaultThreadPool change? https://github.com/llvm/llvm-project/pull/83702 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [RISCV] Improve error message when the extension is not supported (PR #83989)
dwblaikie wrote: perhaps the llvm libSupport prats of this change should be unit tested in LLVM, rather than only tested indirectly in clang? https://github.com/llvm/llvm-project/pull/83989 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Diagnose config_macros before building modules (PR #83641)
@@ -1591,6 +1591,14 @@ static void checkConfigMacro(Preprocessor , StringRef
ConfigMacro,
}
}
+static void checkConfigMacros(Preprocessor , Module *M,
+ SourceLocation ImportLoc) {
+ clang::Module *TopModule = M->getTopLevelModule();
+ for (unsigned I = 0, N = TopModule->ConfigMacros.size(); I != N; ++I) {
dwblaikie wrote:
range based for loop?
https://github.com/llvm/llvm-project/pull/83641
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [HIP] add --offload-compression-level= option (PR #83605)
dwblaikie wrote: > level 20 is a sweet spot for both compression rate and compression time I wonder how much this is overfitting for kernels of a particular size, though? (is it making the window just large enough that there's some "memory" from one kernel to the next - but a slightly larger kernel would cause it to fail to see the similarities of two or more kernels - and equally, would a lower level have a smaller window which would be adequate for smaller kernels?) If level does imply window size and that does imply the size of the kernels that can be efficiently compressed across multiple similar copies - it might be interesting to know what range of kernel sizes fit in the new default, and if that size is representative of the majority of kernels. https://github.com/llvm/llvm-project/pull/83605 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CLANG][DWARF] Do not emit -ggnu-pubnames for LLDB tuning, unless -ggnu-pubnames is specified. (PR #83331)
@@ -11,7 +11,6 @@ // NOINLINE-NOT: "-fsplit-dwarf-inlining" // SPLIT-NOT: "-dumpdir" // SPLIT: "-debug-info-kind=constructor" -// SPLIT-SAME: "-ggnu-pubnames" dwblaikie wrote: Nah, I think that's probably fine without an explicit `-ggdb` test - though with the test as-is, wouldn't it fail on macos machines, where they'll implicitly default to `-glldb` and so `-ggnu-pubnames` won't get passed, so the check on line 14 of split-debug.c will fail? So maybe that has to be removed from there and only checked via explicit tuning flags, in which case adding a `-ggdb` test would be necessary (though it could share the CHECK lines from the `-glldb -ggnu-pubnames` test) https://github.com/llvm/llvm-project/pull/83331 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CLANG][DWARF] Do not emit -ggnu-pubnames for LLDB tuning, unless -ggnu-pubnames is specified. (PR #83331)
@@ -11,7 +11,6 @@ // NOINLINE-NOT: "-fsplit-dwarf-inlining" // SPLIT-NOT: "-dumpdir" // SPLIT: "-debug-info-kind=constructor" -// SPLIT-SAME: "-ggnu-pubnames" dwblaikie wrote: > As discussed in original PR, #82840 , the idea is if -gsplit-dwarf with > -glldb is used the -ggnu-pubnames wouldn't be passed in. Since LLDB doesn't > benefit from it, and it just uses space. Yep, I'm with you on all of that. > A fix from original is if someone does specify -ggnu-pubnames it will be > generated. Sure. > I added a test for it on linux side. Added a test for what on the linux side? And where is that test? > There is also a test on mac side that used -gsplit-dwarf with -ggnu-pubnames. Right, I see that test here in this `split-debug.c` file at the end. Checking for the absence of `-ggnu-pubnames` if `-gsplit-dwarf -g -glldb` is passed, and the presence if `-gsplit-dwarf -g -glldb -ggnu-pubnames` is passed. So I'm with you there. But what i don't understand is that, with the removal of the `// SPLIT-SAME: "-ggnu-pubnames"` line above - what tests that, for instance `-gsplit-dwarf -g -ggdb` does use `-ggnu-pubnames`? (said another way: If we removed the any code that added `-ggnu-pubnames` when `-gsplit-dwarf` is specified, which lit tests would fail?) https://github.com/llvm/llvm-project/pull/83331 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Sema] -Wpointer-bool-conversion: suppress lambda function pointer conversion diagnostic during instantiation (PR #83497)
dwblaikie wrote: Presumably similar things might show up in macros? But can cross that bridge when we come to it. Perhaps we have some/could use some generic utility for this sort of contextual warning "if these things are literally written next to each other, warn, but if they came to be via template instantiation, macro, (something else?) then don't" because that sort of situation shows up pretty regularly in diagnostics, I think... https://github.com/llvm/llvm-project/pull/83497 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CLANG][DWARF] Do not emit -ggnu-pubnames for split dwarf version 5 (PR #83331)
@@ -11,7 +11,6 @@ // NOINLINE-NOT: "-fsplit-dwarf-inlining" // SPLIT-NOT: "-dumpdir" // SPLIT: "-debug-info-kind=constructor" -// SPLIT-SAME: "-ggnu-pubnames" dwblaikie wrote: has this lost coverage for non `-glldb` configurations? (like would we still have test failures if we had a bug where `-ggnu-pubnames` wasn't passed on Linux when using `-gsplit-dwarf`?) https://github.com/llvm/llvm-project/pull/83331 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][DebugInfo] Use CGDebugInfo::createFile in CGDebugInfo::CreateCompileUnit (#83174) (PR #83175)
dwblaikie wrote: Some test coverage would be good to help demonstrate the issue/fix https://github.com/llvm/llvm-project/pull/83175 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CLANG][DWARF] Do not emit -ggnu-pubnames for split dwarf version 5. (PR #82840)
https://github.com/dwblaikie approved this pull request. https://github.com/llvm/llvm-project/pull/82840 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][NFC] Trim license header comments to 81 characters (PR #82919)
dwblaikie wrote: +1 to @pogo59's comment about pruning complete paths - I suspect they're in the minority. Might be worth checking whether the `===` at the start and end is markup for any particular thing (I /think/ the `-*- C++ -*-` is load bearing for some editors to inform them this `.h` file is C++ not C, so I'm not sure about some other features of those top-of-file comments). https://github.com/llvm/llvm-project/pull/82919 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [attributes][analyzer] Generalize [[clang::suppress]] to declarations. (PR #80371)
dwblaikie wrote: Commit without precommit review is fine, especially from a code owner - if you only wanted the PR for automated precommit checking, you can add the `skip-precommit-approval` to indicate that the PR isn't intended for precommit review. But, yeah, otherwise it's good that if something /is/ sent for review, that it's not committed until it is reviewed. (code owners/domain experts sometimes get into the niche where this gets a bit fuzzy and it's "here's an idea I had, anyone got better ones/thoughts on this, otherwise I'll go ahead with it" - but yeah, usually the simplest way to deal with that is to have someone else you were asking say "yeah, sounds OK, I don't have any particularly better ideas about how to do this", etc) https://github.com/llvm/llvm-project/pull/80371 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [compiler-rt] [flang] [libclc] [libcxx] [lld] [lldb] [llvm] [NFC] Remove trailing whitespace across all non-test related files (PR #82838)
dwblaikie wrote: The dev policy says "Avoid committing formatting- or whitespace-only changes outside of code you plan to make subsequent changes to." - I think it's reasonable to consider changing this, but probably under the "clang-format everything" or a similar discussion (broad discussion before we worry about making pull requests https://github.com/llvm/llvm-project/pull/82838 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CLANG][DWARF] Do not emit -ggnu-pubnames for split dwarf version 5. (PR #82840)
dwblaikie wrote: If you're debugging with lldb you should probably be using -glldb - if you're doing that, certainly gnu-pubnames should not be enabled by default or implicitly by gsplit-dwarf. I'd say -gsplit-dwarf -glldb probably doesn't need any names/accelerator table by default (any more than the non-split dwarf should default enable names in -glldb - which, maybe it should be, since it is the default on apple platforms, I think?) - split dwarf for gcc needed to (& I think should still be the default, under -ggdb (the default on Linux etc)) enable gnuoubnames by default for correctness (gdb would assume it was present/accurate and fail lookups, rather than falling back to slow performance/exhaustive search) https://github.com/llvm/llvm-project/pull/82840 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [attributes][analyzer] Generalize [[clang::suppress]] to declarations. (PR #80371)
dwblaikie wrote: did I miss something - it looks like this was committed without approval? https://github.com/llvm/llvm-project/pull/80371 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [docs] [C++20] [Modules] Ideas for transitioning to modules (PR #80687)
https://github.com/dwblaikie approved this pull request. Seems ok https://github.com/llvm/llvm-project/pull/80687 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [lldb] [c++20] P1907R1: Support for generalized non-type template arguments of scalar type. (PR #78041)
@@ -5401,6 +5409,8 @@ std::string CGDebugInfo::GetName(const Decl *D, bool
Qualified) const {
// feasible some day.
return TA.getAsIntegral().getBitWidth() <= 64 &&
IsReconstitutableType(TA.getIntegralType());
+ case TemplateArgument::StructuralValue:
+return false;
dwblaikie wrote:
I did finally take a look at this - I think the Clang side of things is fine -
if anything improvements could be made to LLVM to be able to lower constants to
DWARF for a wider variety of values.
eg: For the `float` example, the IR is:
```
!8 = !DITemplateValueParameter(name: "F", type: !9, value: float 1.00e+00)
```
But the DWARF backend can't handle the float constant - the handling is in
`DwarfUnit::constructTemplateValueParameterDIE` (in
llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp) and currently only handles
ConstantInt (for basic stuff - bools, ints, etc) and GlobalValue (for pointer
non-type template parameters).
So for these new floats and such, the DWARF doesn't include the value, only the
type.
GCC uses this encoding, for instance:
```
0x002b: DW_TAG_template_value_parameter [3] (0x001e)
DW_AT_name [DW_FORM_string] ("F")
DW_AT_type [DW_FORM_ref4] (cu + 0x004d => {0x004d}
"float")
DW_AT_const_value [DW_FORM_block1](<0x04> 00 00 80 3f )
```
https://github.com/llvm/llvm-project/pull/78041
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [docs] [C++20] [Modules] Ideas for transitioning to modules (PR #80687)
@@ -610,6 +610,345 @@ the following style significantly:
The key part of the tip is to reduce the duplications from the text includes.
+Ideas for converting to modules
+---
+
+For new libraries, we encourage them to use modules completely from day one if
possible.
+This will be pretty helpful to make the whole ecosystems to get ready.
+
+For many existing libraries, it may be a breaking change to refactor themselves
+into modules completely. So that many existing libraries need to provide
headers and module
+interfaces for a while to not break existing users.
+Here we provide some ideas to ease the transition process for existing
libraries.
+**Note that the this section is only about helping ideas instead of
requirement from clang**.
+
+Let's start with the case that there is no dependency or no dependent
libraries providing
+modules for your library.
+
+ABI non-breaking styles
+~~~
+
+export-using style
+^^
+
+.. code-block:: c++
+
+ module;
+ #include "header_1.h"
+ #include "header_2.h"
+ ...
+ #include "header_n.h"
+ export module your_library;
+ export namespace your_namespace {
+using decl_1;
+using decl_2;
+...
+using decl_n;
+ }
+
+As the example shows, you need to include all the headers containing
declarations needs
+to be exported and `using` such declarations in an `export` block. Then,
basically,
+we're done.
+
+export extern-C++ style
+^^^
+
+.. code-block:: c++
+
+ module;
+ #include "third_party/A/headers.h"
+ #include "third_party/B/headers.h"
+ ...
+ #include "third_party/Z/headers.h"
+ export module your_library;
+ #define IN_MODULE_INTERFACE
+ extern "C++" {
+#include "header_1.h"
+#include "header_2.h"
+...
+#include "header_n.h"
+ }
+
+Then in your headers (from ``header_1.h`` to ``header_n.h``), you need to
define the macro:
+
+.. code-block:: c++
+
+ #ifdef IN_MODULE_INTERFACE
+ #define EXPORT export
+ #else
+ #define EXPORT
+ #endif
+
+And you should put ``EXPORT`` to the beginning of the declarations you want to
export.
+
+Also it is suggested to refactor your headers to include thirdparty headers
conditionally:
+
+.. code-block:: c++
+
+ + #ifndef IN_MODULE_INTERFACE
+ #include "third_party/A/headers.h"
+ + #endif
+
+ #include "header_x.h"
+
+ ...
+
+This may be helpful to get better diagnostic messages if you forgot to update
your module
+interface unit file during maintaining.
+
+The reasoning for the practice is that the declarations in the language
linkage are considered
+to be attached to the global module. So the ABI of your library in the modular
version
+wouldn't change.
+
+While this style looks not as convenient as the export-using style, it is
easier to convert
+to other styles.
+
+ABI breaking style
+~~
+
+The term ``ABI breaking`` sounds terrifying generally. But you may want it
here if you want
+to force your users to introduce your library in a consistent way. E.g., they
either include
+your headers all the way or import your modules all the way.
+The style prevents the users to include your headers and import your modules
at the same time
+in the same repo.
dwblaikie wrote:
What's the motivation for doing this? Given the challenges it presents to
downstream usage of the library?
https://github.com/llvm/llvm-project/pull/80687
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][Sema] Subclass `-Wshorten-64-to-32` under `-Wimplicit-int-conversion` (PR #80814)
dwblaikie wrote: Can't seem to load the image - and generally a copy/paste of the text is more usable for everyone than a screenshot. If you could include the copy/pasted text, that'd be handy, thanks! https://github.com/llvm/llvm-project/pull/80814 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [docs] [C++20] [Modules] Ideas for transitioning to modules (PR #80687)
@@ -610,6 +610,345 @@ the following style significantly:
The key part of the tip is to reduce the duplications from the text includes.
+Ideas for converting to modules
+---
+
+For new libraries, we encourage them to use modules completely from day one if
possible.
+This will be pretty helpful to make the whole ecosystems to get ready.
+
+For many existing libraries, it may be a breaking change to refactor themselves
+into modules completely. So that many existing libraries need to provide
headers and module
+interfaces for a while to not break existing users.
+Here we provide some ideas to ease the transition process for existing
libraries.
+**Note that the this section is only about helping ideas instead of
requirement from clang**.
+
+Let's start with the case that there is no dependency or no dependent
libraries providing
+modules for your library.
+
+ABI non-breaking styles
+~~~
+
+export-using style
+^^
+
+.. code-block:: c++
+
+ module;
+ #include "header_1.h"
+ #include "header_2.h"
+ ...
+ #include "header_n.h"
+ export module your_library;
+ export namespace your_namespace {
+using decl_1;
+using decl_2;
+...
+using decl_n;
+ }
+
+As the example shows, you need to include all the headers containing
declarations needs
+to be exported and `using` such declarations in an `export` block. Then,
basically,
+we're done.
+
+export extern-C++ style
+^^^
+
+.. code-block:: c++
+
+ module;
+ #include "third_party/A/headers.h"
+ #include "third_party/B/headers.h"
+ ...
+ #include "third_party/Z/headers.h"
+ export module your_library;
+ #define IN_MODULE_INTERFACE
+ extern "C++" {
+#include "header_1.h"
+#include "header_2.h"
+...
+#include "header_n.h"
+ }
+
+Then in your headers (from ``header_1.h`` to ``header_n.h``), you need to
define the macro:
+
+.. code-block:: c++
+
+ #ifdef IN_MODULE_INTERFACE
+ #define EXPORT export
+ #else
+ #define EXPORT
+ #endif
+
+And you should put ``EXPORT`` to the beginning of the declarations you want to
export.
+
+Also it is suggested to refactor your headers to include thirdparty headers
conditionally:
+
+.. code-block:: c++
+
+ + #ifndef IN_MODULE_INTERFACE
+ #include "third_party/A/headers.h"
+ + #endif
+
+ #include "header_x.h"
+
+ ...
+
+This may be helpful to get better diagnostic messages if you forgot to update
your module
+interface unit file during maintaining.
dwblaikie wrote:
```suggestion
interface unit file to match changes to the headers in the future.
```
https://github.com/llvm/llvm-project/pull/80687
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [docs] [C++20] [Modules] Ideas for transitioning to modules (PR #80687)
@@ -610,6 +610,345 @@ the following style significantly:
The key part of the tip is to reduce the duplications from the text includes.
+Ideas for converting to modules
+---
+
+For new libraries, we encourage them to use modules completely from day one if
possible.
+This will be pretty helpful to make the whole ecosystems to get ready.
+
+For many existing libraries, it may be a breaking change to refactor themselves
+into modules completely. So that many existing libraries need to provide
headers and module
+interfaces for a while to not break existing users.
+Here we provide some ideas to ease the transition process for existing
libraries.
+**Note that the this section is only about helping ideas instead of
requirement from clang**.
+
+Let's start with the case that there is no dependency or no dependent
libraries providing
+modules for your library.
+
+ABI non-breaking styles
+~~~
+
+export-using style
+^^
+
+.. code-block:: c++
+
+ module;
+ #include "header_1.h"
+ #include "header_2.h"
+ ...
+ #include "header_n.h"
+ export module your_library;
+ export namespace your_namespace {
+using decl_1;
+using decl_2;
+...
+using decl_n;
+ }
+
+As the example shows, you need to include all the headers containing
declarations needs
+to be exported and `using` such declarations in an `export` block. Then,
basically,
+we're done.
+
+export extern-C++ style
+^^^
+
+.. code-block:: c++
+
+ module;
+ #include "third_party/A/headers.h"
+ #include "third_party/B/headers.h"
+ ...
+ #include "third_party/Z/headers.h"
+ export module your_library;
+ #define IN_MODULE_INTERFACE
+ extern "C++" {
+#include "header_1.h"
+#include "header_2.h"
+...
+#include "header_n.h"
+ }
+
+Then in your headers (from ``header_1.h`` to ``header_n.h``), you need to
define the macro:
+
+.. code-block:: c++
+
+ #ifdef IN_MODULE_INTERFACE
+ #define EXPORT export
+ #else
+ #define EXPORT
+ #endif
+
+And you should put ``EXPORT`` to the beginning of the declarations you want to
export.
+
+Also it is suggested to refactor your headers to include thirdparty headers
conditionally:
+
+.. code-block:: c++
+
+ + #ifndef IN_MODULE_INTERFACE
+ #include "third_party/A/headers.h"
+ + #endif
+
+ #include "header_x.h"
+
+ ...
+
+This may be helpful to get better diagnostic messages if you forgot to update
your module
+interface unit file during maintaining.
+
+The reasoning for the practice is that the declarations in the language
linkage are considered
+to be attached to the global module. So the ABI of your library in the modular
version
+wouldn't change.
+
+While this style looks not as convenient as the export-using style, it is
easier to convert
+to other styles.
+
+ABI breaking style
+~~
+
+The term ``ABI breaking`` sounds terrifying generally. But you may want it
here if you want
+to force your users to introduce your library in a consistent way. E.g., they
either include
+your headers all the way or import your modules all the way.
+The style prevents the users to include your headers and import your modules
at the same time
+in the same repo.
+
+The pattern for ABI breaking style is similar with export extern-C++ style.
+
+.. code-block:: c++
+
+ module;
+ #include "third_party/A/headers.h"
+ #include "third_party/B/headers.h"
+ ...
+ #include "third_party/Z/headers.h"
+ export module your_library;
+ #define IN_MODULE_INTERFACE
+ #include "header_1.h"
+ #include "header_2.h"
+ ...
+ #include "header_n.h"
+
+ #if the number of .cpp files in your project are small
+ module :private;
+ #include "source_1.cpp"
+ #include "source_2.cpp"
+ ...
+ #include "source_n.cpp"
+ #else // the number of .cpp files in your project are a lot
+ // Using all the declarations from thirdparty libraries which are
+ // used in the .cpp files.
+ namespace third_party_namespace {
+using third_party_decl_used_in_cpp_1;
+using third_party_decl_used_in_cpp_2;
+...
+using third_party_decl_used_in_cpp_n;
+ }
+ #endif
+
+(And add `EXPORT` and conditional include to the headers as suggested in the
export
+extern-C++ style section)
+
+Remember that the ABI get changed and we need to compile our source files into
the
+new ABI format. This is the job of the additional part of the interface unit:
+
+.. code-block:: c++
+
+ #if the number of .cpp files in your project are small
+ module :private;
+ #include "source_1.cpp"
+ #include "source_2.cpp"
+ ...
+ #include "source_n.cpp"
+ #else // the number of .cpp files in your project are a lot
+ // Using all the declarations from thirdparty libraries which are
+ // used in the .cpp files.
+ namespace third_party_namespace {
+using third_party_decl_used_in_cpp_1;
+using third_party_decl_used_in_cpp_2;
+...
+using third_party_decl_used_in_cpp_n;
+ }
+ #endif
+
+In case the
[clang] [docs] [C++20] [Modules] Ideas for transitioning to modules (PR #80687)
@@ -610,6 +610,345 @@ the following style significantly:
The key part of the tip is to reduce the duplications from the text includes.
+Ideas for converting to modules
+---
+
+For new libraries, we encourage them to use modules completely from day one if
possible.
+This will be pretty helpful to make the whole ecosystems to get ready.
+
+For many existing libraries, it may be a breaking change to refactor themselves
+into modules completely. So that many existing libraries need to provide
headers and module
+interfaces for a while to not break existing users.
+Here we provide some ideas to ease the transition process for existing
libraries.
+**Note that the this section is only about helping ideas instead of
requirement from clang**.
+
+Let's start with the case that there is no dependency or no dependent
libraries providing
+modules for your library.
+
+ABI non-breaking styles
+~~~
+
+export-using style
+^^
+
+.. code-block:: c++
+
+ module;
+ #include "header_1.h"
+ #include "header_2.h"
+ ...
+ #include "header_n.h"
+ export module your_library;
+ export namespace your_namespace {
+using decl_1;
+using decl_2;
+...
+using decl_n;
+ }
+
+As the example shows, you need to include all the headers containing
declarations needs
+to be exported and `using` such declarations in an `export` block. Then,
basically,
+we're done.
+
+export extern-C++ style
+^^^
+
+.. code-block:: c++
+
+ module;
+ #include "third_party/A/headers.h"
+ #include "third_party/B/headers.h"
+ ...
+ #include "third_party/Z/headers.h"
+ export module your_library;
+ #define IN_MODULE_INTERFACE
+ extern "C++" {
+#include "header_1.h"
+#include "header_2.h"
+...
+#include "header_n.h"
+ }
+
+Then in your headers (from ``header_1.h`` to ``header_n.h``), you need to
define the macro:
+
+.. code-block:: c++
+
+ #ifdef IN_MODULE_INTERFACE
+ #define EXPORT export
+ #else
+ #define EXPORT
+ #endif
+
+And you should put ``EXPORT`` to the beginning of the declarations you want to
export.
+
+Also it is suggested to refactor your headers to include thirdparty headers
conditionally:
+
+.. code-block:: c++
+
+ + #ifndef IN_MODULE_INTERFACE
+ #include "third_party/A/headers.h"
+ + #endif
+
+ #include "header_x.h"
+
+ ...
+
+This may be helpful to get better diagnostic messages if you forgot to update
your module
+interface unit file during maintaining.
+
+The reasoning for the practice is that the declarations in the language
linkage are considered
+to be attached to the global module. So the ABI of your library in the modular
version
+wouldn't change.
+
+While this style looks not as convenient as the export-using style, it is
easier to convert
+to other styles.
+
+ABI breaking style
+~~
+
+The term ``ABI breaking`` sounds terrifying generally. But you may want it
here if you want
+to force your users to introduce your library in a consistent way. E.g., they
either include
+your headers all the way or import your modules all the way.
+The style prevents the users to include your headers and import your modules
at the same time
+in the same repo.
dwblaikie wrote:
I would imagine this is generally an anti-goal for most people, or would create
maintenance challenges - because if your library is used by other libraries -
some of those users might be using C++20 modules, and some might not be. And
then if you want to depend on all those libraries together in some other
library/program, it'd be unfortunate if you were stuck/not able to do that due
to the very opinionated original library that said "only use headers or only
use modules, don't mix and match".
https://github.com/llvm/llvm-project/pull/80687
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [docs] [C++20] [Modules] Ideas for transitioning to modules (PR #80687)
@@ -610,6 +610,345 @@ the following style significantly:
The key part of the tip is to reduce the duplications from the text includes.
+Ideas for converting to modules
+---
+
+For new libraries, we encourage them to use modules completely from day one if
possible.
+This will be pretty helpful to make the whole ecosystems to get ready.
+
+For many existing libraries, it may be a breaking change to refactor themselves
+into modules completely. So that many existing libraries need to provide
headers and module
+interfaces for a while to not break existing users.
+Here we provide some ideas to ease the transition process for existing
libraries.
+**Note that the this section is only about helping ideas instead of
requirement from clang**.
+
+Let's start with the case that there is no dependency or no dependent
libraries providing
+modules for your library.
+
+ABI non-breaking styles
+~~~
+
+export-using style
+^^
+
+.. code-block:: c++
+
+ module;
+ #include "header_1.h"
+ #include "header_2.h"
+ ...
+ #include "header_n.h"
+ export module your_library;
+ export namespace your_namespace {
+using decl_1;
+using decl_2;
+...
+using decl_n;
+ }
+
+As the example shows, you need to include all the headers containing
declarations needs
+to be exported and `using` such declarations in an `export` block. Then,
basically,
+we're done.
+
+export extern-C++ style
+^^^
+
+.. code-block:: c++
+
+ module;
+ #include "third_party/A/headers.h"
+ #include "third_party/B/headers.h"
+ ...
+ #include "third_party/Z/headers.h"
+ export module your_library;
+ #define IN_MODULE_INTERFACE
+ extern "C++" {
+#include "header_1.h"
+#include "header_2.h"
+...
+#include "header_n.h"
+ }
+
+Then in your headers (from ``header_1.h`` to ``header_n.h``), you need to
define the macro:
+
+.. code-block:: c++
+
+ #ifdef IN_MODULE_INTERFACE
+ #define EXPORT export
+ #else
+ #define EXPORT
+ #endif
+
+And you should put ``EXPORT`` to the beginning of the declarations you want to
export.
+
+Also it is suggested to refactor your headers to include thirdparty headers
conditionally:
+
+.. code-block:: c++
+
+ + #ifndef IN_MODULE_INTERFACE
+ #include "third_party/A/headers.h"
+ + #endif
+
+ #include "header_x.h"
+
+ ...
+
+This may be helpful to get better diagnostic messages if you forgot to update
your module
+interface unit file during maintaining.
+
+The reasoning for the practice is that the declarations in the language
linkage are considered
+to be attached to the global module. So the ABI of your library in the modular
version
+wouldn't change.
+
+While this style looks not as convenient as the export-using style, it is
easier to convert
+to other styles.
+
+ABI breaking style
+~~
+
+The term ``ABI breaking`` sounds terrifying generally. But you may want it
here if you want
+to force your users to introduce your library in a consistent way. E.g., they
either include
+your headers all the way or import your modules all the way.
+The style prevents the users to include your headers and import your modules
at the same time
+in the same repo.
+
+The pattern for ABI breaking style is similar with export extern-C++ style.
+
+.. code-block:: c++
+
+ module;
+ #include "third_party/A/headers.h"
+ #include "third_party/B/headers.h"
+ ...
+ #include "third_party/Z/headers.h"
+ export module your_library;
+ #define IN_MODULE_INTERFACE
+ #include "header_1.h"
+ #include "header_2.h"
+ ...
+ #include "header_n.h"
+
+ #if the number of .cpp files in your project are small
+ module :private;
+ #include "source_1.cpp"
+ #include "source_2.cpp"
+ ...
+ #include "source_n.cpp"
+ #else // the number of .cpp files in your project are a lot
+ // Using all the declarations from thirdparty libraries which are
+ // used in the .cpp files.
+ namespace third_party_namespace {
+using third_party_decl_used_in_cpp_1;
+using third_party_decl_used_in_cpp_2;
+...
+using third_party_decl_used_in_cpp_n;
+ }
+ #endif
+
+(And add `EXPORT` and conditional include to the headers as suggested in the
export
+extern-C++ style section)
+
+Remember that the ABI get changed and we need to compile our source files into
the
+new ABI format. This is the job of the additional part of the interface unit:
+
+.. code-block:: c++
+
+ #if the number of .cpp files in your project are small
+ module :private;
+ #include "source_1.cpp"
+ #include "source_2.cpp"
+ ...
+ #include "source_n.cpp"
+ #else // the number of .cpp files in your project are a lot
+ // Using all the declarations from thirdparty libraries which are
+ // used in the .cpp files.
+ namespace third_party_namespace {
+using third_party_decl_used_in_cpp_1;
+using third_party_decl_used_in_cpp_2;
+...
+using third_party_decl_used_in_cpp_n;
+ }
+ #endif
+
+In case the
[clang] [docs] [C++20] [Modules] Ideas for transitioning to modules (PR #80687)
@@ -610,6 +610,345 @@ the following style significantly:
The key part of the tip is to reduce the duplications from the text includes.
+Ideas for converting to modules
+---
+
+For new libraries, we encourage them to use modules completely from day one if
possible.
+This will be pretty helpful to make the whole ecosystems to get ready.
+
+For many existing libraries, it may be a breaking change to refactor themselves
+into modules completely. So that many existing libraries need to provide
headers and module
+interfaces for a while to not break existing users.
+Here we provide some ideas to ease the transition process for existing
libraries.
+**Note that the this section is only about helping ideas instead of
requirement from clang**.
+
+Let's start with the case that there is no dependency or no dependent
libraries providing
+modules for your library.
+
+ABI non-breaking styles
+~~~
+
+export-using style
+^^
+
+.. code-block:: c++
+
+ module;
+ #include "header_1.h"
+ #include "header_2.h"
+ ...
+ #include "header_n.h"
+ export module your_library;
+ export namespace your_namespace {
+using decl_1;
+using decl_2;
+...
+using decl_n;
+ }
+
+As the example shows, you need to include all the headers containing
declarations needs
+to be exported and `using` such declarations in an `export` block. Then,
basically,
+we're done.
+
+export extern-C++ style
+^^^
+
+.. code-block:: c++
+
+ module;
+ #include "third_party/A/headers.h"
+ #include "third_party/B/headers.h"
+ ...
+ #include "third_party/Z/headers.h"
+ export module your_library;
+ #define IN_MODULE_INTERFACE
+ extern "C++" {
+#include "header_1.h"
+#include "header_2.h"
+...
+#include "header_n.h"
+ }
+
+Then in your headers (from ``header_1.h`` to ``header_n.h``), you need to
define the macro:
+
+.. code-block:: c++
+
+ #ifdef IN_MODULE_INTERFACE
+ #define EXPORT export
+ #else
+ #define EXPORT
+ #endif
+
+And you should put ``EXPORT`` to the beginning of the declarations you want to
export.
+
+Also it is suggested to refactor your headers to include thirdparty headers
conditionally:
+
+.. code-block:: c++
+
+ + #ifndef IN_MODULE_INTERFACE
+ #include "third_party/A/headers.h"
+ + #endif
+
+ #include "header_x.h"
+
+ ...
+
+This may be helpful to get better diagnostic messages if you forgot to update
your module
+interface unit file during maintaining.
+
+The reasoning for the practice is that the declarations in the language
linkage are considered
+to be attached to the global module. So the ABI of your library in the modular
version
+wouldn't change.
+
+While this style looks not as convenient as the export-using style, it is
easier to convert
+to other styles.
+
+ABI breaking style
+~~
+
+The term ``ABI breaking`` sounds terrifying generally. But you may want it
here if you want
+to force your users to introduce your library in a consistent way. E.g., they
either include
+your headers all the way or import your modules all the way.
+The style prevents the users to include your headers and import your modules
at the same time
+in the same repo.
+
+The pattern for ABI breaking style is similar with export extern-C++ style.
+
+.. code-block:: c++
+
+ module;
+ #include "third_party/A/headers.h"
+ #include "third_party/B/headers.h"
+ ...
+ #include "third_party/Z/headers.h"
+ export module your_library;
+ #define IN_MODULE_INTERFACE
+ #include "header_1.h"
+ #include "header_2.h"
+ ...
+ #include "header_n.h"
+
+ #if the number of .cpp files in your project are small
+ module :private;
+ #include "source_1.cpp"
+ #include "source_2.cpp"
+ ...
+ #include "source_n.cpp"
+ #else // the number of .cpp files in your project are a lot
+ // Using all the declarations from thirdparty libraries which are
+ // used in the .cpp files.
+ namespace third_party_namespace {
+using third_party_decl_used_in_cpp_1;
+using third_party_decl_used_in_cpp_2;
+...
+using third_party_decl_used_in_cpp_n;
+ }
+ #endif
+
+(And add `EXPORT` and conditional include to the headers as suggested in the
export
+extern-C++ style section)
+
+Remember that the ABI get changed and we need to compile our source files into
the
+new ABI format. This is the job of the additional part of the interface unit:
+
+.. code-block:: c++
+
+ #if the number of .cpp files in your project are small
+ module :private;
+ #include "source_1.cpp"
+ #include "source_2.cpp"
+ ...
+ #include "source_n.cpp"
+ #else // the number of .cpp files in your project are a lot
+ // Using all the declarations from thirdparty libraries which are
+ // used in the .cpp files.
+ namespace third_party_namespace {
+using third_party_decl_used_in_cpp_1;
+using third_party_decl_used_in_cpp_2;
+...
+using third_party_decl_used_in_cpp_n;
+ }
+ #endif
+
+In case the
[clang] [docs] [C++20] [Modules] Ideas for transitioning to modules (PR #80687)
@@ -610,6 +610,345 @@ the following style significantly:
The key part of the tip is to reduce the duplications from the text includes.
+Ideas for converting to modules
+---
+
+For new libraries, we encourage them to use modules completely from day one if
possible.
+This will be pretty helpful to make the whole ecosystems to get ready.
+
+For many existing libraries, it may be a breaking change to refactor themselves
+into modules completely. So that many existing libraries need to provide
headers and module
+interfaces for a while to not break existing users.
+Here we provide some ideas to ease the transition process for existing
libraries.
+**Note that the this section is only about helping ideas instead of
requirement from clang**.
+
+Let's start with the case that there is no dependency or no dependent
libraries providing
+modules for your library.
+
+ABI non-breaking styles
+~~~
+
+export-using style
+^^
+
+.. code-block:: c++
+
+ module;
+ #include "header_1.h"
+ #include "header_2.h"
+ ...
+ #include "header_n.h"
+ export module your_library;
+ export namespace your_namespace {
+using decl_1;
+using decl_2;
+...
+using decl_n;
+ }
+
+As the example shows, you need to include all the headers containing
declarations needs
+to be exported and `using` such declarations in an `export` block. Then,
basically,
+we're done.
+
+export extern-C++ style
+^^^
+
+.. code-block:: c++
+
+ module;
+ #include "third_party/A/headers.h"
+ #include "third_party/B/headers.h"
+ ...
+ #include "third_party/Z/headers.h"
+ export module your_library;
+ #define IN_MODULE_INTERFACE
+ extern "C++" {
+#include "header_1.h"
+#include "header_2.h"
+...
+#include "header_n.h"
+ }
+
+Then in your headers (from ``header_1.h`` to ``header_n.h``), you need to
define the macro:
+
+.. code-block:: c++
+
+ #ifdef IN_MODULE_INTERFACE
+ #define EXPORT export
+ #else
+ #define EXPORT
+ #endif
+
+And you should put ``EXPORT`` to the beginning of the declarations you want to
export.
+
+Also it is suggested to refactor your headers to include thirdparty headers
conditionally:
+
+.. code-block:: c++
+
+ + #ifndef IN_MODULE_INTERFACE
+ #include "third_party/A/headers.h"
+ + #endif
+
+ #include "header_x.h"
+
+ ...
+
+This may be helpful to get better diagnostic messages if you forgot to update
your module
+interface unit file during maintaining.
+
+The reasoning for the practice is that the declarations in the language
linkage are considered
+to be attached to the global module. So the ABI of your library in the modular
version
+wouldn't change.
+
+While this style looks not as convenient as the export-using style, it is
easier to convert
+to other styles.
+
+ABI breaking style
+~~
+
+The term ``ABI breaking`` sounds terrifying generally. But you may want it
here if you want
+to force your users to introduce your library in a consistent way. E.g., they
either include
+your headers all the way or import your modules all the way.
+The style prevents the users to include your headers and import your modules
at the same time
+in the same repo.
+
+The pattern for ABI breaking style is similar with export extern-C++ style.
+
+.. code-block:: c++
+
+ module;
+ #include "third_party/A/headers.h"
+ #include "third_party/B/headers.h"
+ ...
+ #include "third_party/Z/headers.h"
+ export module your_library;
+ #define IN_MODULE_INTERFACE
+ #include "header_1.h"
+ #include "header_2.h"
+ ...
+ #include "header_n.h"
+
+ #if the number of .cpp files in your project are small
+ module :private;
+ #include "source_1.cpp"
+ #include "source_2.cpp"
+ ...
+ #include "source_n.cpp"
+ #else // the number of .cpp files in your project are a lot
+ // Using all the declarations from thirdparty libraries which are
+ // used in the .cpp files.
+ namespace third_party_namespace {
+using third_party_decl_used_in_cpp_1;
+using third_party_decl_used_in_cpp_2;
+...
+using third_party_decl_used_in_cpp_n;
+ }
+ #endif
+
+(And add `EXPORT` and conditional include to the headers as suggested in the
export
+extern-C++ style section)
+
+Remember that the ABI get changed and we need to compile our source files into
the
dwblaikie wrote:
```suggestion
Remember that the ABI is changed and we need to compile our source files into
the
```
https://github.com/llvm/llvm-project/pull/80687
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [docs] [C++20] [Modules] Ideas for transitioning to modules (PR #80687)
@@ -610,6 +610,345 @@ the following style significantly:
The key part of the tip is to reduce the duplications from the text includes.
+Ideas for converting to modules
+---
+
+For new libraries, we encourage them to use modules completely from day one if
possible.
+This will be pretty helpful to make the whole ecosystems to get ready.
+
+For many existing libraries, it may be a breaking change to refactor themselves
+into modules completely. So that many existing libraries need to provide
headers and module
+interfaces for a while to not break existing users.
+Here we provide some ideas to ease the transition process for existing
libraries.
+**Note that the this section is only about helping ideas instead of
requirement from clang**.
+
+Let's start with the case that there is no dependency or no dependent
libraries providing
+modules for your library.
+
+ABI non-breaking styles
+~~~
+
+export-using style
+^^
+
+.. code-block:: c++
+
+ module;
+ #include "header_1.h"
+ #include "header_2.h"
+ ...
+ #include "header_n.h"
+ export module your_library;
+ export namespace your_namespace {
+using decl_1;
+using decl_2;
+...
+using decl_n;
+ }
+
+As the example shows, you need to include all the headers containing
declarations needs
+to be exported and `using` such declarations in an `export` block. Then,
basically,
+we're done.
+
+export extern-C++ style
+^^^
+
+.. code-block:: c++
+
+ module;
+ #include "third_party/A/headers.h"
+ #include "third_party/B/headers.h"
+ ...
+ #include "third_party/Z/headers.h"
+ export module your_library;
+ #define IN_MODULE_INTERFACE
+ extern "C++" {
+#include "header_1.h"
+#include "header_2.h"
+...
+#include "header_n.h"
+ }
+
+Then in your headers (from ``header_1.h`` to ``header_n.h``), you need to
define the macro:
+
+.. code-block:: c++
+
+ #ifdef IN_MODULE_INTERFACE
+ #define EXPORT export
+ #else
+ #define EXPORT
+ #endif
+
+And you should put ``EXPORT`` to the beginning of the declarations you want to
export.
+
+Also it is suggested to refactor your headers to include thirdparty headers
conditionally:
+
+.. code-block:: c++
+
+ + #ifndef IN_MODULE_INTERFACE
+ #include "third_party/A/headers.h"
+ + #endif
+
+ #include "header_x.h"
+
+ ...
+
+This may be helpful to get better diagnostic messages if you forgot to update
your module
+interface unit file during maintaining.
+
+The reasoning for the practice is that the declarations in the language
linkage are considered
+to be attached to the global module. So the ABI of your library in the modular
version
+wouldn't change.
+
+While this style looks not as convenient as the export-using style, it is
easier to convert
+to other styles.
+
+ABI breaking style
+~~
+
+The term ``ABI breaking`` sounds terrifying generally. But you may want it
here if you want
+to force your users to introduce your library in a consistent way. E.g., they
either include
+your headers all the way or import your modules all the way.
+The style prevents the users to include your headers and import your modules
at the same time
+in the same repo.
+
+The pattern for ABI breaking style is similar with export extern-C++ style.
+
+.. code-block:: c++
+
+ module;
+ #include "third_party/A/headers.h"
+ #include "third_party/B/headers.h"
+ ...
+ #include "third_party/Z/headers.h"
+ export module your_library;
+ #define IN_MODULE_INTERFACE
+ #include "header_1.h"
+ #include "header_2.h"
+ ...
+ #include "header_n.h"
+
+ #if the number of .cpp files in your project are small
+ module :private;
+ #include "source_1.cpp"
+ #include "source_2.cpp"
+ ...
+ #include "source_n.cpp"
+ #else // the number of .cpp files in your project are a lot
+ // Using all the declarations from thirdparty libraries which are
+ // used in the .cpp files.
+ namespace third_party_namespace {
+using third_party_decl_used_in_cpp_1;
+using third_party_decl_used_in_cpp_2;
+...
+using third_party_decl_used_in_cpp_n;
+ }
+ #endif
+
+(And add `EXPORT` and conditional include to the headers as suggested in the
export
+extern-C++ style section)
+
+Remember that the ABI get changed and we need to compile our source files into
the
+new ABI format. This is the job of the additional part of the interface unit:
+
+.. code-block:: c++
+
+ #if the number of .cpp files in your project are small
+ module :private;
+ #include "source_1.cpp"
+ #include "source_2.cpp"
+ ...
+ #include "source_n.cpp"
+ #else // the number of .cpp files in your project are a lot
+ // Using all the declarations from thirdparty libraries which are
+ // used in the .cpp files.
+ namespace third_party_namespace {
+using third_party_decl_used_in_cpp_1;
+using third_party_decl_used_in_cpp_2;
+...
+using third_party_decl_used_in_cpp_n;
+ }
+ #endif
+
+In case the
[clang] [docs] [C++20] [Modules] Ideas for transitioning to modules (PR #80687)
@@ -610,6 +610,345 @@ the following style significantly: The key part of the tip is to reduce the duplications from the text includes. +Ideas for converting to modules +--- + +For new libraries, we encourage them to use modules completely from day one if possible. +This will be pretty helpful to make the whole ecosystems to get ready. + +For many existing libraries, it may be a breaking change to refactor themselves dwblaikie wrote: ```suggestion For many existing libraries, it may be a breaking change to refactor them ``` https://github.com/llvm/llvm-project/pull/80687 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [docs] [C++20] [Modules] Ideas for transitioning to modules (PR #80687)
@@ -610,6 +610,345 @@ the following style significantly:
The key part of the tip is to reduce the duplications from the text includes.
+Ideas for converting to modules
+---
+
+For new libraries, we encourage them to use modules completely from day one if
possible.
+This will be pretty helpful to make the whole ecosystems to get ready.
+
+For many existing libraries, it may be a breaking change to refactor themselves
+into modules completely. So that many existing libraries need to provide
headers and module
+interfaces for a while to not break existing users.
+Here we provide some ideas to ease the transition process for existing
libraries.
+**Note that the this section is only about helping ideas instead of
requirement from clang**.
+
+Let's start with the case that there is no dependency or no dependent
libraries providing
+modules for your library.
+
+ABI non-breaking styles
+~~~
+
+export-using style
+^^
+
+.. code-block:: c++
+
+ module;
+ #include "header_1.h"
+ #include "header_2.h"
+ ...
+ #include "header_n.h"
+ export module your_library;
+ export namespace your_namespace {
+using decl_1;
+using decl_2;
+...
+using decl_n;
+ }
+
+As the example shows, you need to include all the headers containing
declarations needs
+to be exported and `using` such declarations in an `export` block. Then,
basically,
+we're done.
+
+export extern-C++ style
+^^^
+
+.. code-block:: c++
+
+ module;
+ #include "third_party/A/headers.h"
+ #include "third_party/B/headers.h"
+ ...
+ #include "third_party/Z/headers.h"
+ export module your_library;
+ #define IN_MODULE_INTERFACE
+ extern "C++" {
+#include "header_1.h"
+#include "header_2.h"
+...
+#include "header_n.h"
+ }
+
+Then in your headers (from ``header_1.h`` to ``header_n.h``), you need to
define the macro:
+
+.. code-block:: c++
+
+ #ifdef IN_MODULE_INTERFACE
+ #define EXPORT export
+ #else
+ #define EXPORT
+ #endif
+
+And you should put ``EXPORT`` to the beginning of the declarations you want to
export.
+
+Also it is suggested to refactor your headers to include thirdparty headers
conditionally:
+
+.. code-block:: c++
+
+ + #ifndef IN_MODULE_INTERFACE
+ #include "third_party/A/headers.h"
+ + #endif
+
+ #include "header_x.h"
+
+ ...
+
+This may be helpful to get better diagnostic messages if you forgot to update
your module
+interface unit file during maintaining.
+
+The reasoning for the practice is that the declarations in the language
linkage are considered
+to be attached to the global module. So the ABI of your library in the modular
version
+wouldn't change.
+
+While this style looks not as convenient as the export-using style, it is
easier to convert
+to other styles.
+
+ABI breaking style
+~~
+
+The term ``ABI breaking`` sounds terrifying generally. But you may want it
here if you want
+to force your users to introduce your library in a consistent way. E.g., they
either include
+your headers all the way or import your modules all the way.
+The style prevents the users to include your headers and import your modules
at the same time
+in the same repo.
+
+The pattern for ABI breaking style is similar with export extern-C++ style.
+
+.. code-block:: c++
+
+ module;
+ #include "third_party/A/headers.h"
+ #include "third_party/B/headers.h"
+ ...
+ #include "third_party/Z/headers.h"
+ export module your_library;
+ #define IN_MODULE_INTERFACE
+ #include "header_1.h"
+ #include "header_2.h"
+ ...
+ #include "header_n.h"
+
+ #if the number of .cpp files in your project are small
+ module :private;
+ #include "source_1.cpp"
+ #include "source_2.cpp"
+ ...
+ #include "source_n.cpp"
+ #else // the number of .cpp files in your project are a lot
+ // Using all the declarations from thirdparty libraries which are
+ // used in the .cpp files.
+ namespace third_party_namespace {
+using third_party_decl_used_in_cpp_1;
+using third_party_decl_used_in_cpp_2;
+...
+using third_party_decl_used_in_cpp_n;
+ }
+ #endif
+
+(And add `EXPORT` and conditional include to the headers as suggested in the
export
+extern-C++ style section)
+
+Remember that the ABI get changed and we need to compile our source files into
the
+new ABI format. This is the job of the additional part of the interface unit:
+
+.. code-block:: c++
+
+ #if the number of .cpp files in your project are small
+ module :private;
+ #include "source_1.cpp"
+ #include "source_2.cpp"
+ ...
+ #include "source_n.cpp"
+ #else // the number of .cpp files in your project are a lot
+ // Using all the declarations from thirdparty libraries which are
+ // used in the .cpp files.
+ namespace third_party_namespace {
+using third_party_decl_used_in_cpp_1;
+using third_party_decl_used_in_cpp_2;
+...
+using third_party_decl_used_in_cpp_n;
+ }
+ #endif
+
+In case the
[clang] [docs] [C++20] [Modules] Ideas for transitioning to modules (PR #80687)
@@ -610,6 +610,345 @@ the following style significantly: The key part of the tip is to reduce the duplications from the text includes. +Ideas for converting to modules +--- + +For new libraries, we encourage them to use modules completely from day one if possible. +This will be pretty helpful to make the whole ecosystems to get ready. + +For many existing libraries, it may be a breaking change to refactor themselves +into modules completely. So that many existing libraries need to provide headers and module +interfaces for a while to not break existing users. +Here we provide some ideas to ease the transition process for existing libraries. +**Note that the this section is only about helping ideas instead of requirement from clang**. dwblaikie wrote: ```suggestion **Note that the this section is only about helpful ideas instead of requirement from clang**. ``` https://github.com/llvm/llvm-project/pull/80687 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [docs] [C++20] [Modules] Ideas for transitioning to modules (PR #80687)
@@ -610,6 +610,345 @@ the following style significantly:
The key part of the tip is to reduce the duplications from the text includes.
+Ideas for converting to modules
+---
+
+For new libraries, we encourage them to use modules completely from day one if
possible.
+This will be pretty helpful to make the whole ecosystems to get ready.
+
+For many existing libraries, it may be a breaking change to refactor themselves
+into modules completely. So that many existing libraries need to provide
headers and module
+interfaces for a while to not break existing users.
+Here we provide some ideas to ease the transition process for existing
libraries.
+**Note that the this section is only about helping ideas instead of
requirement from clang**.
+
+Let's start with the case that there is no dependency or no dependent
libraries providing
+modules for your library.
+
+ABI non-breaking styles
+~~~
+
+export-using style
+^^
+
+.. code-block:: c++
+
+ module;
+ #include "header_1.h"
+ #include "header_2.h"
+ ...
+ #include "header_n.h"
+ export module your_library;
+ export namespace your_namespace {
+using decl_1;
+using decl_2;
+...
+using decl_n;
+ }
+
+As the example shows, you need to include all the headers containing
declarations needs
+to be exported and `using` such declarations in an `export` block. Then,
basically,
+we're done.
+
+export extern-C++ style
+^^^
+
+.. code-block:: c++
+
+ module;
+ #include "third_party/A/headers.h"
+ #include "third_party/B/headers.h"
+ ...
+ #include "third_party/Z/headers.h"
+ export module your_library;
+ #define IN_MODULE_INTERFACE
+ extern "C++" {
+#include "header_1.h"
+#include "header_2.h"
+...
+#include "header_n.h"
+ }
+
+Then in your headers (from ``header_1.h`` to ``header_n.h``), you need to
define the macro:
+
+.. code-block:: c++
+
+ #ifdef IN_MODULE_INTERFACE
+ #define EXPORT export
+ #else
+ #define EXPORT
+ #endif
+
+And you should put ``EXPORT`` to the beginning of the declarations you want to
export.
+
+Also it is suggested to refactor your headers to include thirdparty headers
conditionally:
+
+.. code-block:: c++
+
+ + #ifndef IN_MODULE_INTERFACE
+ #include "third_party/A/headers.h"
+ + #endif
+
+ #include "header_x.h"
+
+ ...
+
+This may be helpful to get better diagnostic messages if you forgot to update
your module
+interface unit file during maintaining.
+
+The reasoning for the practice is that the declarations in the language
linkage are considered
+to be attached to the global module. So the ABI of your library in the modular
version
+wouldn't change.
+
+While this style looks not as convenient as the export-using style, it is
easier to convert
+to other styles.
+
+ABI breaking style
+~~
+
+The term ``ABI breaking`` sounds terrifying generally. But you may want it
here if you want
+to force your users to introduce your library in a consistent way. E.g., they
either include
+your headers all the way or import your modules all the way.
+The style prevents the users to include your headers and import your modules
at the same time
+in the same repo.
dwblaikie wrote:
```suggestion
The style prevents the users from including your headers and importing your
modules at the same time
in the same repo.
```
https://github.com/llvm/llvm-project/pull/80687
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [docs] [C++20] [Modules] Ideas for transitioning to modules (PR #80687)
@@ -610,6 +610,345 @@ the following style significantly:
The key part of the tip is to reduce the duplications from the text includes.
+Ideas for converting to modules
+---
+
+For new libraries, we encourage them to use modules completely from day one if
possible.
+This will be pretty helpful to make the whole ecosystems to get ready.
+
+For many existing libraries, it may be a breaking change to refactor themselves
+into modules completely. So that many existing libraries need to provide
headers and module
+interfaces for a while to not break existing users.
+Here we provide some ideas to ease the transition process for existing
libraries.
+**Note that the this section is only about helping ideas instead of
requirement from clang**.
+
+Let's start with the case that there is no dependency or no dependent
libraries providing
+modules for your library.
+
+ABI non-breaking styles
+~~~
+
+export-using style
+^^
+
+.. code-block:: c++
+
+ module;
+ #include "header_1.h"
+ #include "header_2.h"
+ ...
+ #include "header_n.h"
+ export module your_library;
+ export namespace your_namespace {
+using decl_1;
+using decl_2;
+...
+using decl_n;
+ }
+
+As the example shows, you need to include all the headers containing
declarations needs
+to be exported and `using` such declarations in an `export` block. Then,
basically,
dwblaikie wrote:
```suggestion
As the example shows, you need to include all the headers containing
declarations that need
to be exported and `using` such declarations in an `export` block. Then,
basically,
```
https://github.com/llvm/llvm-project/pull/80687
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [docs] [C++20] [Modules] Ideas for transitioning to modules (PR #80687)
@@ -610,6 +610,345 @@ the following style significantly: The key part of the tip is to reduce the duplications from the text includes. +Ideas for converting to modules +--- + +For new libraries, we encourage them to use modules completely from day one if possible. +This will be pretty helpful to make the whole ecosystems to get ready. + +For many existing libraries, it may be a breaking change to refactor themselves +into modules completely. So that many existing libraries need to provide headers and module dwblaikie wrote: ```suggestion into modules completely. So many existing libraries will need to provide headers and module ``` https://github.com/llvm/llvm-project/pull/80687 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [docs] [C++20] [Modules] Ideas for transitioning to modules (PR #80687)
https://github.com/dwblaikie commented: Generally seems like good stuff to write down - I'm not sure about the ABI breaking version (that mostly seems like it would make more problems than solutions). Commented on some minor grammatical issues. https://github.com/llvm/llvm-project/pull/80687 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [docs] [C++20] [Modules] Ideas for transitioning to modules (PR #80687)
https://github.com/dwblaikie edited https://github.com/llvm/llvm-project/pull/80687 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang] Revert "[RISCV] Relax march string order constraint" (PR #79976)
dwblaikie wrote: Sure - wrote down my thoughts here: https://discourse.llvm.org/t/prs-without-approvals-muddy-the-waters/76656 (my understanding is that this (waiting for approval after sending out a review - and that all PRs are reviews until we figure out a way to differentiate them) is existing policy, as noted in the documentation linked from the post) https://github.com/llvm/llvm-project/pull/79976 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Add support for builtin_verbose_trap (PR #79230)
@@ -346,6 +346,14 @@ class CGDebugInfo {
const FieldDecl *BitFieldDecl, const llvm::DIDerivedType *BitFieldDI,
llvm::ArrayRef PreviousFieldsDI, const RecordDecl *RD);
+ // A cache that maps artificial inlined function names used for
+ // __builtin_verbose_trap to subprograms.
+ std::map InlinedTrapFuncMap;
dwblaikie wrote:
& consider using `llvm::StringMap`, perhaps?
https://github.com/llvm/llvm-project/pull/79230
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Add support for builtin_verbose_trap (PR #79230)
@@ -3424,6 +3445,26 @@ llvm::DIMacroFile *CGDebugInfo::CreateTempMacroFile(llvm::DIMacroFile *Parent, return DBuilder.createTempMacroFile(Parent, Line, FName); } +llvm::DILocation *CGDebugInfo::CreateTrapFailureMessageFor( dwblaikie wrote: There's currently only one caller with a fixed parameter for `Prefix` - perhaps that could be hardcoded in the implementation instead? https://github.com/llvm/llvm-project/pull/79230 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Add support for builtin_verbose_trap (PR #79230)
@@ -3424,6 +3445,26 @@ llvm::DIMacroFile
*CGDebugInfo::CreateTempMacroFile(llvm::DIMacroFile *Parent,
return DBuilder.createTempMacroFile(Parent, Line, FName);
}
+llvm::DILocation *CGDebugInfo::CreateTrapFailureMessageFor(
+llvm::DebugLoc TrapLocation, StringRef Prefix, StringRef FailureMsg) {
+ assert((!FailureMsg.empty() || Prefix.find(' ') != std::string::npos) &&
+ "Prefix must contain a space when FailureMsg is empty");
+
+ // Create debug info that describes an inlined function whose name is the
+ // failure message.
+ std::string FuncName(Prefix);
dwblaikie wrote:
`llvm::SmallString`?
https://github.com/llvm/llvm-project/pull/79230
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [C++20] [Modules] Introduce -fskip-odr-check-in-gmf (PR #79959)
dwblaikie wrote: I'd still idly vote against adding this flag/support - but if other modules contributors feel it's the right thing to do, I won't stand in the way. https://github.com/llvm/llvm-project/pull/79959 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang] Revert "[RISCV] Relax march string order constraint" (PR #79976)
dwblaikie wrote: (Please don't send pull requests that aren't going to be reviewed - commit directly instead. Otherwise it's unclear which pull requests are expecting review (& should wait on it) and which pull requests don't need review. Especially for new contributors, it'd be good to not give the impression that pull requests should be sent, then committed if reviews are not forthcoming) https://github.com/llvm/llvm-project/pull/79976 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Serialization] Check for stack exhaustion when reading declarations (PR #79875)
dwblaikie wrote: > > Could you show the stack (omitting/annotating the repeated part) that leads > > to failure? and/or the AST shape that leads to failure? > > See the test I added. All you need is ~10k overloads of a method in a class > and a `using Base::func` in the derived class. The AST represents that as a > linked list inside `UsingShadowDecl` (each shadow decl references the next > one). Serializing them works fine, but deserialization is recursive and blows > up. > > Feel free to just call `-ast-dump` on the test I posted (it only crashes when > reading the pcm, so outputing AST should be fine) 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. 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
[clang] [Serialization] Check for stack exhaustion when reading declarations (PR #79875)
dwblaikie wrote: Could you show the stack (omitting/annotating the repeated part) that leads to failure? and/or the AST shape that leads to failure? 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
[clang] Add support for builtin_verbose_trap (PR #79230)
https://github.com/dwblaikie edited https://github.com/llvm/llvm-project/pull/79230 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Add support for builtin_verbose_trap (PR #79230)
@@ -0,0 +1,28 @@ +// RUN: %clang_cc1 -std=c++11 -fsyntax-only -fcxx-exceptions -verify %s + +#if !__has_builtin(__builtin_verbose_trap) +#error +#endif dwblaikie wrote: Is this necessary? https://github.com/llvm/llvm-project/pull/79230 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Add support for builtin_verbose_trap (PR #79230)
https://github.com/dwblaikie commented: neat idea (I imagine some debuggers will trip over the space in the inlined name, but seems pretty good) I'd guess sometimes we'll lose the inlined debug info if two of these traps are merged, fwiw - but it's probably relatively robust, apart from that. https://github.com/llvm/llvm-project/pull/79230 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [lldb] [c++20] P1907R1: Support for generalized non-type template arguments of scalar type. (PR #78041)
@@ -5401,6 +5409,8 @@ std::string CGDebugInfo::GetName(const Decl *D, bool
Qualified) const {
// feasible some day.
return TA.getAsIntegral().getBitWidth() <= 64 &&
IsReconstitutableType(TA.getIntegralType());
+ case TemplateArgument::StructuralValue:
+return false;
dwblaikie wrote:
Sorry for the delays in the debug info review for this - it is on my list :/
https://github.com/llvm/llvm-project/pull/78041
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
