Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Increase the minimum linux-gnu versions #95026

Merged
merged 5 commits into from
Aug 5, 2022
Merged

Conversation

cuviper
Copy link
Member

@cuviper cuviper commented Mar 16, 2022

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.

@cuviper 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
Copy link
Collaborator

r? @pietroalbini

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

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 16, 2022
@@ -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]
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@jonhoo
Copy link
Contributor

jonhoo commented Mar 17, 2022

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
Copy link
Member Author

cuviper commented Mar 21, 2022

@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
Copy link
Contributor

jonhoo commented Mar 21, 2022

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
Copy link
Member Author

cuviper commented Mar 21, 2022

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
Copy link
Member

I can review it tomorrow, sorry for the delay 🙂

r? @pietroalbini

Copy link
Member

@pietroalbini pietroalbini left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@pietroalbini
Copy link
Member

r=me whenever this is ready to merge

@cuviper
Copy link
Member Author

cuviper commented Mar 23, 2022

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

@jonhoo
Copy link
Contributor

jonhoo commented Mar 24, 2022

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
Copy link
Member Author

cuviper commented Mar 24, 2022

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
Copy link
Member

@rfcbot fcp merge

@rfcbot
Copy link

rfcbot commented Mar 24, 2022

Team member @pietroalbini has proposed to merge this. The next step is review by the rest of the tagged team members:

Concerns:

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@rfcbot 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
@estebank
Copy link
Contributor

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
Copy link
Member

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
Copy link

oblique commented Aug 8, 2022

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
Copy link
Contributor

slanterns commented Aug 8, 2022

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
Copy link
Member Author

cuviper commented Aug 8, 2022

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
Copy link

oblique commented Aug 9, 2022

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
Copy link
Member

rylev commented Aug 9, 2022

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

@rustbot rustbot added the perf-regression-triaged The performance regression has been triaged. label Aug 9, 2022
bors added a commit to rust-lang-ci/rust that referenced this pull request Aug 12, 2022
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`
@rfcbot rfcbot added finished-final-comment-period The final comment period is finished for this PR / Issue. to-announce Announce this issue on triage meeting and removed final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. labels Aug 12, 2022
@apiraino apiraino removed the to-announce Announce this issue on triage meeting label Aug 25, 2022
cuviper added a commit to cuviper/rust that referenced this pull request Sep 21, 2022
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.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Sep 22, 2022
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.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Sep 23, 2022
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.
wip-sync pushed a commit to NetBSD/pkgsrc-wip that referenced this pull request Oct 11, 2022
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)
@cuviper cuviper deleted the bump-linux-min branch October 15, 2022 00:15
netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this pull request Nov 16, 2022
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)
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 26, 2023
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this PR / Issue. merged-by-bors This PR was explicitly merged by bors. needs-fcp This change is insta-stable, so needs a completed FCP to proceed. perf-regression Performance regression. perf-regression-triaged The performance regression has been triaged. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-infra Relevant to the infrastructure 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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.