Serialize whether VarDecls are top-level #29489
Conversation
|
Any pointers for how to test this would be appreciated. |
|
I can pull this change into my branch and run full suite test to see whether it fixes the problem. |
|
@adrian-prantl I have |
lib/SILGen/SILGenGlobalVariable.cpp
Outdated
| @@ -69,7 +69,8 @@ ManagedValue | |||
| SILGenFunction::emitGlobalVariableRef(SILLocation loc, VarDecl *var) { | |||
| assert(!VarLocs.count(var)); | |||
|
|
|||
| if (var->isLazilyInitializedGlobal()) { | |||
| // In the debugger, no variables are lazy initialized. | |||
| if (!SGM.SwiftModule->getDebugClient() && var->isLazilyInitializedGlobal()) { | |||
There was a problem hiding this comment.
Sorry, I accidentally left this is.
There was a problem hiding this comment.
No worries, I can re-apply and test :)
adrian-prantl
force-pushed
the
58939370
branch
2 times, most recently
from
adf05b5 to
af3ffb1
Compare
|
I have re-applied the changes and restarted testing. |
|
test with swiftlang/llvm-project#674 |
|
Build failed |
|
@xedin You'll also need swiftlang/llvm-project#674 for the LLDB tests to succeed. This PR tests whether it also works without your PR. If yes I will land this, cherry-pick both to master-rebranch and master-next and then you should be able to merge your PR. |
|
Build failed |
|
Sounds good! Going to keep an eye on this PR. |
adrian-prantl
force-pushed
the
58939370
branch
from
af3ffb1 to
b6871ac
Compare
|
test with swiftlang/llvm-project#674 |
|
Build failed |
|
Build failed |
Diagnose an attempt to reference a top-level name shadowed by
a local member e.g.
```swift
extension Sequence {
func test() -> Int {
return max(1, 2)
}
}
```
Here `min` refers to a global function `min<T>(_: T, _: T)` in `Swift`
module and can only be accessed by adding `Swift.` to it, because `Sequence`
has a member named `min` which accepts a single argument.
|
test with swiftlang/llvm-project#674 |
Stop filtering outer overload choices while trying to pre-check expression, instead have it always fetch those and use new fix to only attempt them in diagnostic mode (unless it's min/max situation with conditional conformances).
Although such functionality is not yet supported we have to mirror AST lookup and add such members into results, otherwise there is a risk of inner/outer results mismatch.
adrian-prantl
force-pushed
the
58939370
branch
from
bc1ef38 to
ee5af7e
Compare
|
test with swiftlang/llvm-project#674 |
The current way that VarDecl::isLazilyInitializedGlobal() is implemented does not work in the debugger, since the DeclContext of all VarDecls are deserialized Swift modules. By adding a bit to the VarDecl we can recover the fact that a VarDecl was in fact a global even in the debugger. <rdar://problem/58939370>
This is in preparation to a change in serialization of global variables where this detail will matter.
adrian-prantl
force-pushed
the
58939370
branch
from
ee5af7e to
93dd4df
Compare
|
test with swiftlang/llvm-project#674 |
|
Build failed |
|
Build failed |
|
test with swiftlang/llvm-project#674 |
There was a problem hiding this comment.
This looks good, but it appears you've cherry-picked @xedin's changes into this PR too. Can we land the two sets of changes separately?
| @@ -5410,11 +5411,7 @@ bool VarDecl::isLazilyInitializedGlobal() const { | |||
|
|
|||
| // Top-level global variables in the main source file and in the REPL are not | |||
There was a problem hiding this comment.
Are the above checks (hasClangNode() and isDebuggerVar()) needed at all then? The bit should not be set in those cases either.
|
@slavapestov We actually going to do it vice versa - I have cherry-picked Adrian's changes to my PR to make sure everything works correctly, currently waiting on full performance suite to complete and we are going to land my PR together with llvm side. |
|
@xedin Ok, sure. In that case, can you simplify VarDecl::isLazilyInitializedGlobal() in your PR then? |
|
@slavapestov Sure! I'm going to let full test finish and commit the simplification to my PR. |
|
Abandoning this in favor of @xedin's all-in-one PR. |
The current way that VarDecl::isLazilyInitializedGlobal() is implemented does
not work in the debugger, since the DeclContext of all VarDecls are deserialized
Swift modules. By adding a bit to the VarDecl we can recover the fact that a
VarDecl was in fact a global even in the debugger.
rdar://problem/58939370