LifetimeDependenceDiagnostics: bug fixes and output clarity #81191
Conversation
When the type checker encounters incomplete type error, bail out early to avoid an assertion.
Fix a simple typo that results in infinite recursion on invalid code. Fixes rdar://147470493 ([nonescapable] LifetimeDependenceInsertion: infinite recursion in VariableUseDefWalker.walkup with immortal setter)
Ensure that we always issue a diagnostic on error, but avoid emitting any notes that don't have source locations. With implicit accessors and thunks, report the correct line number and indicate which accessor generates the error. Always check for debug_value users. Consistently handle access scopes across diagnostic analysis and diagnostic messages.
Add a note explaining that dependence on closure captures is not supported. Otherwise, the diagnostics are very confusing: "it depends on a closure capture; this is not yet supported"
|
@swift-ci merge |
|
@swift-ci smoke test |
|
Unrelated failure: |
|
@swift-ci smoke test |
| @@ -34,7 +34,12 @@ public class Argument : Value, Hashable { | |||
|
|
|||
| public var isLexical: Bool { false } | |||
|
|
|||
| public var varDecl: VarDecl? { bridged.getVarDecl().getAs(VarDecl.self) } | |||
| public var varDecl: VarDecl? { | |||
There was a problem hiding this comment.
I don't think it's good to combine getDecl and the lookup of debug_value users into a single API.
I think it's better to directly bridge getDecl (returning a Decl) and add varDecl on top of this. And varDecl belongs more to OptUtils than defining it in the "raw" SIL, because it looks at a bigger SIL structure (including the users) than the Argument in isolation.
| } | ||
|
|
||
| extension Value { | ||
| var debugValDecl: VarDecl? { |
There was a problem hiding this comment.
The same here: this belongs more to OptUtils.
Also the name is not very descriptive. How about func getValDeclFromDebugUsers?
| return debugUserDecl | ||
| } | ||
|
|
||
| var debugUserDecl: VarDecl? { |
| } | ||
|
|
||
| var debugUserDecl: VarDecl? { | ||
| for use in uses { |
There was a problem hiding this comment.
uses.users(ofType: DebugValueInst.self).first?.varDecl
|
@eeckstein This week is especially disruptive to land cleanup PRs on main that interfere with 6.2 cherry-picking. Let's please avoid that. On Monday I can rethink the varDecl interface (which I don't like either) and land a cleanup PR. I agree with all your review comments except for moving logic into OptUtils. SIL structure is fundamental to SIL. As a rule, if any passes have expectations about that structure, those conventions need to be defined in SIL, not OptUtils. One of my biggest frustrations with SwiftCompilerSources today is the way fundamental SIL operations are scattered around the optimizer code. I particularly agree that property declarations should not usually search the use list, and we should try to mirror C++ API semantics. |
|
@eeckstein also please be aware that the only reason the varDecl APIs are such a mess is that the SIL structure itself is broken. But fixing that requires fixing SILGen. It is extremely important that such complexities (I would call them bugs) with the SIL structures are handled in the fundamental SIL APIs. Basically, anything you need to correctly use SIL, including verifying that its structure is valid, needs to be defined as part of SIL. |
|
blocked by a timeout building lib benchmark.a |
|
@swift-ci smoke test macOS |
LifetimeDependence type checking: avoid an assertion on error.
When the type checker encounters incomplete type error, bail out early to avoid
an assertion.
LifetimeDependenceDiagnostics: avoid infinite recursion on error
Fix a simple typo that results in infinite recursion on invalid code.
Fixes rdar://147470493 ([nonescapable] LifetimeDependenceInsertion: infinite
recursion in VariableUseDefWalker.walkup with immortal setter)
Refactor debugVarDecl so arguments also support debug_value users.
[NFC] SwiftCompilerSource: bridge Function.accessorKindName
LifetimeDependence: clarify diagnostics for many unusual cases.
Ensure that we always issue a diagnostic on error, but avoid emitting any notes that don't have source locations.
With implicit accessors and thunks, report the correct line number and indicate which accessor generates the error.
Always check for debug_value users.
Consistently handle access scopes across diagnostic analysis and diagnostic messages.
LifetimeDependenceDiagnostics: note for unsupported closure capture
Add a note explaining that dependence on closure captures is not
supported. Otherwise, the diagnostics are very confusing:
"it depends on a closure capture; this is not yet supported"