Stream: t-compiler/help

Topic: petgraph wrong number of type arguments


Jake Goulding (Aug 11 2020 at 14:34, on Zulip):

I updated to 441fd2255763c2aeea616aeac61b2c795a4c5330 in my aarch64-darwin fork, and now I'm getting:

error[E0107]: wrong number of type arguments: expected 3, found 2
   --> /Users/shepmaster/.cargo/registry/src/github.com-1ecc6299db9ec823/petgraph-0.5.1/src/graphmap.rs:580:16
    |
580 |     edges: &'a IndexMap<(N, N), E>,
    |                ^^^^^^^^^^^^^^^^^^^ expected 3 type arguments

error[E0107]: wrong number of type arguments: expected 2, found 1
   --> /Users/shepmaster/.cargo/registry/src/github.com-1ecc6299db9ec823/petgraph-0.5.1/src/matrix_graph.rs:925:22
    |
925 |     removed_ids: &'a IndexSet<usize>,
    |                      ^^^^^^^^^^^^^^^ expected 2 type arguments

error[E0107]: wrong number of type arguments: expected 3, found 2
  --> /Users/shepmaster/.cargo/registry/src/github.com-1ecc6299db9ec823/petgraph-0.5.1/src/graphmap.rs:61:12
   |
61 |     nodes: IndexMap<N, Vec<(N, CompactDirection)>>,
   |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected 3 type arguments

error[E0107]: wrong number of type arguments: expected 3, found 2
  --> /Users/shepmaster/.cargo/registry/src/github.com-1ecc6299db9ec823/petgraph-0.5.1/src/graphmap.rs:62:12
   |
62 |     edges: IndexMap<(N, N), E>,
   |            ^^^^^^^^^^^^^^^^^^^ expected 3 type arguments

error[E0107]: wrong number of type arguments: expected 2, found 1
   --> /Users/shepmaster/.cargo/registry/src/github.com-1ecc6299db9ec823/petgraph-0.5.1/src/matrix_graph.rs:851:18
    |
851 |     removed_ids: IndexSet<usize>,
    |                  ^^^^^^^^^^^^^^^ expected 2 type arguments

Ring a bell for anyone?

Jake Goulding (Aug 11 2020 at 16:44, on Zulip):

I wasn't super clear, but this is while compiling rustc:

    SDKROOT=$(xcrun -sdk macosx11.0 --show-sdk-path) \
    MACOSX_DEPLOYMENT_TARGET=$(xcrun -sdk macosx11.0 --show-sdk-platform-version) \
    DESTDIR=~/crossed \
    ../../x.py install -i --stage 1 --host ../aarch64-apple-darwin.json --target aarch64-apple-darwin,x86_64-apple-darwin \
    src/librustc library/std
simulacrum (Aug 11 2020 at 20:31, on Zulip):

https://github.com/rust-lang/rust/pull/75309#issuecomment-672261875 seems similar

Jake Goulding (Aug 24 2020 at 13:31, on Zulip):

This is still happening :-(

Jake Goulding (Aug 24 2020 at 13:36, on Zulip):

Hm so indexmap is using autocfg to probe for std's presence, I think via this bit of code. My guess is that's not using the right rustc or not passing it the right parameters, but I'm not sure without seeing the actual build log from autocfg we'd be able to say much.

@simulacrum so if I could get that, maybe we could get unstuck?

Jake Goulding (Aug 24 2020 at 13:38, on Zulip):

@cuviper How may I get debugging output from autocfg?

simulacrum (Aug 24 2020 at 13:41, on Zulip):

Realistically I'm pretty unhappy about crates doing this in the first place, seems a bit hacky. I guess there's not too many better solutions...

simulacrum (Aug 24 2020 at 13:41, on Zulip):

(well, cargo features are the norm, and something I'd prefer)

Jake Goulding (Aug 24 2020 at 13:47, on Zulip):

Heh, it's something I have a light fight with for SNAFU as well. Having the "auto" is really nice, _but_. My soft plan there is to keep having v1_30 flags and a auto_detect flag, both of which are off-by-default.

Jake Goulding (Aug 24 2020 at 13:54, on Zulip):

Ah, here we go...

rustc command: "DYLD_LIBRARY_PATH"="/Users/shepmaster/Projects/rust/silicon/cross/build/x86_64-apple-darwin/stage0/lib" "/Users/shepmaster/Projects/rust/silicon/cross/build/x86_64-apple-darwin/stage0/bin/rustc" "--crate-name" "probe0" "--crate-type=lib" "--out-dir" "/Users/shepmaster/Projects/rust/silicon/cross/build/x86_64-apple-darwin/stage0-rustc/aarch64-apple-darwin/release/build/indexmap-2845cc4b8ddf50e9/out" "--emit=llvm-ir" "--cfg=bootstrap" "-Zdual-proc-macros" "-Zmacro-backtrace" "-Zosx-rpath-install-name" "-Clink-args=-Wl,-rpath,@loader_path/../lib" "-Zunstable-options" "-Wrustc::internal" "-Cprefer-dynamic" "-Cllvm-args=-import-instr-limit=10" "--target" "aarch64-apple-darwin" "-" "-Wrust_2018_idioms" "-Wunused_lifetimes" "-Dwarnings" "--sysroot" "/Users/shepmaster/Projects/rust/silicon/cross/build/x86_64-apple-darwin/stage0-sysroot" "-Z" "force-unstable-if-unmarked"
sysroot: "/Users/shepmaster/Projects/rust/silicon/cross/build/x86_64-apple-darwin/stage0-sysroot"
libdir: "/Users/shepmaster/Projects/rust/silicon/cross/build/x86_64-apple-darwin/stage0/lib"
<jemalloc>: Unsupported system page size
error: Error loading target specification: Could not find specification for target "aarch64-apple-darwin". Use `--print target-list` for a list of built-in targets
``
Jake Goulding (Aug 24 2020 at 13:56, on Zulip):

So it looks like there's a mismatch between which rustc is being used and the target

Jake Goulding (Aug 24 2020 at 13:57, on Zulip):

Because the bootstrap compiler doesn't know about aarch64-macos yet

Joshua Nelson (Aug 24 2020 at 13:59, on Zulip):

you could try RUSTFLAGS_NOT_BOOTSTRAP maybe?

Jake Goulding (Aug 24 2020 at 14:02, on Zulip):

Perhaps! But I can't reason through if this is bootstrap or not

simulacrum (Aug 24 2020 at 14:02, on Zulip):

yeah, build compiler for build scripts is always(?) set to the bootstrap compiler

simulacrum (Aug 24 2020 at 14:02, on Zulip):

well, I mean, it has to be in this case, you don't have another compiler

simulacrum (Aug 24 2020 at 14:03, on Zulip):

looking at that command it looks like it's failing in stage0 compiler artifacts compilation

Jake Goulding (Aug 24 2020 at 14:03, on Zulip):

One thing I don't understand is why this previously worked and recently changed.

simulacrum (Aug 24 2020 at 14:03, on Zulip):

indexmap I think only recently started doing this perhaps?

simulacrum (Aug 24 2020 at 14:03, on Zulip):

maybe not, not sure :)

Jake Goulding (Aug 24 2020 at 14:04, on Zulip):

It'd be fine to use the bootstrap compiler, so long as the --target path was passed

simulacrum (Aug 24 2020 at 14:04, on Zulip):

right, I guess someone is synthesizing a wrong rustc invocation, probably autocfg

Jake Goulding (Aug 24 2020 at 14:04, on Zulip):

Relevant part of my command line:

../../x.py install -i --stage 1 --host ../aarch64-apple-darwin.json --target aarch64-apple-darwin,x86_64-apple-darwin
simulacrum (Aug 24 2020 at 14:05, on Zulip):

oh

simulacrum (Aug 24 2020 at 14:05, on Zulip):

wait, that seems weird, why do you have .json for host but not target?

simulacrum (Aug 24 2020 at 14:05, on Zulip):

you can see that the bootstrap compiler is being run with "--target" "aarch64-apple-darwin"

Jake Goulding (Aug 24 2020 at 14:06, on Zulip):

I agree it's weird, but I'll fall back on the old chestnuts of "this used to work" and "I don't fully understand the build process"

Jake Goulding (Aug 24 2020 at 14:07, on Zulip):

I'm guessing that the most expedient fix would be for me to bump the bootstrap compiler so that I can abandon the json file

Jake Goulding (Aug 24 2020 at 14:07, on Zulip):

But I was thinking I might as well try to fix weird thing while I'm here, if it seems useful

bjorn3 (Aug 24 2020 at 14:07, on Zulip):

--host is what you build a compiler for. --target is what you build libstd for.

Jake Goulding (Aug 24 2020 at 14:11, on Zulip):

Sure. And the libstd is seemingly built with the compiler built from --host, which is why I could get away with using the built-in target then.

simulacrum (Aug 24 2020 at 14:14, on Zulip):

I think the problem is that cargo sets $TARGET for build scripts to the json-less path

simulacrum (Aug 24 2020 at 14:14, on Zulip):

but without knowing whether cargo is passed the json-less path, I'm not sure if that's cargo's fault or not

simulacrum (Aug 24 2020 at 14:14, on Zulip):

(json-less path => not a path at all)

simulacrum (Aug 24 2020 at 14:23, on Zulip):

@Jake Goulding do you have the cargo invocation?

Jake Goulding (Aug 24 2020 at 14:26, on Zulip):

I do not right now, but after this test with upgrading bootstrap I can get it again.

Jake Goulding (Aug 24 2020 at 14:27, on Zulip):

@simulacrum If I rebased with your PR for 1.46, would I also get a bootstrap bump?

simulacrum (Aug 24 2020 at 14:27, on Zulip):

hm which PR?

Jake Goulding (Aug 24 2020 at 14:28, on Zulip):

Oh, I guess you just reviewed it, not authored it (https://github.com/rust-lang/rust/pull/75878)

simulacrum (Aug 24 2020 at 14:28, on Zulip):

oh no you shouldn't rebase with that PR as your tip

Jake Goulding (Aug 24 2020 at 14:28, on Zulip):

Ok, good.

Jake Goulding (Aug 24 2020 at 14:29, on Zulip):

Oh, it's even going to the stable branch. yes.

simulacrum (Aug 24 2020 at 14:29, on Zulip):

if you want to bump bootstrap, edit src/stage0.txt to set date: to 2020-08-22

simulacrum (Aug 24 2020 at 14:29, on Zulip):

(or maybe 21, not sure)

Jake Goulding (Aug 24 2020 at 14:29, on Zulip):

Yeah, that's what I did, but then was looking for any other PRs that might have been updating it.

simulacrum (Aug 24 2020 at 14:29, on Zulip):

I think we talked about bumping but never actually did. We rarely do.

Jake Goulding (Aug 24 2020 at 14:30, on Zulip):

I suppose there will be a normal bump in the next week or so to get the next beta.0?

simulacrum (Aug 24 2020 at 14:30, on Zulip):

yeah, to 1.47-beta

simulacrum (Aug 24 2020 at 14:33, on Zulip):

@Jake Goulding to be clear, I suspect that there's either a cargo or bootstrap bug (though maybe hard to fix) wrt to treatment of $TARGET when --target is a file path, not a compiler-known triple

simulacrum (Aug 24 2020 at 14:33, on Zulip):

I suspect a cargo bug

Jake Goulding (Aug 24 2020 at 14:36, on Zulip):

sure. I certainly changed a lot of places in bootstrap to try and pass the file around, so I'd lean towards believing there's something I missed, TBH.

simulacrum (Aug 24 2020 at 14:39, on Zulip):

well I'd expect things to fail much earlier if we're not passing it to cargo correctly

simulacrum (Aug 24 2020 at 14:39, on Zulip):

and cargo is in charge of $TARGET

Jake Goulding (Aug 24 2020 at 14:53, on Zulip):

Just doing the bootstrap bump was sufficient, so that's good.

Jake Goulding (Aug 24 2020 at 14:53, on Zulip):

Now to restart and get that cargo error.

Jake Goulding (Aug 24 2020 at 15:17, on Zulip):

It's almost like it doesn't run Cargo again, which is nonsensical

Jake Goulding (Aug 24 2020 at 15:19, on Zulip):

Starting at the end of the log, I search backward for indexmap-1.5.1/build.rs:

rustc command: "DYLD_LIBRARY_PATH"="/Users/shepmaster/Projects/rust/silicon/cross/build/x86_64-apple-darwin/stage0/lib" "/Users/shepmaster/Projects/rust/silicon/cross/build/x86_64-apple-darwin/stage0/bin/rustc" "--crate-name" "build_script_build" "--edition=2018" "/Use
rs/shepmaster/.cargo/registry/src/github.com-1ecc6299db9ec823/indexmap-1.5.1/build.rs" "--error-format=json" "--json=diagnostic-rendered-ansi" "--crate-type" "bin" "--emit=dep-info,link" "-C" "opt-level=3" "-Cembed-bitcode=no" "-C" "debuginfo=0" "-C" "metadata=8c660252
da0efa04" "-C" "extra-filename=-8c660252da0efa04" "--out-dir" "/Users/shepmaster/Projects/rust/silicon/cross/build/x86_64-apple-darwin/stage0-rustc/release/build/indexmap-8c660252da0efa04" "-L" "dependency=/Users/shepmaster/Projects/rust/silicon/cross/build/x86_64-appl
e-darwin/stage0-rustc/release/deps" "--extern" "autocfg=/Users/shepmaster/Projects/rust/silicon/cross/build/x86_64-apple-darwin/stage0-rustc/release/deps/libautocfg-29bfb26e4fe2686c.rlib" "--cap-lints" "warn" "-Zbinary-dep-depinfo" "-Wrust_2018_idioms" "-Wunused_lifeti
mes" "-Dwarnings"

Then, the next preceding line that mentions indexmap is

Copy "/Users/shepmaster/Projects/rust/silicon/cross/build/x86_64-apple-darwin/stage0-rustc/x86_64-apple-darwin/release/deps/libindexmap-6714a9f0e483ccbd.rlib" to "/Users/shepmaster/Projects/rust/silicon/cross/build/x86_64-apple-darwin/stage0-sysroot/lib/rustlib/x86_64-
apple-darwin/lib/libindexmap-6714a9f0e483ccbd.rlib"
simulacrum (Aug 24 2020 at 15:27, on Zulip):

can you paste the full log? Cargo won't be run to build just indexmap

Jake Goulding (Aug 24 2020 at 15:27, on Zulip):

sure — you have a suggested location for ~4MB of text?

simulacrum (Aug 24 2020 at 15:28, on Zulip):

I'm only interested in running: "/home/mark/Build/rust/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "build" "--target" "x86_64-unknown-linux-gnu" "-Zbinary-dep-depinfo" "-j" "32" "-v" "--release" "--manifest-path" "/home/mark/Build/rust/src/tools/rustdoc/Cargo.toml"
and similar

Jake Goulding (Aug 24 2020 at 15:28, on Zulip):

Well that will never work... :cry: My name's not mark :wink:

Jake Goulding (Aug 24 2020 at 15:30, on Zulip):

./build/x86_64-apple-darwin/stage0/bin/cargo "build" "--target" "x86_64-apple-darwin" "-Zbinary-dep-depinfo" "-j" "32" "-v" "--release" "--manifest-path" "../../src/tools/rustdoc/Cargo.toml" — what's the magic "let me use -Z on beta env var?

simulacrum (Aug 24 2020 at 15:32, on Zulip):

@Jake Goulding no, I mean that running is part of the 4MB log hopefully

simulacrum (Aug 24 2020 at 15:32, on Zulip):

and the other running cargo lines

Jake Goulding (Aug 24 2020 at 15:33, on Zulip):

ah.

% grep -F '"build"' /tmp/build.log
running: "/Users/shepmaster/Projects/rust/silicon/cross/build/x86_64-apple-darwin/stage0/bin/cargo" "build" "--target" "x86_64-apple-darwin" "-Zbinary-dep-depinfo" "-j" "4" "-v" "-v" "-v" "-v" "-v" "--release" "--features" "panic-unwind backtrace compiler-builtins-c" "--manifest-path" "/Users/shepmaster/Projects/rust/library/test/Cargo.toml" "--message-format" "json-render-diagnostics"
running: "/Users/shepmaster/Projects/rust/silicon/cross/build/x86_64-apple-darwin/stage0/bin/cargo" "build" "--target" "x86_64-apple-darwin" "-Zbinary-dep-depinfo" "-j" "4" "-v" "-v" "-v" "-v" "-v" "--release" "--features" " llvm" "--manifest-path" "/Users/shepmaster/Projects/rust/src/rustc/Cargo.toml" "--message-format" "json-render-diagnostics"
running: "/Users/shepmaster/Projects/rust/silicon/cross/build/x86_64-apple-darwin/stage0/bin/cargo" "build" "--target" "../aarch64-apple-darwin.json" "-Zbinary-dep-depinfo" "-j" "4" "-v" "-v" "-v" "-v" "-v" "--release" "--features" "panic-unwind backtrace compiler-builtins-c" "--manifest-path" "/Users/shepmaster/Projects/rust/library/test/Cargo.toml" "--message-format" "json-render-diagnostics"
running: "/Users/shepmaster/Projects/rust/silicon/cross/build/x86_64-apple-darwin/stage0/bin/cargo" "build" "--target" "../aarch64-apple-darwin.json" "-Zdual-proc-macros" "-Zbinary-dep-depinfo" "-j" "4" "-v" "-v" "-v" "-v" "-v" "--release" "--features" " llvm" "--manifest-path" "/Users/shepmaster/Projects/rust/src/rustc/Cargo.toml" "--message-format" "json-render-diagnostics"
command did not execute successfully: "/Users/shepmaster/Projects/rust/silicon/cross/build/x86_64-apple-darwin/stage0/bin/cargo" "build" "--target" "../aarch64-apple-darwin.json" "-Zdual-proc-macros" "-Zbinary-dep-depinfo" "-j" "4" "-v" "-v" "-v" "-v" "-v" "--release" "--features" " llvm" "--manifest-path" "/Users/shepmaster/Projects/rust/src/rustc/Cargo.toml" "--message-format" "json-render-diagnostics"
simulacrum (Aug 24 2020 at 15:33, on Zulip):

My guess is that we'll see --target aarch64....json being passe to Cargo, but cargo is passing it without .json to build scripts in $TARGET, which means autocfg will not (in general) work

simulacrum (Aug 24 2020 at 15:33, on Zulip):

yeah that seems to be the case

simulacrum (Aug 24 2020 at 15:33, on Zulip):

so, in general, this is a cargo "bug" or autocfg is buggy, depending on how you think about what $TARGET means

Jake Goulding (Aug 24 2020 at 15:34, on Zulip):

Very strange, as doing this kind of thing is super common for embedded

simulacrum (Aug 24 2020 at 15:35, on Zulip):

well, I imagine that it's relatively rare for build scripts to do this

simulacrum (Aug 24 2020 at 15:35, on Zulip):

afaik most build scripts don't invoke rustc, or if they do, they don't invoke it in a target-specific setting

simulacrum (Aug 24 2020 at 15:41, on Zulip):

If you could file a cargo issue and cc me on it that'd be great

Jake Goulding (Aug 24 2020 at 15:52, on Zulip):

Sure. Any thoughts on how to make a repro? I was thinking something like

# Same target as default, but in a file
rustc +nightly -Z unstable-options --print target-spec-json > my-target.json
# Try to use it
cargo +nightly build --target $PWD/my-target.json -Z build-std

but that seems to have issues compiling std.

Jake Goulding (Aug 24 2020 at 15:59, on Zulip):

@Eric Huss does this ring any bells?

% cargo +nightly build --target $PWD/my-target.json -Z build-std --verbose

...

error[E0432]: unresolved imports `crate::sys_common::net::getsockopt`, `crate::sys_common::net::setsockopt`, `crate::sys_common::net::sockaddr_to_addr`
 --> /Users/shep/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/std/src/sys/unix/net.rs:8:30
  |
8 | use crate::sys_common::net::{getsockopt, setsockopt, sockaddr_to_addr};
  |                              ^^^^^^^^^^  ^^^^^^^^^^  ^^^^^^^^^^^^^^^^ no `sockaddr_to_addr` in `sys::unix::net`
  |                              |           |
  |                              |           no `setsockopt` in `sys::unix::net`
  |                              no `getsockopt` in `sys::unix::net`

error[E0432]: unresolved import `crate::sys_common::net::LookupHost`
  --> /Users/shep/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/std/src/net/addr.rs:12:5
   |
12 | use crate::sys_common::net::LookupHost;
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `LookupHost` in `sys::unix::net`

error[E0433]: failed to resolve: could not find `TcpStream` in `net_imp`
bjorn3 (Aug 24 2020 at 16:09, on Zulip):

Does https://github.com/rust-lang/rust/blob/80fb3f3139c7dee7f211964c6a0b3ccb04b83d5e/library/std/build.rs#L41 get run or the fallback https://github.com/rust-lang/rust/blob/80fb3f3139c7dee7f211964c6a0b3ccb04b83d5e/library/std/build.rs#L91? What is the name of the target spec json file?

Jake Goulding (Aug 24 2020 at 16:10, on Zulip):

You mean in the (attempted) repro? --target $PWD/my-target.json

bjorn3 (Aug 24 2020 at 16:11, on Zulip):

Yes. Does it work if you name the file $PWD/aarch64-apple-darwin.json or something like that with the substring apple-darwin?

Jake Goulding (Aug 24 2020 at 16:11, on Zulip):

yeah, renaming it now. I guess I got stupidly lucky with respect to that when I started this whole thing

cuviper (Aug 24 2020 at 16:14, on Zulip):

Jake Goulding said:

cuviper How may I get debugging output from autocfg?

The only real option at the moment is to find the stderr file that cargo captures from the build script, but that will only have error output from its compiler invocations. It would probably be a good idea to add an environment DEBUG_AUTOCFG that dumps more from autocfg itself...

Eric Huss (Aug 24 2020 at 16:14, on Zulip):

@Jake Goulding Yea, there are a bunch of places that look at the target name (that shouldn't). I think in this case the JSON filename needs a substring like "apple-darwin" in it.

cuviper (Aug 24 2020 at 16:15, on Zulip):

target-json issues are new to me, but there are similar issues with RUSTFLAGS: https://github.com/cuviper/autocfg/issues/15

Jake Goulding (Aug 24 2020 at 16:16, on Zulip):

Yeah, I'm seeing something like this now in my smaller repro:

[repro 0.1.0] error[E0463]: can't find crate for `std`
[repro 0.1.0]   |
[repro 0.1.0]   = note: the `apple-darwin-x86_64-fork` target may not be installed
[repro 0.1.0]
[repro 0.1.0] error: aborting due to previous error

Trying to see if it's a Cargo or autocfg issue before I file something

Eric Huss (Aug 24 2020 at 16:17, on Zulip):

If you want to make progress on fixing things, one place to start is https://github.com/rust-lang/rust/blob/master/library/std/build.rs, where it should be looking at CARGO_CFG_TARGET_* values instead of TARGET.

Eric Huss (Aug 24 2020 at 16:38, on Zulip):

I posted https://github.com/rust-lang/wg-cargo-std-aware/issues/6#issuecomment-679237914 with a list of other places that are sensitive to the JSON filename.

Jake Goulding (Aug 24 2020 at 18:18, on Zulip):

@simulacrum https://github.com/rust-lang/cargo/issues/8646

simulacrum (Aug 24 2020 at 18:51, on Zulip):

Thanks!

Last update: Sep 28 2020 at 14:00UTC