make shell.nix better

[Nilstrieb]

This makes it less opinionated.

cc @Nadrieril @fee1-dead i know you're using nixos

[5225225]

One thing that would be useful is somehow getting x in the PATH and having it work.

Just doing

x_application = pkgs.writeShellApplication {
  name = "x";
  text = ''exec ${./x} "$@"'';
};

and putting that in nativeBuildInputs doesn't work, since the script looks up stuff relative to itself, which is fair enough.

x_application = pkgs.writeShellApplication {
  name = "x";
  text = ''
      cd "${builtins.toString ./.}"
      ./x "$@"
  '';
};

seems to work fine? I don't know nix or bootstrap terribly well so there's probably a cleaner way of doing this.

[Nadrieril]

Oh RUSTC_ICE is the setting I didn't know I needed x) So many files turning up for no apparent reason!

I agree with most of the changes except that I really liked the RUSTC_BOOTSTRAP_CONFIG example. I wouldn't have known it was an option but now I can share my config.toml between machines. You could perhaps edit the comment instead, to have it say "this is an example config.toml, edit at your convenience"?

[rowan-sl]

In order to fix #1812 nativeBuildInputs can be changed to include glibc.out glibc.static (in that order)

• additionally, gcc_multi can be removed Looks like it was used in a different part than the part of the test suite i ran

for some reason glibc.out doesn't create the issues with stdlib.h that glibc did - see this discussion

[Nadrieril]

I added gcc_multi because it was required to run the mir_opts tests (see this discussion)

[eopb]

I generally agree with this change but I think it would be a shame to get rid of the recommendation of patch-binaries-for-nix = true.

That line is needed for nix shells on non-NixOS systems because bootstrap doesn't have perfect nix detection. I added it in #1774.

If we are going to get rid of the config.toml part of this shell.nix we should probably recommend patch-binaries-for-nix separately on the same page.

[fee1-dead]

Thanks for the ping. I actually don't use a shell.nix for hacking the rust compiler, since I thought it would be more hassle free if I installed these required things globally.

It might be helpful to showcase that using nix to manage config.toml is possible, but leave a comment saying that if anyone wants to change the behavior to use the ./config.toml instead they can remove it.

[Nilstrieb]

In order to fix #1812 nativeBuildInputs can be changed to include glibc.out glibc.static (in that order)

* ~additionally, `gcc_multi` can be removed~ Looks like it was used in a different part than the part of the test suite i ran

for some reason glibc.out doesn't create the issues with stdlib.h that glibc did - see this discussion

lol, i tried this out with awesome results: compiling rustc with this causes a rustc that just hangs (when cargo is invoking it to figure out cfgs etc). no problem, I try to perf top to figure out what's going on.

perf: Segmentation fault

[rowan-sl]

In order to fix #1812 nativeBuildInputs can be changed to include glibc.out glibc.static (in that order)

* ~additionally, `gcc_multi` can be removed~ Looks like it was used in a different part than the part of the test suite i ran

for some reason glibc.out doesn't create the issues with stdlib.h that glibc did - see this discussion

lol, i tried this out with awesome results: compiling rustc with this causes a rustc that just hangs (when cargo is invoking it to figure out cfgs etc). no problem, I try to perf top to figure out what's going on.

perf: Segmentation fault

it has this problem when using the fix I gave? (or did you mean when gcc_multi is removed?)
(asking because it (at least the test suite) worked for me with this)

[Nilstrieb]

ok my perf is always broken somehow (???). I did remove gcc_multi because it's useless now (as mir opt tests now don't require C anymore) but the change I made is adding glibc.out glibc.static to nativeBuildInputs (shouldn't it be buildInputs too?) which makes programs (build scripts, rustc) hang... will debug it further and report back
@Nemo157 mentioned that it works though

[Nilstrieb]

moving it to buildInputs fixed the hangs. i do not want to know where they come from. but i will put it there, that seems more appropriate anyways.

[Nadrieril]

Can you try running ./x.py test tests/mir-opts --bless just to be sure? I remember gcc_multi being required for entirely silly reasons (bless is important because that runs more tests than without it 😅)

[Nilstrieb]

saethlin very recently made this not required anymore, being able to bless without a C toolchain.

[Nadrieril]

Ah I see, amazing then :D

[Nilstrieb]

This should be fine to merge now. We could also mention this in x setup when it detects nix (which it already) can, but that's something for later.