Closed
Description
When I compile serde_codegen 0.7.8
with -Z orbit
on Windows 32-bit, I get this error:
Assertion failed: isa<X>(Val) && "cast<Ty>() argument of incompatible type!", file C:\bot\slave\nightly-dist-rustc-win-msvc-32\build\src\llvm\include\llvm/Support/Casting.h, line 223
Build failed, waiting for other jobs to finish...
error: Could not compile `serde_codegen`.
Meta:
Alexander@VAIO-FZ13 MINGW64 ~
$ rustc -vV
rustc 1.11.0-nightly (1c975eafa 2016-06-05)
binary: rustc
commit-hash: 1c975eafa934e291e4f94b7252faae767de17313
commit-date: 2016-06-05
host: i686-pc-windows-msvc
release: 1.11.0-nightly
The build succeeds at least on OS X.
Metadata
Metadata
Assignees
Type
Projects
Relationships
Development
No branches or pull requests
Activity
retep998 commentedon Jun 6, 2016
The biggest codegen difference between -msvc and other targets is the SEH exception stuff, which may be causing this, possibly.
eddyb commentedon Jun 7, 2016
Hang on, that includes the changes which broke
syntex_syntax
and which I fixed in #34128.@alexbool What version did you try on OSX?
alexbool commentedon Jun 7, 2016
@eddyb version on OS X is:
eddyb commentedon Jun 7, 2016
@alexbool Hmm, that's the same version, it shouldn't be able to compile
syntex_syntax
withRUSTFLAGS=-Zorbit
.Unless version
0.7
is old enough that it doesn't sportstruct Name(u32);
(that definition used to betype Name = u32;
which would explain why it works).@retep998 started a windows build of #34128, so we might find out soon, one way or another.
alexbool commentedon Jun 7, 2016
@eddyb I am trying to make a minimal example now, seems that it isn't so easy
eddyb commentedon Jun 7, 2016
@alexbool A backtrace or the last hundred or so lines from
RUST_LOG=rustc_trans::mir
could reveal the problem but I doubt either is possible on the MSVC nightly.alexbool commentedon Jun 7, 2016
@eddyb UPD only happens on release builds. Minimal example on the way
alexbool commentedon Jun 7, 2016
Cargo.toml
src/lib.rs
~/.cargo/config
(removing
-Ctarget-cpu=native
doesn't help)alexbool commentedon Jun 7, 2016
Also build options (
-Ctarget-cpu=native -Zorbit -Ctarget-cpu=native -Zorbit
) are somehow passed twice, seems like there's also a cargo bugeddyb commentedon Jun 7, 2016
@alexbool Isn't it easier to just run
RUSTFLAGS=-Zorbit cargo build
inserde_codegen
's source dir?alexbool commentedon Jun 7, 2016
@eddyb Yep, something like this works:
eddyb commentedon Jun 11, 2016
@alexbool Does this still happen on the latest nightly?
alexbool commentedon Jun 11, 2016
@eddyb latest nightly broke aster, so nope. I will recheck when it's fixed
alexbool commentedon Jun 12, 2016
Still reproduces on latest nightly and
serde-codegen 0.7.10
22 remaining items
alexcrichton commentedon Jun 15, 2016
Ok, @brson and I will work on #34055, and once that's landed we can try to land an LLVM update, and hopefully that'll just magically fix this!
alexcrichton commentedon Jun 27, 2016
I've added this to the "Launch MIR into Orbit" milestone, but feel free to correct me if that was in error!
eddyb commentedon Jun 27, 2016
@alexbool Sounds good. What's the status of the LLVM update?
alexcrichton commentedon Jun 27, 2016
I'm not personally actively working on it, but @brson has posted about it here and here. We may want a little bit of extra coordinate to support both emscripten and AVR, but may just want to coordinate in this thread
nikomatsakis commentedon Jun 27, 2016
@alexcrichton seems like it qualifies for milestone to me.
nikomatsakis commentedon Jul 27, 2016
Do we believe that this is platform specific? The original comment mentions that it fails on Windows 32-bit, but not Mac -- what about linux? Other versions of Windows?
alexbool commentedon Jul 28, 2016
I cannot repriduce this on Linux. Did not try Windows 64 bit
eddyb commentedon Aug 1, 2016
@alexbool Next nightly (~20h from now) should be fixed. Will close when we have confirmation.
alexbool commentedon Aug 1, 2016
OK, I'll try
eddyb commentedon Aug 1, 2016
@alexbool FWIW both @alexcrichton and me and have tried and can't reproduce on beta or nightly.
I also can't reproduce on a local build that includes the LLVM upgrade, so this is most likely fixed now.
alexbool commentedon Aug 2, 2016
@eddyb I can confirm that with the latest nightly it doesn't reproduce