Switch to using the v2 resolver in most workspaces

[tgross35]

Pinning the resolver to v1 was done in 5abff37 ("Explicit set workspace.resolver ...") in order to suppress warnings. Since there is no specific reason not to use the new resolver and since it fixes issues, change to resolver = "2" everywhere except library.

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

The list of allowed third-party dependencies may have been modified! You must ensure that any new dependencies have compatible licenses before merging.

cc @davidtwco, @wesleywiser

The run-make-support library was changed

cc @jieyouxu

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

Portable SIMD is developed in its own repository. If possible, consider making this change to rust-lang/portable-simd instead.

cc @calebzulawski, @programmerjake

[tgross35]

Split off of #128359 since the library was split off to its own Cargo.lock.

[klensy]

Why updating any deps here? There exist separate CI task (#127140, which stuck a little). As i understand, portable-simd developed in it's own repo (https://github.com/rust-lang/portable-simd), so shouldn't be changed here (at least this way it will be simpler to sync it)?

[tgross35]

Why updating any deps here? There exist separate CI task (#127140, which stuck a little). As i understand, portable-simd developed in it's own repo (https://github.com/rust-lang/portable-simd), so shouldn't be changed here (at least this way it will be simpler to sync it)?

For licensing - the WASM tools and the crates that depend on them all need to be the latest version. Otherwise we get duplicate versions with different licenses that confuses tidy, as mentioned in #128722 (comment). I can rebase after #127140 so the diff is smaller.

You are right about portable-simd, I will drop those changes.

[bors]

☔ The latest upstream changes (presumably #128783) made this pull request unmergeable. Please resolve the merge conflicts.

[Mark-Simulacrum]

r=me with this rebased

[tgross35]

Thanks Mark.

@bors r=Mark-Simulacrum

[bors]

📌 Commit 32fbbaa has been approved by Mark-Simulacrum

It is now in the queue for this repository.

[klensy]

rollup=never?

[tgross35]

Hopefully this shouldn't conflict with anything, maybe just

@bors rollup=iffy

[bors]

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing 45fbf41 to master...

[rust-timer]

Finished benchmarking commit (45fbf41): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	1.0%	[1.0%, 1.0%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary 2.2%, secondary -0.3%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	2.2%	[2.2%, 2.2%]	1
Regressions ❌ (secondary)	1.4%	[1.4%, 1.4%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.0%	[-2.0%, -2.0%]	2
All ❌✅ (primary)	2.2%	[2.2%, 2.2%]	1

Cycles

Results (primary -4.5%, secondary -2.5%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-4.5%	[-4.5%, -4.5%]	1
Improvements ✅ (secondary)	-2.5%	[-2.5%, -2.5%]	1
All ❌✅ (primary)	-4.5%	[-4.5%, -4.5%]	1

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 750.46s -> 749.421s (-0.14%)
Artifact size: 339.15 MiB -> 336.74 MiB (-0.71%)

[dpaoliello]

@rustbot label +relnotes

This change includes a new version of cc-rs which no longer supports Visual Studio 2013, which means that Rust will no longer use or consider the VS 2013 linker when building *-msvc targets.

[Mark-Simulacrum]

@tgross35 can we back that cc change out? It shouldn't go through a PR like this - probably merits t-compiler FCP?

(I'm not sure if we document which linker versions we consider, but I'm not comfortable landing it in a PR like this).

[dpaoliello]

Per INSTALL.md, VS 2017 is required:

rust/INSTALL.md

Line 199 in 636d7ff

MSVC builds of Rust additionally require an installation of Visual Studio 2017

Rustup's docs have also been updated, but it looks like it hasn't been deployed yet: rust-lang/rustup@4831701

That said, I don't think there's anything blocking older versions except for cc-rs support.

[Mark-Simulacrum]

INSTALL.md is ... not really the right place for that to be documented, it should probably go on the platform support page (rendered https://doc.rust-lang.org/nightly/rustc/platform-support.html) and doesn't appear there currently. I don't have any objection to raising the limit, but we should do that intentionally.

[tgross35]

I opened #129290 to pin to the version below that release, per rust-lang/cc-rs#1142. Bit surprising that this change was semver-compatible, but maybe that wasn't explicitly intentional.

@dpaoliello since you have the background here, maybe you could put up a PR upgrading to 1.1.x and changing the docs after my pinning PR merges? As a place for compiler FCP to get us unpinned.

[dpaoliello]

changing the docs

I assume you mean create a platform support page for the -msvc targets?

Bit surprising that this change was semver-compatible, but maybe that wasn't explicitly intentional.

If I recall, we went ahead with the change since 1) VS 2013 is out of support and 2) cc-rs's MSRV was bumped past the version where the Rust's INSTALL.md indicated that VS2017 was required.

Seems like there should be some guidance for bumping and documenting min tool versions somewhere. I know we've been waiting on changing the raw-dylib feature since we need a newer binutils version, but I can't find any docs that indicate what the min required version is.

[Mark-Simulacrum]

Removing relnotes since #129290 dropped the break.

[Veykril]

This seems to have broken most (if not all) ./x.py test compiler/<insert crate name here> invocations, failing with

error: none of the selected packages contains these features: jemalloc, llvm, max_level_info, rustc_use_parallel_compiler

for compiler/rustc_abi for example

[tgross35]

Maybe bootstrap needs to get adjusted to be more accurate with the feature flags it passes? Might be worth a new issue