derive: use discriminant_value in #[derive(Hash)] #32252
Conversation
|
@bors: r+ b938cf96e0dbf8928833e823572e4461ee9975ac eh we'll see how bors orders this |
|
☔ The latest upstream changes (presumably #32251) made this pull request unmergeable. Please resolve the merge conflicts. |
|
My pre-emptive efforts to avoid this merge conflict failed. |
|
@bors r=alexcrichton |
|
📌 Commit 23aa5f1 has been approved by |
|
⌛ Testing commit 23aa5f1 with merge 5058d71... |
|
💔 Test failed - auto-linux-32-opt |
|
@alexcrichton do you think it's real this time? On Wed, Mar 16, 2016 at 2:43 AM, bors notifications@github.com wrote:
|
|
Hm yes, that looks legit... not sure how though? |
|
I mean, start is a lang item, and lang items are stored in an enum that On Wed, Mar 16, 2016 at 12:36 PM, Alex Crichton notifications@github.com
|
|
Perhaps, yeah. It seems specifically related to the |
|
More data! I ran Master: Branch: (note: I commented out this line so that I could inspect the symbols) cc @eddyb (we talked on IRC) any thoughts? |
|
@durka The symbols would differ anyway, had you changed a single non-whitespace thing in any library. |
|
@eddyb ok. So do you know what "symbol lookup error" actually means? Who is On Fri, Mar 18, 2016 at 4:58 PM, Eduard-Mihai Burtescu <
|
|
@durka The dynamic linker is looking up symbols and it only reports the first failure. Most likely none of the symbols in there match the
Now, since this is a hashing change, it could mean "you were always using the wrong library but somehow stage1 Which, well, totally makes sense! You're changing how The only thing you need to do is get this into a snapshot (sad that I haven't looked into this in-depth and right now we're building one...) with the test disabled, and re-enable it afterwards. |
|
@durka Alternatively, you could try looking at the invocation that compiles |
|
@eddyb yep, you're right. Here is the log: So it compiles everything with stage2 libs and then runs with stage1 libs. |
|
And clearly it's looking for the stage2 symbol. So the question is where the mistake is in the maze of makefiles. |
|
I think I found the mistake in the maze of makefiles. In this block of vars, shouldn't it be |
|
With the above change there are 19 failures in a full |
|
Failures: |
|
@durka Those are the "pretty" versions of |
|
Look at the output though, it's complaining about plugins not found which
|
|
No, they're complaining about plugins having mismatched symbols (i.e. mismatched dynamic libraries), which is quite common - |
|
Yeah, this doesn't work. |
|
@durka That works if you do |
|
☔ The latest upstream changes (presumably #32293) made this pull request unmergeable. Please resolve the merge conflicts. |
This is the same approach taken in rust-lang#24270, except that this should not be a breaking change because it only changes the output of hash functions, which nobody should be relying on.
|
#32293 landed so I undid the rebase. Let's see if I did it right. |
|
@bors r=alexcrichton |
|
📌 Commit 1e67d8a has been approved by |
derive: use discriminant_value in #[derive(Hash)] derive: use discriminant_value in #[derive(Hash)] Fixes #21714. Spawned from #32139. r? @alexcrichton
|
💔 Test failed - auto-win-gnu-32-opt-rustbuild |
|
@bors clean retry |
derive: use discriminant_value in #[derive(Hash)] derive: use discriminant_value in #[derive(Hash)] Fixes #21714. Spawned from #32139. r? @alexcrichton
|
💔 Test failed - auto-win-msvc-64-opt-rustbuild |
|
I got a couple of failures in unrelated tests when running make check locally. A bunch of debuginfo failures on x64-darwin. But the bots seem to have not even gotten that far. |
|
@bors retry |
|
@bors force |
derive: use discriminant_value in #[derive(Hash)] derive: use discriminant_value in #[derive(Hash)] Fixes rust-lang#21714. Spawned from rust-lang#32139. r? @alexcrichton
|
⛄ The build was interrupted to prioritize another pull request. |
derive: use discriminant_value in #[derive(Hash)]
Fixes #21714.
Spawned from #32139.
r? @alexcrichton