Skip to content
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

SILGen: "sort" the witness tables in declaration order #22308

Closed

Conversation

compnerd
Copy link
Member

@compnerd compnerd commented Feb 1, 2019

Emit the tables in the declaration order. This ensures that we get identical
emission ordering across Windows and Linux. This imporves the test pass rate on
Windows for the SILGen tests.

Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.

Resolves SR-NNNN.

@compnerd
Copy link
Member Author

compnerd commented Feb 1, 2019

CC: @gottesmm @jckarter @jrose-apple

@compnerd
Copy link
Member Author

compnerd commented Feb 1, 2019

@swift-ci please test

Emit the tables in the declaration order.  This ensures that we get identical
emission ordering across Windows and Linux.  This imporves the test pass rate on
Windows for the SILGen tests.
@compnerd compnerd force-pushed the noncanonical-is-more-canonical branch from bb26f80 to bb295c7 Compare February 1, 2019 21:55
@compnerd
Copy link
Member Author

compnerd commented Feb 1, 2019

@swift-ci please test

@swift-ci
Copy link
Contributor

swift-ci commented Feb 1, 2019

Build failed
Swift Test OS X Platform
Git Sha - bb26f80210fb76dbdf394e55d264886c6bb9e5d0

@swift-ci
Copy link
Contributor

swift-ci commented Feb 1, 2019

Build failed
Swift Test Linux Platform
Git Sha - bb26f80210fb76dbdf394e55d264886c6bb9e5d0

Copy link
Contributor

@slavapestov slavapestov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why does the order differ on Windows?

@compnerd
Copy link
Member Author

compnerd commented Feb 2, 2019

@slavapestov ... dunno the exact details, but the address of the two decls is just different (TypeDecl::compare returns different values).

@slavapestov
Copy link
Contributor

TypeDecl::compare should not depend on address order...

@compnerd
Copy link
Member Author

compnerd commented Feb 2, 2019

It does do a pointer comparison, but, I can track through it again if it really matters (I think I agree with @gottesmm that emitting it in declaration order is nice)

@compnerd
Copy link
Member Author

compnerd commented Feb 6, 2019

CC: @DougGregor

@compnerd
Copy link
Member Author

compnerd commented Feb 6, 2019

Actually, I am curious about the need for the sort in the getLocalConformances path ... what was the reason for that?

@gottesmm
Copy link
Contributor

gottesmm commented Feb 6, 2019

To be clear I think that is a question for @DougGregor (i.e. why do we need to sort).

@compnerd
Copy link
Member Author

compnerd commented Feb 7, 2019

ping @DougGregor @jrose-apple - it's unclear the reason for the sorting, and seems to introduce a difference in the generated SILGen.

@jrose-apple
Copy link
Contributor

I've got no context for this; we'll have to wait for Doug.

@compnerd
Copy link
Member Author

@DougGregor ping

@DougGregor
Copy link
Member

There's no point in doing this sorting; the underlying data structures should be deterministic. I went a step further and killed the "sorted" parameter in #22659. Let's see if that solves the problem for good.

@compnerd
Copy link
Member Author

@DougGregor - awesome, thanks!

@compnerd compnerd closed this Feb 16, 2019
@compnerd compnerd deleted the noncanonical-is-more-canonical branch February 16, 2019 04:44
@compnerd
Copy link
Member Author

@DougGregor - I think I should look at that change more carefully at some point. That also caught the last two cases that I was trying to chase down! SILGen is now at 100% pass on Windows!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants