[NFC] Hide SourceFile::Decls#525
Conversation
There was a problem hiding this comment.
@dcci Do you know why this was injecting variables into the start of the top level decls list instead of the end?
There was a problem hiding this comment.
Quite honestly, I don't. This predates my time. Do you know what breaks when you change it? I'll be happy to take a look with you.
There was a problem hiding this comment.
Quite honestly, I don't. This predates my time. Do you know what breaks when you change it? I'll be happy to take a look with you.
There was a problem hiding this comment.
If I put these in the original order (Redirected VarDecl then Top Level Code with Pattern Binding) then it fails a REPL test. But the odd thing is that it should have failed much much more spectacularly than just a runtime exclusivity assertion.
The correct way around (Top Level Code then Redirected VarDecl) we'll see soon enough...
There was a problem hiding this comment.
Thanks. I'm curious to see the results too. @jimingham might have more context on why this was the order originally, but it was long enough ago that he might not remember either and the history is lost in the initial import.
There was a problem hiding this comment.
Thanks. I'm curious to see the results too. @jimingham might have more context on why this was the order originally, but it was long enough ago that he might not remember either and the history is lost in the initial import.
There was a problem hiding this comment.
Same REPL test fails. I can merge this through with an extra entrypoint on the Swift side to preserve this behavior, but the fact that only a single test fails because of this, and fails in such a bizarre way, suggests there's something deeper at play.
154ec47 to
f64e25b
Compare
|
⛵️ |
Supports swiftlang/swift#28995