Handle conflicts with system-installed `cargo`

[msprotz]

After doing git clean -fdx and rustup update on my Intel OSX machine, build fails for charon:

make
...
error[E0554]: `#![feature]` may not be used on the stable release channel
--> macros/src/lib.rs:4:1
  |
4 | #![feature(non_exhaustive_omitted_patterns_lint)]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^



For more information about this error, try `rustc --explain E0554`.
error: could not compile `macros` (lib) due to 1 previous error
warning: build failed, waiting for other jobs to finish...
make[1]: *** [Makefile:6: build] Error 101
make[1]: Leaving directory '/Users/jonathan/Code/charon/charon'
make: *** [Makefile:36: build-charon-rust] Error 2
jonathan@absinthe:~/Code/charon (main) $ git rev-parse head
45b95e0f63cb830202c0b3ca00a341a3451a02ba

Let me know if I'm doing anything wrong! Thank you.

[Nadrieril]

We discussed this on zulip, I believe the issue was that cargo was installed with homebrew and shadowed rustup's cargo. Since charon requires a precise version of rust, it can't build with a system-wide installed rustc toolchain. The solution is to uninstall the non-rustup toolchain, or to make sure rustup takes precedence (e.g. in the PATH variable).

[sonmarcho]

Should we close this issue?

[Nadrieril]

I was waiting for @msprotz to confirm that he can build charon now

[msprotz]

Yes it works now that I uninstalled the brew-provided cargo. Feel free to turn this into "warn against using system cargo", or "make sure cargo comes from rustup", or just close it. Thanks!

[Nadrieril]

I opened https://github.com/rust-lang/rustup/issues/3990, we should at least find a way to warn the user.

[Nadrieril]

For this one, before calling cargo we should check:

• if cargo is a symlink to a binary called rustup or rustup-init,all is good;
• if we're in a nix context we just trust the cargo version;
• otherwise we tell the user that they're using a systemwide version of rust but we require a very specific nightly. user should uninstall their version and install rustup instead.

When we're done we should test that this correctly reports an error on OS X in the case reported. We can always ask @msprotz to try again if we can't test it otherwise.

[protz]

FYI on my system there was some complex interaction between the path-modifying behaviors of brew, rustup and OPAM. Here are the comments I left in my bashrc once I managed to track this down:

  53 │ # Step 0: make sure brew itself is reachable via one of the usual locations.
  54 │ add_to_path_if "/opt/homebrew/bin"
  55 │ add_to_path_if "/usr/local/bin"
  56 │
  57 │ # Step 1: let brew trash the path by putting /usr/local/bin up front -- this
  58 │ # might shadow opam, rustc, cargo, etc. so this needs to be done first
  59 │ if $(which brew > /dev/null 2>&1); then
  60 │   . $(brew --prefix)/etc/bash_completion
  61 │   eval $(brew shellenv)
  62 │ fi
  63 │
  64 │ # Step 2: this one isn't too smart and will decline to export things right if
  65 │ # ~/.cargo/bin is already in the path (but possibly in the wrong spot), so it
  66 │ # needs to be *after* the brew shell setup.
  67 │ [ -f "$HOME/.cargo/env" ] && . "$HOME/.cargo/env"
  68 │
  69 │ # Step 3: OPAM, now findable at the right location
  70 │ if [ -d ~/.opam ]; then
  71 │   eval $(opam config env)
  72 │   . $HOME/.opam/opam-init/init.sh > /dev/null 2> /dev/null || true
  73 │ fi