rust: 1.51.0 -> 1.52.0

[prusnak]

Motivation for this change

• update rustc to 1.52.0

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

[prusnak]

After the update, I tried to build fd and ripgrep. They both failed on missing libiconv error. Rather than adding libiconv to buildInputs of thousands of individual rust packages, I feel this is the better way to go.

[Mic92]

I tend to agree if this is a dependency of the rust stdlib, otherwise I would keep it rather explicit than bloating the default closure size.. What part in fd and ripgrep depends on libiconv?

[Mic92]

But let's ask some darwin maintainer: @LnL7 @thefloweringash @abathur

[happysalada]

I haven't been able to pinpoint it, but I think it's clap.
I've made the fix to about 10 packages so far. I don't mind, the only problem is that for some of them, people don't spot the breakage, until somebody running on darwin comes along.

[danieldk]

Prior discussion: #95556

[jonringer]

I think darwin support can be done in another PR. AFAIK, this would have been an existing issue, and I would rather not delay this PR. Darwin maintainers have around 5 days to come up with a solution before the final staging-next cycle will begin before branch-off of 21.05

[jonringer]

Also, I don't think having libiconv as a buildInput will bloat too much, as the likelihood of another package requiring it should be very high.

[danieldk]

I think I have found the culprit. The libc crate used to unconditionally link libiconv on Apple platforms:

    if target.contains("-apple-") {
        println!("cargo:rustc-link-lib=iconv");
    }

libc is a transitive dependency of many widely-used crates, such as rand, memchr, and chrono, so it percolates through much of the Nix ecosystem.

However, this dependency is now made conditional in libc (only needed when libiconv symbols are used):

rust-lang/libc#2150

So, I propose that we revert adding libiconv as a buildinput, since it will become unnecessary as more and more crates adopt the next version of libc.

[prusnak]

@danieldk Thanks for investigating the issue - I guess we can revert the libiconv addition together with once libc 0.2.95 update once it is out.

[danieldk]

Proposed PR to remove the dependency #122231.

[jonringer]

LGTM, thanks :)

https://github.com/NixOS/nixpkgs/pull/122110

1 package built:
ripgrep