Increase the minimum linux-gnu versions #95026

cuviper · 2022-03-16T22:18:08Z

This is implementing the MCP from rust-lang/compiler-team#493. It is
increasing the minimum requirements of a couple Tier 1 targets, and
others at lower tiers, so this should go through FCP sign-offs for both
T-compiler and T-release.

The new linux-gnu baseline is kernel 3.2 and glibc 2.17. We will also
take that kernel as the minimum floor for all *-linux-* targets, so
it may be broadly assumed in the implementation of the standard library.
That does not preclude specific targets from having greater requirements
where it makes sense, like a new arch needing something newer, or a
platform like linux-android choosing a newer baseline.

rust-highfive · 2022-03-16T22:18:12Z

r? @pietroalbini

(rust-highfive has picked a reviewer for you, use r? to override)

cuviper · 2022-03-16T22:23:50Z

src/doc/rustc/src/platform-support.md

@@ -30,14 +30,14 @@ All tier 1 targets with host tools support the full standard library.

 target | notes
 -------|-------
-`aarch64-unknown-linux-gnu` | ARM64 Linux (kernel 4.2, glibc 2.17+) [^missing-stack-probes]
+`aarch64-unknown-linux-gnu` | ARM64 Linux (kernel 4.1, glibc 2.17+) [^missing-stack-probes]


Note that this one actually went backwards because crosstool-ng 1.24 doesn't have kernel 4.2, but the nearest are 4.1.49 or 4.4.174. It doesn't make any practical difference AFAIK.

Hmmm. 4.4 is Ubuntu 16 and is "Super LTS", so if we rolled forward here it would be easier to test compliance.

And, well, there were also significant improvements in the Linux kernel's arm64 support in 4.2, 4.3, and 4.4, in particular in atomics and page support. so I think it might actually be better to roll forward, if we have to move one way or another.

Many modern Asus wifi6/ax routers are running the 4.1 kernel so I'm glad and appreciate that 4.1 is the baseline for aarch64. I hope it remains there until such time all linux targets are moved beyond this version.

src/ci/docker/host-x86_64/dist-i686-linux/Dockerfile

jonhoo · 2022-03-17T17:12:09Z

This feels worthy of a blog post either to the main Rust blog or to the Inside Rust blog, since it may require some action inside larger organizations using Rust. I also wonder if it might be valuable to delay by at least one stable release after the announcement to give more than one release cycle for big users to make changes they may need to make to absorb this change. Especially because this doesn't feel like a change that it's critical to get out the door asap, unless I'm missing something?

cuviper · 2022-03-21T20:11:15Z

@jonhoo FWIW this should get at least a little visibility by the FCP section of TWiR, but I suppose we could make a more specific announcement. Do you happen to know of any orgs that will be impacted?

I also wonder if it might be valuable to delay by at least one stable release after the announcement to give more than one release cycle for big users to make changes they may need to make to absorb this change.

There's the natural delay between stuff landing on master before it rides the train to stable, between 6-12 weeks depending on when it merges in the cycle. That's also after the FCP waiting period. Do you imagine needing more than that? I also expect that such careful big orgs can delay their adoption of a new release as needed, on their own time.

jonhoo · 2022-03-21T21:51:07Z

FWIW this should get at least a little visibility by the FCP section of TWiR, but I suppose we could make a more specific announcement.

This feels like a big enough change to a Tier 1 platform that it's worth a blog post to at least the Inside Rust blog.

Do you happen to know of any orgs that will be impacted?

Amazon + AWS :)

There are a non-trivial number of environments where for one reason or another we are stuck on older versions of GLIBC with "migrate to a newer platforms" is the way to get off of them. Many have migrated, but many are still putting pretty big wheels in motion and will take time to move.

Now, that's not to say we should block upgrading GLIBC for Rust — quite to the contrary. I think Rust moving on is (another) good incentive for those "big wheels" to get moving. But it does suggest that it's worthwhile to give fair warning before making the change (see below).

There's the natural delay between stuff landing on master before it rides the train to stable, between 6-12 weeks depending on when it merges in the cycle. That's also after the FCP waiting period. Do you imagine needing more than that?

Depends on how quickly the FCP lands and when in the release cycle it's released. My thinking was something like two stable releases after the deprecation announcement is posted, which gives about three months of advance warning.

I also expect that such careful big orgs can delay their adoption of a new release as needed, on their own time.

Two points on this, more to give context than anything else.

First, I don't think it's necessarily careful orgs that get hit by this. Instead, it's more a matter of practicality at scale that some users are harder to move than others. Platforms with newer GLIBCs have been available internally for a long time, but when you're running X million lines of code in production on Y hosts with Z users worldwide, something as big as a platform change has to be approached very deliberately and takes time to minimize customer impact.

Second, while it's true that big orgs (or subsets of big orgs) can choose not to adopt new Rust releases if, say, they won't work with the version of GLIBC they happen to be stuck on, doing so comes with its own (often significant) risks. It may mean not getting critical Rust point releases, being unable to take updates to library dependencies that bump their MSRV, or being subject to miscompilations or other compiler bugs with no easy recourse.

I don't say that to argue this change shouldn't happen — again, I definitely think it should — just that it's a change that should be given fair warning and lenient lead time, especially given that it's not urgent for Rust itself to land this change.

cuviper · 2022-03-21T22:07:22Z

OK, that's all fair. I'm often on that conservative side as well with my Red Hat on -- but that also makes me feel relief when I can finally let an old target go. :) So thanks for that added context, and for registering this as non-blocking. I think that's a reasonable request for an Inside Rust post and two more stable releases as-is.

r? @Mark-Simulacrum perhaps? (on both the PR and this plan)

pietroalbini · 2022-03-21T22:38:19Z

I can review it tomorrow, sorry for the delay 🙂

r? @pietroalbini

pietroalbini

The code changes look good! It'd be nice in the future to make the crosstools config changes actually reviewable, but I trust you did the right tweaks there.

Regarding the communication, the target tier policy states this:

Raising the baseline expectations of a tier 1 target (such as the minimum CPU features or OS version required) requires the approval of the compiler and release teams, and should be widely communicated as well, but does not necessarily require a full RFC.

In addition to the FCP I think it's reasonable to have another two stable releases as-is and mention the future compatibility change in the relnotes and blog post (just a line in the end) of those two releases.

src/ci/docker/host-x86_64/dist-armv7-linux/Dockerfile

pietroalbini · 2022-03-23T21:22:58Z

r=me whenever this is ready to merge

cuviper · 2022-03-23T23:38:04Z

It's ready as far as I'm concerned, but don't you need to initiate the FCP as the reviewer?

jonhoo · 2022-03-24T00:25:13Z

If the goal is to have two stable releases with this change after it is first announced, then the earliest we should merge this is April 8th assuming the change will be mentioned in the release notes for 1.60 on April 7th.

Speaking of, should we mark this as relnotes? Or do something else to ensure it'll actually be included in the 1.60 release notes even though the change itself hasn't been merged.

cuviper · 2022-03-24T15:12:48Z

I have the relnotes pr for 1.60, #94817, so I can add that. How do we want to phrase it right now? Say that we will change in 1.62, or just that we're planning to -- and are we soliciting feedback?

(I presume we'll have a more definitive statement in 1.61.)

pietroalbini · 2022-03-24T16:13:31Z

@rfcbot fcp merge

rfcbot · 2022-03-24T17:16:41Z

estebank · 2022-03-24T18:34:11Z

If the goal is to have two stable releases with this change after it is first announced, then the earliest we should merge this is April 8th assuming the change will be mentioned in the release notes for 1.60 on April 7th.

It might be prudent to delay the switch even further and publicize our intent ASAP in order to give enough time for people to make their concerns heard. Even if we might end up deciding that what we find aren't blockers, we might be made aware of some that we haven't yet seen.

Mark-Simulacrum · 2022-03-25T02:42:19Z

I have the relnotes pr for 1.60, #94817, so I can add that. How do we want to phrase it right now? Say that we will change in 1.62, or just that we're planning to -- and are we soliciting feedback?

(I presume we'll have a more definitive statement in 1.61.)

I think just an initial timeline is the right approach here; I would not set a hard expectation of 1.62. In particular, if we get strong feedback that seems actionable (i.e., has a concrete and trusted timeline attached) for ~X release cycles being enough that someone moves off the removed platforms in time, I think that would be worthwhile to consider at least. (Depends on the X, at least, of course).

There is some negative value to a floating window, but I think we can commit to deprecation starting now (~1.61), which just means an edit to the tier support page. As a reversible decision I feel comfortable r+ing that without FCP. We can use the blog post from 1.60 / release notes to determine if we have a 1-cycle (1.61 deprecated, 1.62 removed) deprecation or a longer time period there.

oblique · 2022-08-08T10:58:17Z

Correct me if I'm wrong, but the minimum Linux version for glibc 2.17 is Linux 2.6.19. Based on this, can you reevaluate the minimum Linux kernel version?

glibc increases its requirements to Linux 3.2 on 2.24 version. I'm actually using an ARM embedded system with glibc 2.23 and Linux 3.0.

slanterns · 2022-08-08T11:44:08Z

Correct me if I'm wrong, but the minimum Linux version for glibc 2.17 is Linux 2.6.19. Based on this, can you reevaluate the minimum Linux kernel version?

glibc increases its requirements to Linux 3.2 on 2.24 version. I'm actually using an ARM embedded system with glibc 2.23 and Linux 3.0.

It's also about which system apis can be used in libstd. So I think it's a rather fair choice (especially for most of the Rust users with a kernel version >= 3.2).

cuviper · 2022-08-08T21:26:09Z

Correct me if I'm wrong, but the minimum Linux version for glibc 2.17 is Linux 2.6.19. Based on this, can you reevaluate the minimum Linux kernel version?

That would in effect be doubling our minimum period, taking an old glibc version and using its even older minimum kernel version that made sense at that time. Glibc 2.17 was released on 2012-12-24, and Linux 2.6.19 was released much further back on 2006-11-29. Linux 3.2 was released on 2012-01-04, which is closer to being contemporary with our new minimum glibc.

glibc increases its requirements to Linux 3.2 on 2.24 version.

Right, and they still hold that requirement today, so I cited this as a kernel version that makes sense for current software to continue supporting.

oblique · 2022-08-09T08:36:29Z

I understand. I was wondering if you were willing to increase only the glibc requirement and Linux kernel requirement stays as it is (2.6.32), but increasing it for using newer system apis is a valid point.

rylev · 2022-08-09T15:19:45Z

re: perf - given the difficulty of investigating the performance issues and since the largest of regressions are in doc builds (where we have slightly higher tolerances for regressions), I'm going to mark this as triaged.

@rustbot label: +perf-regression-triaged

https://github.com/pyodide/pyodide/releases/tag/0.21.0

Update to LLVM 15 For preliminary testing. Some LLVM 15 compatibility fixes were applied separately in rust-lang#99512. Release timeline: * LLVM 15 branched on Jul 26. * The final LLVM 15.0.0 release is scheduled for Sep 6. * Current nightly (1.65.0) is scheduled for Nov 3. Changes in this PR (apart from the LLVM update): * Pass `--set llvm.allow-old-toolchain` for many Docker images. LLVM 16 will require GCC >= 7.1, while LLVM 15 still allows older compilers with an option. Specify the option for builders still using GCC 5.4. rust-lang#95026 updated some of the used toolchains, but not all. * Use the `+atomics-32` target feature for thumbv6m. * Explicitly link libatomic when cross-compiling LLVM to 32-bit target. * Explicitly disable zstd support, to avoid libzstd.so dependency. New LLVM patches ([commits](https://github.com/rust-lang/llvm-project/commits/rustc/15.0-2022-08-09)): * [rust-only] Fix ICE with GCC 5.4 (nikic/llvm-project@15be58d) * [rust-only] Fix build with GCC 5.4 (nikic/llvm-project@774edc1) * ~~[rust-only] Fix build with GCC 5.2 (nikic/llvm-project@1a6069a7bb35ace1e40d566035cbf7ed2fa3b1f7)~~ * ~~[rust-only] Fix ICE with GCC 5.2 (nikic/llvm-project@493081f2909206e0ed55af68a4058a76c0ad7a64)~~ * ~~[rust-only] Fix build with GCC 5.2 (nikic/llvm-project@0fc5979d738c3a1f9510fe2d62417f7d2af37817)~~ * [backported] Addition of `+atomics` target feature (llvm/llvm-project@57bdd98). * [backported] Revert compiler-rt change that broke powerpc (llvm/llvm-project@9c68b43) * [awaiting backport] Fix RelLookupTableConverter on gnux32 (nikic/llvm-project@639388a / llvm/llvm-project#57021) Tested images: dist-x86_64-linux, armhf-gnu, arm-android, dist-s390x-linux, dist-x86_64-illumos, dist-x86_64-freebsd, wasm32, dist-x86_64-musl, dist-various-1, dist-riscv64-linux, dist-mips-linux, dist-mipsel-linux, dist-powerpc-linux, dist-aarch64-linux, dist-x86_64-apple, x86_64-msvc-1, x86_64-msvc-2, dist-various-2, dist-arm-linux Tested up to the usual ipv6 error: test-various, i686-gnu, x86_64-gnu-nopt r? `@ghost`

This was previously limited to partial relro, citing issues on RHEL6, but that's no longer a supported platform since rust-lang#95026. We have long been enabling full relro in RHEL7's own Rust builds for ppc64, without trouble, so it should be fine to drop this workaround.

Allow full relro on powerpc64-unknown-linux-gnu This was previously limited to partial relro, citing issues on RHEL6, but that's no longer a supported platform since rust-lang#95026. We have long been enabling full relro in RHEL7's own Rust builds for ppc64, without trouble, so it should be fine to drop this workaround.

Pkgsrc changes: * Add patch to fix vendor/kqueue issue (on 32-bit hosts) * Adjust other patches & line numbers * Version bumps & checksum changes. Upstream changes: Version 1.64.0 (2022-09-22) =========================== Language -------- - [Unions with mutable references or tuples of allowed types are now allowed](rust-lang/rust#97995) - It is now considered valid to deallocate memory pointed to by a shared reference `&T` [if every byte in `T` is inside an `UnsafeCell`](rust-lang/rust#98017) - Unused tuple struct fields are now warned against in an allow-by-default lint, [`unused_tuple_struct_fields`] (rust-lang/rust#95977), similar to the existing warning for unused struct fields. This lint will become warn-by-default in the future. Compiler -------- - [Add Nintendo Switch as tier 3 target] (rust-lang/rust#88991) - Refer to Rust's [platform support page][platform-support-doc] for more information on Rust's tiered platform support. - [Only compile `#[used]` as llvm.compiler.used for ELF targets] (rust-lang/rust#93718) - [Add the `--diagnostic-width` compiler flag to define the terminal width.] (rust-lang/rust#95635) - [Add support for link-flavor `rust-lld` for iOS, tvOS and watchOS] (rust-lang/rust#98771) Libraries --------- - [Remove restrictions on compare-exchange memory ordering.] (rust-lang/rust#98383) - You can now `write!` or `writeln!` into an `OsString`: [Implement `fmt::Write` for `OsString`](rust-lang/rust#97915) - [Make RwLockReadGuard covariant] (rust-lang/rust#96820) - [Implement `FusedIterator` for `std::net::[Into]Incoming`] (rust-lang/rust#97300) - [`impl<T: AsRawFd> AsRawFd for {Arc,Box}<T>`] (rust-lang/rust#97437) - [`ptr::copy` and `ptr::swap` are doing untyped copies] (rust-lang/rust#97712) - [Add cgroupv1 support to `available_parallelism`] (rust-lang/rust#97925) - [Mitigate many incorrect uses of `mem::uninitialized`] (rust-lang/rust#99182) Stabilized APIs --------------- - [`future::IntoFuture`] (https://doc.rust-lang.org/stable/std/future/trait.IntoFuture.html) - [`future::poll_fn`] (https://doc.rust-lang.org/stable/std/future/fn.poll_fn.html) - [`task::ready!`] (https://doc.rust-lang.org/stable/std/task/macro.ready.html) - [`num::NonZero*::checked_mul`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroUsize.html#method.checked_mul) - [`num::NonZero*::checked_pow`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroUsize.html#method.checked_pow) - [`num::NonZero*::saturating_mul`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroUsize.html#method.saturating_mul) - [`num::NonZero*::saturating_pow`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroUsize.html#method.saturating_pow) - [`num::NonZeroI*::abs`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroIsize.html#method.abs) - [`num::NonZeroI*::checked_abs`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroIsize.html#method.checked_abs) - [`num::NonZeroI*::overflowing_abs`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroIsize.html#method.overflowing_abs) - [`num::NonZeroI*::saturating_abs`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroIsize.html#method.saturating_abs) - [`num::NonZeroI*::unsigned_abs`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroIsize.html#method.unsigned_abs) - [`num::NonZeroI*::wrapping_abs`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroIsize.html#method.wrapping_abs) - [`num::NonZeroU*::checked_add`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroUsize.html#method.checked_add) - [`num::NonZeroU*::checked_next_power_of_two`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroUsize.html#method.checked_next_power_of_two) - [`num::NonZeroU*::saturating_add`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroUsize.html#method.saturating_add) - [`os::unix::process::CommandExt::process_group`] (https://doc.rust-lang.org/stable/std/os/unix/process/trait.CommandExt.html#tymethod.process_group) - [`os::windows::fs::FileTypeExt::is_symlink_dir`] (https://doc.rust-lang.org/stable/std/os/windows/fs/trait.FileTypeExt.html#tymethod.is_symlink_dir) - [`os::windows::fs::FileTypeExt::is_symlink_file`] (https://doc.rust-lang.org/stable/std/os/windows/fs/trait.FileTypeExt.html#tymethod.is_symlink_file) These types were previously stable in `std::ffi`, but are now also available in `core` and `alloc`: - [`core::ffi::CStr`] (https://doc.rust-lang.org/stable/core/ffi/struct.CStr.html) - [`core::ffi::FromBytesWithNulError`] (https://doc.rust-lang.org/stable/core/ffi/struct.FromBytesWithNulError.html) - [`alloc::ffi::CString`] (https://doc.rust-lang.org/stable/alloc/ffi/struct.CString.html) - [`alloc::ffi::FromVecWithNulError`] (https://doc.rust-lang.org/stable/alloc/ffi/struct.FromVecWithNulError.html) - [`alloc::ffi::IntoStringError`] (https://doc.rust-lang.org/stable/alloc/ffi/struct.IntoStringError.html) - [`alloc::ffi::NulError`] (https://doc.rust-lang.org/stable/alloc/ffi/struct.NulError.html) These types were previously stable in `std::os::raw`, but are now also available in `core::ffi` and `std::ffi`: - [`ffi::c_char`] (https://doc.rust-lang.org/stable/std/ffi/type.c_char.html) - [`ffi::c_double`] (https://doc.rust-lang.org/stable/std/ffi/type.c_double.html) - [`ffi::c_float`] (https://doc.rust-lang.org/stable/std/ffi/type.c_float.html) - [`ffi::c_int`] (https://doc.rust-lang.org/stable/std/ffi/type.c_int.html) - [`ffi::c_long`] (https://doc.rust-lang.org/stable/std/ffi/type.c_long.html) - [`ffi::c_longlong`] (https://doc.rust-lang.org/stable/std/ffi/type.c_longlong.html) - [`ffi::c_schar`] (https://doc.rust-lang.org/stable/std/ffi/type.c_schar.html) - [`ffi::c_short`] (https://doc.rust-lang.org/stable/std/ffi/type.c_short.html) - [`ffi::c_uchar`] (https://doc.rust-lang.org/stable/std/ffi/type.c_uchar.html) - [`ffi::c_uint`] (https://doc.rust-lang.org/stable/std/ffi/type.c_uint.html) - [`ffi::c_ulong`] (https://doc.rust-lang.org/stable/std/ffi/type.c_ulong.html) - [`ffi::c_ulonglong`] (https://doc.rust-lang.org/stable/std/ffi/type.c_ulonglong.html) - [`ffi::c_ushort`] (https://doc.rust-lang.org/stable/std/ffi/type.c_ushort.html) These APIs are now usable in const contexts: - [`slice::from_raw_parts`] (https://doc.rust-lang.org/stable/core/slice/fn.from_raw_parts.html) Cargo ----- - [Packages can now inherit settings from the workspace so that the settings can be centralized in one place.] (rust-lang/cargo#10859) See [`workspace.package`](https://doc.rust-lang.org/nightly/cargo/reference/workspaces.html#the-workspacepackage-table) and [`workspace.dependencies`](https://doc.rust-lang.org/nightly/cargo/reference/workspaces.html#the-workspacedependencies-table) for more details on how to define these common settings. - [Cargo commands can now accept multiple `--target` flags to build for multiple targets at once] (rust-lang/cargo#10766), and the [`build.target`](https://doc.rust-lang.org/nightly/cargo/reference/config.html#buildtarget) config option may now take an array of multiple targets. - [The `--jobs` argument can now take a negative number to count backwards from the max CPUs.] (rust-lang/cargo#10844) - [`cargo add` will now update `Cargo.lock`.] (rust-lang/cargo#10902) - [Added](rust-lang/cargo#10838) the [`--crate-type`](https://doc.rust-lang.org/nightly/cargo/commands/cargo-rustc.html#option-cargo-rustc---crate-type) flag to `cargo rustc` to override the crate type. - [Significantly improved the performance fetching git dependencies from GitHub when using a hash in the `rev` field.] (rust-lang/cargo#10079) Misc ---- - [The `rust-analyzer` rustup component is now available on the stable channel.] (rust-lang/rust#98640) Compatibility Notes ------------------- - The minimum required versions for all `-linux-gnu` targets are now at least kernel 3.2 and glibc 2.17, for targets that previously supported older versions: [Increase the minimum linux-gnu versions](rust-lang/rust#95026) - [Network primitives are now implemented with the ideal Rust layout, not the C system layout] (rust-lang/rust#78802). This can cause problems when transmuting the types. - [Add assertion that `transmute_copy`'s `U` is not larger than `T`] (rust-lang/rust#98839) - [A soundness bug in `BTreeMap` was fixed] (rust-lang/rust#99413) that allowed data it was borrowing to be dropped before the container. - [The Drop behavior of C-like enums cast to ints has changed] (rust-lang/rust#96862). These are already discouraged by a compiler warning. - [Relate late-bound closure lifetimes to parent fn in NLL] (rust-lang/rust#98835) - [Errors at const-eval time are now in future incompatibility reports] (rust-lang/rust#97743) - On the `thumbv6m-none-eabi` target, some incorrect `asm!` statements were erroneously accepted if they used the high registers (r8 to r14) as an input/output operand. [This is no longer accepted] (rust-lang/rust#99155). - [`impl Trait` was accidentally accepted as the associated type value of return-position `impl Trait`] (rust-lang/rust#97346), without fulfilling all the trait bounds of that associated type, as long as the hidden type satisfies said bounds. This has been fixed. Internal Changes ---------------- These changes do not affect any public interfaces of Rust, but they represent significant improvements to the performance or internals of rustc and related tools. - Windows builds now use profile-guided optimization, providing 10-20% improvements to compiler performance: [Utilize PGO for windows x64 rustc dist builds] (rust-lang/rust#96978) - [Stop keeping metadata in memory before writing it to disk] (rust-lang/rust#96544) - [compiletest: strip debuginfo by default for mode=ui] (rust-lang/rust#98140) - Many improvements to generated code for derives, including performance improvements: - [Don't use match-destructuring for derived ops on structs.] (rust-lang/rust#98446) - [Many small deriving cleanups] (rust-lang/rust#98741) - [More derive output improvements] (rust-lang/rust#98758) - [Clarify deriving code](rust-lang/rust#98915) - [Final derive output improvements] (rust-lang/rust#99046) - [Stop injecting `#[allow(unused_qualifications)]` in generated `derive` implementations](rust-lang/rust#99485) - [Improve `derive(Debug)`](rust-lang/rust#98190) - [Bump to clap 3](rust-lang/rust#98213) - [fully move dropck to mir](rust-lang/rust#98641) - [Optimize `Vec::insert` for the case where `index == len`.] (rust-lang/rust#98755) - [Convert rust-analyzer to an in-tree tool] (rust-lang/rust#99603)

Pkgsrc changes: * This package now contains rust-analyzer, so implicitly conflicts with that pkgsrc package. The same goes for the rust-src package. * Add NetBSD/arm6 port * Add unfinished NetBSD/mipsel port * Revert the use of the internal LLVM, should now build with the new pkgsrc LLVM (15). * Add depndence on compat80 for sparc64 to fix the build * Adapt patches * Add CHECK_INTERPRETER_SKIP for a few (mostly unused) files. (A proper fix may come later.) Upstream changes: Version 1.64.0 (2022-09-22) =========================== Language -------- - [Unions with mutable references or tuples of allowed types are now allowed](rust-lang/rust#97995) - It is now considered valid to deallocate memory pointed to by a shared reference `&T` [if every byte in `T` is inside an `UnsafeCell`](rust-lang/rust#98017) - Unused tuple struct fields are now warned against in an allow-by-default lint, [`unused_tuple_struct_fields`] (rust-lang/rust#95977), similar to the existing warning for unused struct fields. This lint will become warn-by-default in the future. Compiler -------- - [Add Nintendo Switch as tier 3 target] (rust-lang/rust#88991) - Refer to Rust's [platform support page][platform-support-doc] for more information on Rust's tiered platform support. - [Only compile `#[used]` as llvm.compiler.used for ELF targets] (rust-lang/rust#93718) - [Add the `--diagnostic-width` compiler flag to define the terminal width.] (rust-lang/rust#95635) - [Add support for link-flavor `rust-lld` for iOS, tvOS and watchOS] (rust-lang/rust#98771) Libraries --------- - [Remove restrictions on compare-exchange memory ordering.] (rust-lang/rust#98383) - You can now `write!` or `writeln!` into an `OsString`: [Implement `fmt::Write` for `OsString`](rust-lang/rust#97915) - [Make RwLockReadGuard covariant] (rust-lang/rust#96820) - [Implement `FusedIterator` for `std::net::[Into]Incoming`] (rust-lang/rust#97300) - [`impl<T: AsRawFd> AsRawFd for {Arc,Box}<T>`] (rust-lang/rust#97437) - [`ptr::copy` and `ptr::swap` are doing untyped copies] (rust-lang/rust#97712) - [Add cgroupv1 support to `available_parallelism`] (rust-lang/rust#97925) - [Mitigate many incorrect uses of `mem::uninitialized`] (rust-lang/rust#99182) Stabilized APIs --------------- - [`future::IntoFuture`] (https://doc.rust-lang.org/stable/std/future/trait.IntoFuture.html) - [`future::poll_fn`] (https://doc.rust-lang.org/stable/std/future/fn.poll_fn.html) - [`task::ready!`] (https://doc.rust-lang.org/stable/std/task/macro.ready.html) - [`num::NonZero*::checked_mul`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroUsize.html#method.checked_mul) - [`num::NonZero*::checked_pow`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroUsize.html#method.checked_pow) - [`num::NonZero*::saturating_mul`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroUsize.html#method.saturating_mul) - [`num::NonZero*::saturating_pow`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroUsize.html#method.saturating_pow) - [`num::NonZeroI*::abs`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroIsize.html#method.abs) - [`num::NonZeroI*::checked_abs`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroIsize.html#method.checked_abs) - [`num::NonZeroI*::overflowing_abs`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroIsize.html#method.overflowing_abs) - [`num::NonZeroI*::saturating_abs`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroIsize.html#method.saturating_abs) - [`num::NonZeroI*::unsigned_abs`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroIsize.html#method.unsigned_abs) - [`num::NonZeroI*::wrapping_abs`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroIsize.html#method.wrapping_abs) - [`num::NonZeroU*::checked_add`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroUsize.html#method.checked_add) - [`num::NonZeroU*::checked_next_power_of_two`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroUsize.html#method.checked_next_power_of_two) - [`num::NonZeroU*::saturating_add`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroUsize.html#method.saturating_add) - [`os::unix::process::CommandExt::process_group`] (https://doc.rust-lang.org/stable/std/os/unix/process/trait.CommandExt.html#tymethod.process_group) - [`os::windows::fs::FileTypeExt::is_symlink_dir`] (https://doc.rust-lang.org/stable/std/os/windows/fs/trait.FileTypeExt.html#tymethod.is_symlink_dir) - [`os::windows::fs::FileTypeExt::is_symlink_file`] (https://doc.rust-lang.org/stable/std/os/windows/fs/trait.FileTypeExt.html#tymethod.is_symlink_file) These types were previously stable in `std::ffi`, but are now also available in `core` and `alloc`: - [`core::ffi::CStr`] (https://doc.rust-lang.org/stable/core/ffi/struct.CStr.html) - [`core::ffi::FromBytesWithNulError`] (https://doc.rust-lang.org/stable/core/ffi/struct.FromBytesWithNulError.html) - [`alloc::ffi::CString`] (https://doc.rust-lang.org/stable/alloc/ffi/struct.CString.html) - [`alloc::ffi::FromVecWithNulError`] (https://doc.rust-lang.org/stable/alloc/ffi/struct.FromVecWithNulError.html) - [`alloc::ffi::IntoStringError`] (https://doc.rust-lang.org/stable/alloc/ffi/struct.IntoStringError.html) - [`alloc::ffi::NulError`] (https://doc.rust-lang.org/stable/alloc/ffi/struct.NulError.html) These types were previously stable in `std::os::raw`, but are now also available in `core::ffi` and `std::ffi`: - [`ffi::c_char`] (https://doc.rust-lang.org/stable/std/ffi/type.c_char.html) - [`ffi::c_double`] (https://doc.rust-lang.org/stable/std/ffi/type.c_double.html) - [`ffi::c_float`] (https://doc.rust-lang.org/stable/std/ffi/type.c_float.html) - [`ffi::c_int`] (https://doc.rust-lang.org/stable/std/ffi/type.c_int.html) - [`ffi::c_long`] (https://doc.rust-lang.org/stable/std/ffi/type.c_long.html) - [`ffi::c_longlong`] (https://doc.rust-lang.org/stable/std/ffi/type.c_longlong.html) - [`ffi::c_schar`] (https://doc.rust-lang.org/stable/std/ffi/type.c_schar.html) - [`ffi::c_short`] (https://doc.rust-lang.org/stable/std/ffi/type.c_short.html) - [`ffi::c_uchar`] (https://doc.rust-lang.org/stable/std/ffi/type.c_uchar.html) - [`ffi::c_uint`] (https://doc.rust-lang.org/stable/std/ffi/type.c_uint.html) - [`ffi::c_ulong`] (https://doc.rust-lang.org/stable/std/ffi/type.c_ulong.html) - [`ffi::c_ulonglong`] (https://doc.rust-lang.org/stable/std/ffi/type.c_ulonglong.html) - [`ffi::c_ushort`] (https://doc.rust-lang.org/stable/std/ffi/type.c_ushort.html) These APIs are now usable in const contexts: - [`slice::from_raw_parts`] (https://doc.rust-lang.org/stable/core/slice/fn.from_raw_parts.html) Cargo ----- - [Packages can now inherit settings from the workspace so that the settings can be centralized in one place.] (rust-lang/cargo#10859) See [`workspace.package`](https://doc.rust-lang.org/nightly/cargo/reference/workspaces.html#the-workspacepackage-table) and [`workspace.dependencies`](https://doc.rust-lang.org/nightly/cargo/reference/workspaces.html#the-workspacedependencies-table) for more details on how to define these common settings. - [Cargo commands can now accept multiple `--target` flags to build for multiple targets at once] (rust-lang/cargo#10766), and the [`build.target`](https://doc.rust-lang.org/nightly/cargo/reference/config.html#buildtarget) config option may now take an array of multiple targets. - [The `--jobs` argument can now take a negative number to count backwards from the max CPUs.] (rust-lang/cargo#10844) - [`cargo add` will now update `Cargo.lock`.] (rust-lang/cargo#10902) - [Added](rust-lang/cargo#10838) the [`--crate-type`](https://doc.rust-lang.org/nightly/cargo/commands/cargo-rustc.html#option-cargo-rustc---crate-type) flag to `cargo rustc` to override the crate type. - [Significantly improved the performance fetching git dependencies from GitHub when using a hash in the `rev` field.] (rust-lang/cargo#10079) Misc ---- - [The `rust-analyzer` rustup component is now available on the stable channel.] (rust-lang/rust#98640) Compatibility Notes ------------------- - The minimum required versions for all `-linux-gnu` targets are now at least kernel 3.2 and glibc 2.17, for targets that previously supported older versions: [Increase the minimum linux-gnu versions](rust-lang/rust#95026) - [Network primitives are now implemented with the ideal Rust layout, not the C system layout] (rust-lang/rust#78802). This can cause problems when transmuting the types. - [Add assertion that `transmute_copy`'s `U` is not larger than `T`] (rust-lang/rust#98839) - [A soundness bug in `BTreeMap` was fixed] (rust-lang/rust#99413) that allowed data it was borrowing to be dropped before the container. - [The Drop behavior of C-like enums cast to ints has changed] (rust-lang/rust#96862). These are already discouraged by a compiler warning. - [Relate late-bound closure lifetimes to parent fn in NLL] (rust-lang/rust#98835) - [Errors at const-eval time are now in future incompatibility reports] (rust-lang/rust#97743) - On the `thumbv6m-none-eabi` target, some incorrect `asm!` statements were erroneously accepted if they used the high registers (r8 to r14) as an input/output operand. [This is no longer accepted] (rust-lang/rust#99155). - [`impl Trait` was accidentally accepted as the associated type value of return-position `impl Trait`] (rust-lang/rust#97346), without fulfilling all the trait bounds of that associated type, as long as the hidden type satisfies said bounds. This has been fixed. Internal Changes ---------------- These changes do not affect any public interfaces of Rust, but they represent significant improvements to the performance or internals of rustc and related tools. - Windows builds now use profile-guided optimization, providing 10-20% improvements to compiler performance: [Utilize PGO for windows x64 rustc dist builds] (rust-lang/rust#96978) - [Stop keeping metadata in memory before writing it to disk] (rust-lang/rust#96544) - [compiletest: strip debuginfo by default for mode=ui] (rust-lang/rust#98140) - Many improvements to generated code for derives, including performance improvements: - [Don't use match-destructuring for derived ops on structs.] (rust-lang/rust#98446) - [Many small deriving cleanups] (rust-lang/rust#98741) - [More derive output improvements] (rust-lang/rust#98758) - [Clarify deriving code](rust-lang/rust#98915) - [Final derive output improvements] (rust-lang/rust#99046) - [Stop injecting `#[allow(unused_qualifications)]` in generated `derive` implementations](rust-lang/rust#99485) - [Improve `derive(Debug)`](rust-lang/rust#98190) - [Bump to clap 3](rust-lang/rust#98213) - [fully move dropck to mir](rust-lang/rust#98641) - [Optimize `Vec::insert` for the case where `index == len`.] (rust-lang/rust#98755) - [Convert rust-analyzer to an in-tree tool] (rust-lang/rust#99603)

Revert "Download the GCC sources insecurely" This reverts commit 3da037f. This workaround was added after TLS problems with Debian 6 were noted in <rust-lang#86586 (comment)>, but we should be well past that since rust-lang#95026, where our oldest images are now based on CentOS 7.

cuviper added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-release Relevant to the release subteam, which will review and decide on the PR/issue. needs-fcp This change is insta-stable, so needs a completed FCP to proceed. labels Mar 16, 2022

rust-highfive assigned pietroalbini Mar 16, 2022

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 16, 2022

cuviper commented Mar 16, 2022

View reviewed changes

nikic reviewed Mar 16, 2022

View reviewed changes

src/ci/docker/host-x86_64/dist-i686-linux/Dockerfile Outdated Show resolved Hide resolved

cuviper mentioned this pull request Mar 16, 2022

use CLOCK_BOOTTIME in Instant::now #88714

Closed

messense mentioned this pull request Mar 17, 2022

Drop manylinux2010 support PyO3/maturin#857

Closed

2 tasks

rust-highfive assigned Mark-Simulacrum and unassigned pietroalbini Mar 21, 2022

rust-highfive assigned pietroalbini and unassigned Mark-Simulacrum Mar 21, 2022

pietroalbini approved these changes Mar 22, 2022

View reviewed changes

src/ci/docker/host-x86_64/dist-armv7-linux/Dockerfile Show resolved Hide resolved

rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Mar 24, 2022

klensy mentioned this pull request Aug 7, 2022

triage for this week. rust-lang/rustc-perf#1385

Merged

rustbot added the perf-regression-triaged The performance regression has been triaged. label Aug 9, 2022

messense referenced this pull request in pydantic/pydantic-core Aug 11, 2022

update pyodide to 0.21.0 release version (#226)

ae3b707

https://github.com/pyodide/pyodide/releases/tag/0.21.0

apiraino removed the to-announce Announce this issue on triage meeting label Aug 25, 2022

glandium mentioned this pull request Sep 7, 2022

Using a shebang-less script as a linker doesn't work anymore on Linux #101511

Open

cuviper mentioned this pull request Sep 21, 2022

Allow full relro on powerpc64-unknown-linux-gnu #102112

Merged

wesleywiser mentioned this pull request Oct 7, 2022

Upgrade mingw-w64 on CI #100178

Merged

cuviper deleted the bump-linux-min branch October 15, 2022 00:15

jonhoo mentioned this pull request Oct 19, 2022

Update CI to use Android NDK r25b #102332

Merged

alex-pinkus mentioned this pull request Oct 28, 2022

Android NDK r25b changes will break developers using r22b or older #103673

Closed

cuviper mentioned this pull request Apr 25, 2023

Revert "Download the GCC sources insecurely" #110784

Merged

Kobzol mentioned this pull request Jul 15, 2023

CI: build CMake 3.20 to support LLVM 17 #113714

Merged

cuviper mentioned this pull request Aug 23, 2023

Announcing Rust 1.72.0 rust-lang/blog.rust-lang.org#1129

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Increase the minimum linux-gnu versions #95026

Increase the minimum linux-gnu versions #95026

cuviper commented Mar 16, 2022

rust-highfive commented Mar 16, 2022

cuviper Mar 16, 2022

workingjubilee Jul 22, 2022

lancethepants Sep 23, 2022

jonhoo commented Mar 17, 2022 •

edited

Loading

cuviper commented Mar 21, 2022

jonhoo commented Mar 21, 2022

cuviper commented Mar 21, 2022

pietroalbini commented Mar 21, 2022

pietroalbini left a comment

pietroalbini commented Mar 23, 2022

cuviper commented Mar 23, 2022

jonhoo commented Mar 24, 2022

cuviper commented Mar 24, 2022

pietroalbini commented Mar 24, 2022

rfcbot commented Mar 24, 2022 •

edited

Loading

estebank commented Mar 24, 2022

Mark-Simulacrum commented Mar 25, 2022

oblique commented Aug 8, 2022 •

edited

Loading

slanterns commented Aug 8, 2022 •

edited

Loading

cuviper commented Aug 8, 2022 •

edited

Loading

oblique commented Aug 9, 2022 •

edited

Loading

rylev commented Aug 9, 2022

Increase the minimum linux-gnu versions #95026

Increase the minimum linux-gnu versions #95026

Conversation

cuviper commented Mar 16, 2022

rust-highfive commented Mar 16, 2022

cuviper Mar 16, 2022

Choose a reason for hiding this comment

workingjubilee Jul 22, 2022

Choose a reason for hiding this comment

lancethepants Sep 23, 2022

Choose a reason for hiding this comment

jonhoo commented Mar 17, 2022 • edited Loading

cuviper commented Mar 21, 2022

jonhoo commented Mar 21, 2022

cuviper commented Mar 21, 2022

pietroalbini commented Mar 21, 2022

pietroalbini left a comment

Choose a reason for hiding this comment

pietroalbini commented Mar 23, 2022

cuviper commented Mar 23, 2022

jonhoo commented Mar 24, 2022

cuviper commented Mar 24, 2022

pietroalbini commented Mar 24, 2022

rfcbot commented Mar 24, 2022 • edited Loading

estebank commented Mar 24, 2022

Mark-Simulacrum commented Mar 25, 2022

oblique commented Aug 8, 2022 • edited Loading

slanterns commented Aug 8, 2022 • edited Loading

cuviper commented Aug 8, 2022 • edited Loading

oblique commented Aug 9, 2022 • edited Loading

rylev commented Aug 9, 2022

jonhoo commented Mar 17, 2022 •

edited

Loading

rfcbot commented Mar 24, 2022 •

edited

Loading

oblique commented Aug 8, 2022 •

edited

Loading

slanterns commented Aug 8, 2022 •

edited

Loading

cuviper commented Aug 8, 2022 •

edited

Loading

oblique commented Aug 9, 2022 •

edited

Loading