Generate full debug info for special builtins and classes #71332
Conversation
|
@adrian-prantl there are two separate commits here which might be easier to review separately. This depends on #71249 |
|
@swift-ci smoke test |
augusto2112
force-pushed
the
emit-class-deb
branch
from
38b49f9 to
ccfdf02
Compare
|
@swift-ci smoke test |
lib/IRGen/IRGenDebugInfo.cpp
Outdated
| @@ -1525,7 +1526,9 @@ class IRGenDebugInfoImpl : public IRGenDebugInfo { | |||
| ? 0 | |||
| : DbgTy.getAlignment().getValue() * SizeOfByte; | |||
| unsigned Encoding = 0; | |||
| uint32_t NumExtraInhabitants = 0; | |||
| uint32_t NumExtraInhabitants = | |||
| DbgTy.getNumExtraInhabitants() ? *DbgTy.getNumExtraInhabitants() : 0; | |||
There was a problem hiding this comment.
std::optional::value_or (llvm::optional also has such a function)
| return DBuilder.createPointerType(nullptr, PtrSize, 0, | ||
| /* DWARFAddressSpace */ llvm::None, | ||
| MangledName); | ||
| return DBuilder.createObjectPointerType(PTy); |
There was a problem hiding this comment.
Does this intentionally change the behavior for BuiltinRawPointer?
There was a problem hiding this comment.
Yes, I changed it because all of them seem artificial types to me (builtins not visible in user source code). What do you think?
| @@ -2255,6 +2248,7 @@ IRGenDebugInfoImpl::IRGenDebugInfoImpl(const IRGenOptions &Opts, | |||
| } | |||
| OS << '"'; | |||
| } | |||
| createSpecialStlibBuiltinTypes(); | |||
There was a problem hiding this comment.
Commit #1 doesn't have any tests, but we should at least be able to test the special types?
lib/IRGen/IRGenDebugInfo.cpp
Outdated
| DbgTy, Decl, ClassTy, Scope, File, L.Line, SizeInBits, AlignInBits, | ||
| Flags, nullptr, llvm::dwarf::DW_LANG_Swift, MangledName); | ||
| auto SuperClassTy = ClassTy->getSuperclass(); | ||
| if (DIType && SuperClassTy) { |
There was a problem hiding this comment.
When does createStructType() return a nullptr?
There was a problem hiding this comment.
It shouldn't, this is just protecting against UB in case createStructType's implementation is ever changed to return a nullptr.
There was a problem hiding this comment.
I think it would be clearer to assert(DIType) here. It should catch it if someone changes the implementation and makes the intention clearer. Or the function could just return a reference..
lib/IRGen/IRGenDebugInfo.cpp
Outdated
| false); | ||
|
|
||
| llvm::DIType *SuperClassDITy = getOrCreateType(SuperClassDbgTy); | ||
| if (SuperClassDITy) { |
There was a problem hiding this comment.
What does it mean for this to fail?
There was a problem hiding this comment.
getOrCreateType is quite complex so I don't know if succeeds 100% of the time, this is just to guarantee we don't dereference a null ptr. I'll add an assert to document the fact that we don't expect this to fail (I'll do the same for the one you commented above as well).
There was a problem hiding this comment.
The LLVM coding style has a really weird aversion to using references. I think it would be fine to assert and not check here.
augusto2112
force-pushed
the
emit-class-deb
branch
from
ccfdf02 to
2df3ad8
Compare
|
@swift-ci smoke test |
augusto2112
force-pushed
the
emit-class-deb
branch
from
3e211bb to
cc0c488
Compare
|
@swift-ci smoke test |
|
@swift-ci test Windows |
No description provided.