Compiler Crashes when trying to create a label in inline assembler with macros.

[FabianB1998]

Compiler Crashes when trying to create a label in inline assembler with macros. I am not sure if my could would work, but I am pretty sure it should not crash the compiler.

I tried this code: https://pastebin.com/pxCPeQnt

https://pastebin.com/WK4ydW8i
This does not crash, it seems it is somehow relating to the input formatting

I expected to see this happen: Generate a code sample with the given id
Instead, this happened: Compiler crashes

rustc --version --verbose:

rustc 1.30.0-nightly (73c7873 2018-08-05)
binary: rustc
commit-hash: 73c7873
commit-date: 2018-08-05
host: x86_64-pc-windows-msvc
release: 1.30.0-nightly
LLVM version: 7.0

Backtrace:
https://hastebin.com/xeyokeriqo.rb or https://pastebin.com/gDAvd4wQ
(Github keeps messing with the windows formatting)

[estebank]

playground:

error: internal compiler error: librustc_codegen_llvm/mir/operand.rs:145: not immediate: OperandRef(Pair(([0 x i8]*:[0 x i8]* bitcast (<{ [9 x i8] }>* @1 to [0 x i8]*)), (i64:i64 9)) @ TyLayout { ty: &str, details: LayoutDetails { variants: Single { index: 0 }, fields: Arbitrary { offsets: [Size { raw: 0 }, Size { raw: 8 }], memory_index: [0, 1] }, abi: ScalarPair(Scalar { value: Pointer, valid_range: 1..=18446744073709551615 }, Scalar { value: Int(I64, false), valid_range: 0..=18446744073709551615 }), align: Align { abi_pow2: 3, pref_pow2: 3 }, size: Size { raw: 16 } } })

thread 'main' panicked at 'Box<Any>', librustc_errors/lib.rs:587:9
note: Run with `RUST_BACKTRACE=1` for a backtrace.
error: aborting due to previous error

[levex]

Fixed by #54747, no longer reproduces on the playground by @estebank . Also, the span will be improved by #55087. Thanks!

[estebank]

@levex could you add a test for this repro case? The only thing left to close this ticket is a repro test in the repo to avoid regressions.

[levex]

@estebank sure i'll take this. ETA this week.

[AB1908]

@levex could you add a test for this repro case? The only thing left to close this ticket is a repro test in the repo to avoid regressions.

@estebank: If I RTFMed correctly, I think the test should be a compile-fail type which should be added according to the test adding guide. Is this correct?

[estebank]

@AB1908 almost, we're phasing compile-fail away, being subsumed by ui tests. You can create .stderr files for your new tests using ./x.py test src/test/ui --stage1 --bless.

[AB1908]

So do I go ahead and create a regular test and then use `x.py`? Also, how was I supposed to find out about the phasing out of `compile-fail`? I wasn't exactly thorough when looking through the docs. Thanks for the help.

[estebank]

So do I go ahead and create a regular test and then use x.py?

Correct. That will compile the compiler, run the tests and update the .stderr files that the test suite compares against. Then the tests get run again to compare the json output against the comments (like //^ ERROR error desc).

Also, how was I supposed to find out about the phasing out of compile-fail?

@AB1908 I think there hasn't been a hard policy announced, but that's the direction we're going in.

https://rust-lang.github.io/rustc-guide/tests/adding.html#what-kind-of-test-should-i-add
#53353
#44844

[AB1908]

I think that should do it.