-
Notifications
You must be signed in to change notification settings - Fork 344
[NFC] Hide SourceFile::Decls #525
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
[NFC] Hide SourceFile::Decls #525
Conversation
m_source_file.Decls.insert(m_source_file.Decls.begin(), top_level_code); | ||
m_source_file.Decls.insert(m_source_file.Decls.begin(), | ||
redirected_var_decl); | ||
m_source_file.addTopLevelDecl(redirected_var_decl); |
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.
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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