make check-stage1 is broken for run-make/bootstrap-from-c-with-green #13732
Comments
|
see also, further irc discussion/debugging between myself and alexcrichton here: https://botbot.me/mozilla/rust-internals/msg/13776568/ |
|
I resolved where the rpath into my
Anyway, so this is getting installed as the fallback rpath, as indicated here in a verbose log: |
|
Looking at the code in I don't have a problem with that, but we probably should have a compiler flag to either remove the usage of that fallback rpath, or override the path that rustc uses for the fallback. Then the Makefile could actually run |
|
Okay, so I hacked up a patch to add a After doing that and using it in the I did some more digging and determined that there is some funky effect being introduced by the setting of the From the settings of the So I transcribed the settings that the Makefiles are current establishing for the two environment variables at the time that this recipe is run (by the aforementioned It seems like the |
|
attempting to fix, work in progress, see PR #13753 |
|
part of #8058 |
Fix #13732. This is a revised, much less hacky form of PR #13753 The changes here: * add instrumentation to aid debugging of linkage errors, * fine tune some things in the Makefile where we are telling binaries to use a host-oriented path for finding dynamic libraries, when it should be feeding the binaries a target-oriented path for dynamic libraries. * pass along the current stage number to run-make tests, and * skip certain tests when running atop stage1. Fix #13746 as well.
…hievink fix: add fallback case in generated `PartialEq` impl Partially fixes rust-lang#13727. When generating `PartialEq` implementations for enums, the original code can already generate the following fallback case: ```rs _ => std::mem::discriminant(self) == std::mem::discriminant(other), ``` However, it has been suppressed in the following example for no good reason: ```rs enum Either<T, U> { Left(T), Right(U), } impl<T, U> PartialEq for Either<T, U> { fn eq(&self, other: &Self) -> bool { match (self, other) { (Self::Left(l0), Self::Left(r0)) => l0 == r0, (Self::Right(l0), Self::Right(r0)) => l0 == r0, // _ => std::mem::discriminant(self) == std::mem::discriminant(other), // ^ this completes the match arms! } } } ``` This PR has removed that suppression logic. ~~Of course, the PR could have suppressed the fallback case generation for single-variant enums instead, but I believe that this case is quite rare and should be caught by `#[warn(unreachable_patterns)]` anyway.~~ After this fix, when the enum has >1 variants, the following fallback arm will be generated : * `_ => false,` if we've already gone through every case where the variants of `self` and `other` match; * The original one (as stated above) in other cases. --- Note: The code example is still wrong after the fix due to incorrect trait bounds.
…Veykril fix: add generic `TypeBoundList` in generated derivable impl Potentially fixes rust-lang#13727. Continuing with the work in rust-lang#13732, this fix tries to add correct type bounds in the generated `impl` block: ```diff enum Either<T, U> { Left(T), Right(U), } - impl<T, U> PartialEq for Either<T, U> { + impl<T: PartialEq, U: PartialEq> PartialEq for Either<T, U> { fn eq(&self, other: &Self) -> bool { match (self, other) { (Self::Left(l0), Self::Left(r0)) => l0 == r0, (Self::Right(l0), Self::Right(r0)) => l0 == r0, _ => false, } } } ```
There is something funky going on when I currently try to use
make check-stage1on a clean checkout of rust (commit e01e78f)https://gist.github.com/pnkfelix/11260219
Summary of how the story in that gist ends:
@alexcrichton says he often just runs
make check-stage1-rpass, so that is sort of a workaround for the near term.The text was updated successfully, but these errors were encountered: