error: unknown debugging option: `dual-proc-macros` when running cross tests #59110

mati865 · 2019-03-11T18:13:04Z

I'm working on tests for dynamic musl (#58575) and since #58013 I'm hitting:

Building stage0 compiler artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-musl)
error: failed to run `rustc` to learn about target-specific information

Caused by:
  process didn't exit successfully: `/checkout/obj/build/bootstrap/debug/rustc - --crate-name ___ --print=file-names -C target-feature=-crt-static --target x86_64-unknown-linux-musl --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro` (exit code: 1)
--- stderr
error: unknown debugging option: `dual-proc-macros`

[RUSTC-TIMING] ___ test:false 0.011

command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "build" "--target" "x86_64-unknown-linux-musl" "-Zdual-proc-macros" "-j" "16" "--release" "--locked" "--features" "" "--manifest-path" "/checkout/src/rustc/Cargo.toml" "--message-format" "json"
expected success, got: exit code: 101
failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test --host x86_64-unknown-linux-musl --target x86_64-unknown-linux-musl

Error comes from:

rust/src/bootstrap/bin/rustc.rs

Line 115 in f2ef283

cmd.arg("-Zdual-proc-macros");

The configuration is very unusual because the builder is x86_64-unknown-linux-gnu and both the host and the target are set to x86_64-unknown-linux-musl.

Full log from rebuild: https://gist.github.com/mati865/147c64df0f093117f730c78b66299d86

cc @Zoxc

The text was updated successfully, but these errors were encountered:

Zoxc · 2019-03-11T22:16:15Z

Are you overriding the rustc version used to compile?

Zoxc · 2019-03-11T22:20:04Z

Oh wait, that's trying to cross compile using the stage0 compiler, when it should be using the stage1 compiler.

ForceBru · 2019-03-17T19:30:17Z

The same happens when I try to build for armv7-apple-ios:

I tried to run the following command:

../x.py build -i  --stage 1 -j 4 --target armv7-apple-ios --host armv7-apple-ios src/libstd

Got the following output:

Updating only changed submodules
Submodules updated in 0.11 seconds
    Finished dev [unoptimized] target(s) in 2.28s
Building stage0 std artifacts (x86_64-apple-darwin -> armv7-apple-ios)
   Compiling core v0.0.0 (/Users/forcebru/Desktop/Test/RUST/rust/src/libcore)
   Compiling libc v0.2.46
   Compiling compiler_builtins v0.1.5
   Compiling unwind v0.0.0 (/Users/forcebru/Desktop/Test/RUST/rust/src/libunwind)
   Compiling backtrace-sys v0.1.27
   Compiling std v0.0.0 (/Users/forcebru/Desktop/Test/RUST/rust/src/libstd)
   Compiling rustc-std-workspace-core v1.0.0 (/Users/forcebru/Desktop/Test/RUST/rust/src/tools/rustc-std-workspace-core)
   Compiling alloc v0.0.0 (/Users/forcebru/Desktop/Test/RUST/rust/src/liballoc)
   Compiling panic_abort v0.0.0 (/Users/forcebru/Desktop/Test/RUST/rust/src/libpanic_abort)
   Compiling rustc-demangle v0.1.10
   Compiling panic_unwind v0.0.0 (/Users/forcebru/Desktop/Test/RUST/rust/src/libpanic_unwind)
warning: dropping unsupported crate type `dylib` for target `armv7-apple-ios`2: std                                                                                                                                                       

    Finished release [optimized] target(s) in 1m 00s
Copying stage0 std from stage0 (x86_64-apple-darwin -> x86_64-apple-darwin / armv7-apple-ios)
Building stage0 test artifacts (x86_64-apple-darwin -> armv7-apple-ios)
   Compiling proc_macro v0.0.0 (/Users/forcebru/Desktop/Test/RUST/rust/src/libproc_macro)
   Compiling getopts v0.2.17
   Compiling term v0.0.0 (/Users/forcebru/Desktop/Test/RUST/rust/src/libterm)
warning: dropping unsupported crate type `dylib` for target `armv7-apple-ios`4: proc_macro, getopts, term                                                                                                                                 

   Compiling test v0.0.0 (/Users/forcebru/Desktop/Test/RUST/rust/src/libtest)
warning: dropping unsupported crate type `dylib` for target `armv7-apple-ios`4: test                                                                                                                                                      

    Finished release [optimized] target(s) in 17.29s
Copying stage0 test from stage0 (x86_64-apple-darwin -> x86_64-apple-darwin / armv7-apple-ios)
Building stage0 std artifacts (x86_64-apple-darwin -> x86_64-apple-darwin)
    Finished release [optimized] target(s) in 1.28s
Copying stage0 std from stage0 (x86_64-apple-darwin -> x86_64-apple-darwin / x86_64-apple-darwin)
Building stage0 test artifacts (x86_64-apple-darwin -> x86_64-apple-darwin)
    Finished release [optimized] target(s) in 0.50s
Copying stage0 test from stage0 (x86_64-apple-darwin -> x86_64-apple-darwin / x86_64-apple-darwin)
Building stage0 compiler artifacts (x86_64-apple-darwin -> armv7-apple-ios)
error: failed to run `rustc` to learn about target-specific information

Caused by:
  process didn't exit successfully: `/Users/forcebru/Desktop/Test/RUST/rust/build_macos/build/bootstrap/debug/rustc - --crate-name ___ --print=file-names --target armv7-apple-ios --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro` (exit code: 1)
--- stderr
error: unknown debugging option: `dual-proc-macros`


command did not execute successfully: "/Users/forcebru/Desktop/Test/RUST/rust/build_macos/build/x86_64-apple-darwin/stage0/bin/cargo" "build" "--target" "armv7-apple-ios" "-Zdual-proc-macros" "-j" "4" "--release" "--features" "" "--manifest-path" "/Users/forcebru/Desktop/Test/RUST/rust/src/rustc/Cargo.toml" "--message-format" "json"
expected success, got: exit code: 101
failed to run: /Users/forcebru/Desktop/Test/RUST/rust/build_macos/build/bootstrap/debug/bootstrap build -i --stage 1 -j 4 --target armv7-apple-ios --host armv7-apple-ios src/libstd
Build completed unsuccessfully in 0:01:25

Building only the libraries with ../x.py --target=armv7-apple-ios check works fine.

mati865 · 2019-03-20T16:40:48Z

@Zoxc I came up with simple workaround:

diff --git a/src/bootstrap/bin/rustc.rs b/src/bootstrap/bin/rustc.rs
index ca86aeb810..b884d815bf 100644
--- a/src/bootstrap/bin/rustc.rs
+++ b/src/bootstrap/bin/rustc.rs
@@ -111,7 +111,7 @@ fn main() {
 
         // Link crates to the proc macro crate for the target, but use a host proc macro crate
         // to actually run the macros
-        if env::var_os("RUST_DUAL_PROC_MACROS").is_some() {
+        if env::var_os("RUST_DUAL_PROC_MACROS").is_some() && stage != "0" {
             cmd.arg("-Zdual-proc-macros");
         }

I've tried to make it use stage1 but I couldn't make bootstrap successful. In case you want to see where stage0 is coming from here is part of the log with some debug info:

Assembling stage2 compiler (x86_64-unknown-linux-musl)
[src/bootstrap/compile.rs:352] Std{compiler, target,} = Std {
    target: "x86_64-unknown-linux-musl",
    compiler: Compiler {
        stage: 2,
        host: "x86_64-unknown-linux-musl"
    }
}
Uplifting stage1 std (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-musl)
Copying stage2 std from stage1 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-musl / x86_64-unknown-linux-musl)
[src/bootstrap/compile.rs:965] Rustc{compiler: build_compiler, target: target_compiler.host,} = Rustc {
    target: "x86_64-unknown-linux-musl",
    compiler: Compiler {
        stage: 0,
        host: "x86_64-unknown-linux-gnu"
    }
}
[src/bootstrap/compile.rs:477] Test{compiler, target,} = Test {
    target: "x86_64-unknown-linux-musl",
    compiler: Compiler {
        stage: 0,
        host: "x86_64-unknown-linux-gnu"
    }
}
[src/bootstrap/compile.rs:352] Std{compiler, target,} = Std {
    target: "x86_64-unknown-linux-musl",
    compiler: Compiler {
        stage: 0,
        host: "x86_64-unknown-linux-gnu"
    }
}
Building stage0 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-musl)

Full log: https://gist.github.com/mati865/579d833afab7e0c77adbdb584f5ce869
Line numbers match with: https://github.com/rust-lang/rust/blob/0c8700b9d50a1e3d31f7b6c0956df555279ac441/src/bootstrap/compile.rs

Assemble ensures itself recursively until it hits stage0 in this line:

rust/src/bootstrap/compile.rs

Lines 957 to 958 in 0c8700b

    
           let build_compiler = 
        
               builder.compiler(target_compiler.stage - 1, builder.config.build);

Then it ensures there is Rustc for stage0:

rust/src/bootstrap/compile.rs

Lines 965 to 968 in 0c8700b

    
           builder.ensure(Rustc { 
        
               compiler: build_compiler, 
        
               target: target_compiler.host, 
        
           });

And then it builds other stage0 stuff until it hit's the error.

mati865 · 2019-03-20T17:27:07Z

During tests I'm getting:

/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-rustc/release/deps/rustc_macros-5dcf607750efd869: error while loading shared libraries: libstd-d301c78d889cf39d.so: cannot open shared object file: No such file or directory

Maybe this workaround isn't enough.

Zoxc · 2019-03-20T17:51:11Z

@mati865 I'd like to know what causes Assemble to be used. Can you run it with verbose output? (x.py -vv)

mati865 · 2019-03-20T18:03:17Z

@Zoxc every time compiler method is called it uses Assembly:

rust/src/bootstrap/builder.rs

Lines 570 to 574 in 0f88167

    
               pub fn compiler(&self, stage: u32, host: Interned<String>) -> Compiler { 
        
                   self.ensure(compile::Assemble { 
        
                       target_compiler: Compiler { stage, host }, 
        
                   }) 
        
               }

I'm in the middle of work on compiletest so I cannot run it right now. Will add new comment later.

Zoxc · 2019-03-20T18:12:22Z

@mati865 The question is, what is trying to obtain a stage 1 musl compiler?

mati865 · 2019-03-20T18:22:30Z

https://gist.github.com/mati865/39b6162632dbcde4564024726bd155b7
Interesting part:

Copying stage2 std from stage1 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-musl / x86_64-unknown-linux-musl)
          c Libdir { compiler: Compiler { stage: 2, host: "x86_64-unknown-linux-musl" }, target: "x86_64-unknown-linux-musl" }
          > Libdir { compiler: Compiler { stage: 2, host: "x86_64-unknown-linux-musl" }, target: "x86_64-unknown-linux-gnu" }
            c Sysroot { compiler: Compiler { stage: 2, host: "x86_64-unknown-linux-musl" } }
          < Libdir { compiler: Compiler { stage: 2, host: "x86_64-unknown-linux-musl" }, target: "x86_64-unknown-linux-gnu" }
          > Assemble { target_compiler: Compiler { stage: 1, host: "x86_64-unknown-linux-musl" } }
            c Assemble { target_compiler: Compiler { stage: 0, host: "x86_64-unknown-linux-gnu" } }
            > Rustc { target: "x86_64-unknown-linux-musl", compiler: Compiler { stage: 0, host: "x86_64-unknown-linux-gnu" } }
              > Test { target: "x86_64-unknown-linux-musl", compiler: Compiler { stage: 0, host: "x86_64-unknown-linux-gnu" } }
                > Std { target: "x86_64-unknown-linux-musl", compiler: Compiler { stage: 0, host: "x86_64-unknown-linux-gnu" } }
                  > StartupObjects { compiler: Compiler { stage: 0, host: "x86_64-unknown-linux-gnu" }, target: "x86_64-unknown-linux-musl" }
                  < StartupObjects { compiler: Compiler { stage: 0, host: "x86_64-unknown-linux-gnu" }, target: "x86_64-unknown-linux-musl" }
                  > Libdir { compiler: Compiler { stage: 0, host: "x86_64-unknown-linux-gnu" }, target: "x86_64-unknown-linux-musl" }
                    c Sysroot { compiler: Compiler { stage: 0, host: "x86_64-unknown-linux-gnu" } }
                  < Libdir { compiler: Compiler { stage: 0, host: "x86_64-unknown-linux-gnu" }, target: "x86_64-unknown-linux-musl" }
                  c Libdir { compiler: Compiler { stage: 0, host: "x86_64-unknown-linux-gnu" }, target: "x86_64-unknown-linux-gnu" }
                  c Sysroot { compiler: Compiler { stage: 0, host: "x86_64-unknown-linux-gnu" } }
Building stage0 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-musl)

mati865 · 2019-03-20T19:08:22Z

@Zoxc it goes like that:

rust/src/bootstrap/compile.rs

Line 237 in 0c8700b

builder.cargo(target_compiler, Mode::ToolStd, target, "clean");

⬇️

rust/src/bootstrap/builder.rs

Line 730 in 0c8700b

self.compiler(1, compiler.host)

⬇️

rust/src/bootstrap/compile.rs

Line 931 in 0c8700b

fn run(self, builder: &Builder<'_>) -> Compiler {

Zoxc · 2019-03-20T19:52:27Z

The builder.cargo(target_compiler part doesn't make sense, as we can't actually run the target_compiler, so trying to run cargo with it won't work.

@alexcrichton Do you know what is going on here?

mati865 · 2019-03-21T08:18:46Z

First introduced by cec6816 as part of #43630

alexcrichton · 2019-03-21T14:18:47Z

Can you elaborate a bit more on what's going on here? There's good deal of context here and I'm not sure how much is relevant

mati865 · 2019-03-21T15:05:00Z

I'll try to summarize it:
I'm patching up musl host tests and encountered this error after recent bootstrap changes in #58013. With this commit: mati865@4a53632 running ./src/ci/docker/run.sh dist-x86_64-musl will fail with error: unknown debugging option: dual-proc-macros because bootstrap builds stage0 musl compiler. It's because of this line:

rust/src/bootstrap/compile.rs

Line 237 in 0c8700b

builder.cargo(target_compiler, Mode::ToolStd, target, "clean");

builder::cargo calls builder::compiler(1, "musl") which runs Assembly:

rust/src/bootstrap/builder.rs

Lines 570 to 574 in 0c8700b

    
               pub fn compiler(&self, stage: u32, host: Interned<String>) -> Compiler { 
        
                   self.ensure(compile::Assemble { 
        
                       target_compiler: Compiler { stage, host }, 
        
                   }) 
        
               }

Then compile::Assemble runs recursively down to stage0:

rust/src/bootstrap/compile.rs

Line 958 in 0c8700b

builder.compiler(target_compiler.stage - 1, builder.config.build);

I'm trying to avoid it with mati865@efd45e9 but it's still wip and fails in the tests.

EDIT: The error from my hack is:

Testing rustc_macros stage1 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-musl)
running: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "test" "--target" "x86_64-unknown-linux-musl" "-Zdual-proc-macros" "-j" "16" "-v" "--release" "--locked" "--features" "" "--manifest-path" "/checkout/src/rustc/Cargo.toml" "-p" "rustc_macros" "--"
       Fresh unicode-xid v0.1.0
       Fresh proc-macro2 v0.4.24
       Fresh quote v0.6.10
       Fresh syn v0.15.22
       Fresh synstructure v0.10.1
       Fresh rustc_macros v0.1.0 (/checkout/src/librustc_macros)
    Finished release [optimized] target(s) in 0.23s
     Running `/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-rustc/release/deps/rustc_macros-5dcf607750efd869`
/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-rustc/release/deps/rustc_macros-5dcf607750efd869: error while loading shared libraries: libstd-d301c78d889cf39d.so: cannot open shared object file: No such file or directory
error: test failed, to rerun pass '--lib'

EDIT2:

$ find obj/build -name "libstd-d301c78d889cf39d.so" 
obj/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-d301c78d889cf39d.so
obj/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/release/deps/libstd-d301c78d889cf39d.so
obj/build/x86_64-unknown-linux-gnu/stage2/lib/libstd-d301c78d889cf39d.so

alexcrichton · 2019-03-21T20:27:01Z

Hm ok, thanks for the explanation! I'm not really up to speed on all this nowadays though so I'm not sure I'm gonna be all that much help here :(

mati865 · 2019-03-22T17:55:06Z

I think libstd-d301c78d889cf39d.so error is caused by different names of that library between gnu and musl. The same error shows when using either hack from #59110 (comment) or efd45e9.

ld will load dependencies ofrustc_macros in following order:

$ ldd obj/build/x86_64-unknown-linux-gnu/stage1-rustc/release/deps/rustc_macros-5dcf607750efd869
        linux-vdso.so.1 (0x00007ffd633aa000)
        libtest-f4db4b8ec8713e96.so => not found
        libstd-d301c78d889cf39d.so => not found
        libc.so.6 => /lib64/libc.so.6 (0x00007fb97f848000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fb97fc3c000)

$ find obj/build/x86_64-unknown-linux-gnu/stage1* -name "libtest-*.so"     
obj/build/x86_64-unknown-linux-gnu/stage1/lib/libtest-018b174132c5801e.so
obj/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-musl/lib/libtest-f4db4b8ec8713e96.so
obj/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/libtest-f4db4b8ec8713e96.so
obj/build/x86_64-unknown-linux-gnu/stage1-test/x86_64-unknown-linux-musl/release/deps/libtest-f4db4b8ec8713e96.so
obj/build/x86_64-unknown-linux-gnu/stage1-test/x86_64-unknown-linux-gnu/release/deps/libtest-f4db4b8ec8713e96.so

$ find obj/build/x86_64-unknown-linux-gnu/stage1* -name "libstd-*.so" 
obj/build/x86_64-unknown-linux-gnu/stage1/lib/libstd-3a98e985ce6b2adf.so
obj/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-musl/lib/libstd-0397b4f55aac49d0.so
obj/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-d301c78d889cf39d.so
obj/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-musl/release/deps/libstd-0397b4f55aac49d0.so
obj/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/release/deps/libstd-d301c78d889cf39d.so

@Zoxc does it make sense to you?

Zoxc · 2019-03-22T18:04:38Z

@mati865 The Testing rustc_macros stage1 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-musl) line seems pretty sketchy. We can't test while cross compiling.

mati865 · 2019-03-22T18:48:16Z

@Zoxc from the technical point of view there is nothing preventing from cross compiling musl on glibc distro and testing it. I abused bootstrap to do it before rustc_macros were introduced: https://api.travis-ci.com/v3/job/183417890/log.txt

Guess I'll try to use new musl host as stage0 once it makes it to the beta.

mati865 · 2019-04-17T21:58:22Z

Bootstrap compiler was updated so this issue shouldn't happen any more.

I'm not aware of any changes regarding stages flux but that's different issue.

infinity0 · 2019-06-10T06:08:55Z

I can confirm that this issue breaks cross-compiling on 1.34 using 1.33 as stage0. The fix from this comment works for me. Sucks that this wasn't backported for the 1.34.2 release.

infinity0 · 2019-06-10T06:18:17Z

Sorry my mistake, the problem is actually with the 1.35.0 currently-stable release, when using 1.34.2 as stage0. So there is still time to cherry pick this for a 1.35.1 point release if you guys want to. The very counter-intuitive error I get is:

[..]
        c Sysroot { compiler: Compiler { stage: 0, host: "x86_64-unknown-linux-gnu" } }
Building stage0 compiler artifacts (x86_64-unknown-linux-gnu -> i686-unknown-linux-gnu)
running: "/usr/bin/cargo" "build" "--target" "i686-unknown-linux-gnu" "-Zdual-proc-macros" "-j" "4" "-v" "-v" "--release" "--features" "" "--manifest-path" "/build/rustc-EamHhG/rustc-1.35.0+dfsg1/src/rustc/Cargo.toml" "--message-format" "json"
error: output of --print=file-names has changed in the compiler, cannot parse
command did not execute successfully: "/usr/bin/cargo" "build" "--target" "i686-unknown-linux-gnu" "-Zdual-proc-macros" "-j" "4" "-v" "-v" "--release" "--features" "" "--manifest-path" "/build/rustc-EamHhG/rustc-1.35.0+dfsg1/src/rustc/Cargo.toml" "--message-format" "json"
[..]

mati865 · 2019-06-10T09:07:28Z

@rustbot modify labels: +I-nominated +stable-nominated

rustbot · 2019-06-10T09:07:30Z

Error: Label I-nominated can only be set by Rust team members

Please let @rust-lang/release know if you're having trouble with this bot.

aidanhs · 2019-06-25T19:32:14Z

This hasn't made it into the stable being released and we're not looking to do a point release at this point, so removing stable-nominated

mati865 mentioned this issue Mar 12, 2019

Musl host toolchain #58575

Merged

mati865 closed this as completed Apr 17, 2019

mati865 reopened this Jun 10, 2019

Mark-Simulacrum added the regression-from-stable-to-stable Performance or correctness regression from one stable version to another. label Jun 10, 2019

pietroalbini added the stable-nominated Nominated for backporting to the compiler in the stable channel. label Jun 11, 2019

Mark-Simulacrum self-assigned this Jun 11, 2019

aidanhs removed the stable-nominated Nominated for backporting to the compiler in the stable channel. label Jun 25, 2019

mati865 closed this as completed Jul 2, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

error: unknown debugging option: `dual-proc-macros` when running cross tests #59110

error: unknown debugging option: `dual-proc-macros` when running cross tests #59110

mati865 commented Mar 11, 2019

Zoxc commented Mar 11, 2019

Zoxc commented Mar 11, 2019

ForceBru commented Mar 17, 2019

mati865 commented Mar 20, 2019

mati865 commented Mar 20, 2019

Zoxc commented Mar 20, 2019

mati865 commented Mar 20, 2019

Zoxc commented Mar 20, 2019

mati865 commented Mar 20, 2019

mati865 commented Mar 20, 2019

Zoxc commented Mar 20, 2019

mati865 commented Mar 21, 2019

alexcrichton commented Mar 21, 2019

mati865 commented Mar 21, 2019 •

edited

Loading

alexcrichton commented Mar 21, 2019

mati865 commented Mar 22, 2019

Zoxc commented Mar 22, 2019

mati865 commented Mar 22, 2019 •

edited

Loading

mati865 commented Apr 17, 2019

infinity0 commented Jun 10, 2019 •

edited

Loading

infinity0 commented Jun 10, 2019 •

edited

Loading

mati865 commented Jun 10, 2019

rustbot commented Jun 10, 2019

aidanhs commented Jun 25, 2019

error: unknown debugging option: dual-proc-macros when running cross tests #59110

error: unknown debugging option: dual-proc-macros when running cross tests #59110

Comments

mati865 commented Mar 11, 2019

Zoxc commented Mar 11, 2019

Zoxc commented Mar 11, 2019

ForceBru commented Mar 17, 2019

mati865 commented Mar 20, 2019

mati865 commented Mar 20, 2019

Zoxc commented Mar 20, 2019

mati865 commented Mar 20, 2019

Zoxc commented Mar 20, 2019

mati865 commented Mar 20, 2019

mati865 commented Mar 20, 2019

Zoxc commented Mar 20, 2019

mati865 commented Mar 21, 2019

alexcrichton commented Mar 21, 2019

mati865 commented Mar 21, 2019 • edited Loading

alexcrichton commented Mar 21, 2019

mati865 commented Mar 22, 2019

Zoxc commented Mar 22, 2019

mati865 commented Mar 22, 2019 • edited Loading

mati865 commented Apr 17, 2019

infinity0 commented Jun 10, 2019 • edited Loading

infinity0 commented Jun 10, 2019 • edited Loading

mati865 commented Jun 10, 2019

rustbot commented Jun 10, 2019

aidanhs commented Jun 25, 2019

error: unknown debugging option: `dual-proc-macros` when running cross tests #59110

error: unknown debugging option: `dual-proc-macros` when running cross tests #59110

mati865 commented Mar 21, 2019 •

edited

Loading

mati865 commented Mar 22, 2019 •

edited

Loading

infinity0 commented Jun 10, 2019 •

edited

Loading

infinity0 commented Jun 10, 2019 •

edited

Loading