-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[DebugInfo] Stop handling InOut types, they'll be gone soon. #21095
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -500,8 +500,6 @@ class IRGenDebugInfoImpl : public IRGenDebugInfo { | |
SILType type, DeclContext *DeclCtx, | ||
GenericEnvironment *GE) { | ||
auto RealType = type.getASTType(); | ||
if (type.isAddress()) | ||
RealType = CanInOutType::get(RealType); | ||
auto DbgTy = DebugTypeInfo::getFromTypeInfo(DeclCtx, GE, RealType, | ||
IGM.getTypeInfo(type)); | ||
Parameters.push_back(getOrCreateType(DbgTy)); | ||
|
@@ -1192,22 +1190,8 @@ class IRGenDebugInfoImpl : public IRGenDebugInfo { | |
AlignInBits, Flags, MangledName); | ||
} | ||
|
||
case TypeKind::InOut: { | ||
// This is an inout type. Naturally we would be emitting them as | ||
// DW_TAG_reference_type types, but LLDB can deal better with | ||
// pointer-sized struct that has the appropriate mangled name. | ||
auto ObjectTy = BaseTy->castTo<InOutType>()->getObjectType(); | ||
auto Name = MangledName; | ||
if (auto *Decl = ObjectTy->getAnyNominal()) | ||
Name = Decl->getName().str(); | ||
if (Opts.DebugInfoLevel > IRGenDebugInfoLevel::ASTTypes) { | ||
auto DT = getOrCreateDesugaredType(ObjectTy, DbgTy); | ||
return createPointerSizedStruct(Scope, Name, DT, File, 0, Flags, | ||
MangledName); | ||
} else | ||
return createOpaqueStruct(Scope, Name, File, 0, SizeInBits, AlignInBits, | ||
Flags, MangledName); | ||
} | ||
case TypeKind::InOut: | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Will the user-facing inout type disappear, too? Or do we still need to mangle inout types so we can preserve the sugar in LLDB (i.e.: should There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @adrian-prantl I had a quick discussion with @slavapestov yesterday and he suggested we shouldn't print anything at all. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In fact, it's been pointed out that There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I suppose it is not particularly useful information. |
||
break; | ||
|
||
case TypeKind::Archetype: { | ||
auto *Archetype = BaseTy->castTo<ArchetypeType>(); | ||
|
@@ -1384,10 +1368,6 @@ class IRGenDebugInfoImpl : public IRGenDebugInfo { | |
case TypeKind::SILBlockStorage: // Not supported at all. | ||
case TypeKind::SILBox: | ||
return false; | ||
case TypeKind::InOut: { | ||
auto *ObjectTy = Ty->castTo<InOutType>()->getObjectType().getPointer(); | ||
return canMangle(ObjectTy); | ||
} | ||
default: | ||
return true; | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This worries me. Are you representing the address-ness some other way now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this code was unused.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But I didn't write this, so I guess @adrian-prantl is in a better position to judge.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to check whether LLDB attaches any semantics to InOut or if it is pure sugar. If it's the latter then this is safe.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have any tests in LLDB that exercise inout types?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd put a regular Int field in the struct too, then, and make sure you can print that. That's easier than checking the weak reference, though of course that should also be correct.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jrose-apple this is what I'm seeing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That looks like correct behavior, although it would be a better test if you had a class instance that was kept alive until after you were done calling
test
. If that works with and without your change, then I think it's all good.Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jrose-apple Looks like that case is broken with and without my change
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jrose-apple given it seems unrelated, I'll open a
rdar
for this and look at it next.