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

Remove most version detection and conditionals for older versions of Rust #2845

Open
wants to merge 14 commits into
base: main
Choose a base branch
from

Conversation

joshtriplett
Copy link
Member

@joshtriplett joshtriplett commented Jul 12, 2022

Per library team decision, drop most of the conditionals, simplifying the code
substantially. Update the README accordingly.

I left the conditional for 1.62, since that just shipped, and the conditional for 1.51 pending ratification of a libc MSRV policy.

  • Require rust >= 1.15 and drop libc_priv_mod_use conditional
  • Require rust >= 1.19 and drop libc_union conditional
  • Require rust >= 1.24 and drop libc_const_size_of conditional
  • Require rust >= 1.25 and drop libc_align conditional
  • Require rust >= 1.26 and drop libc_int128 conditional
  • Require rust >= 1.30 and drop libc_core_cvoid conditional
  • Require rust >= 1.33 and drop libc_packedN conditional
  • Require rust >= 1.33 and drop libc_cfg_target_vendor conditional
  • Require rust >= 1.37 and drop libc_underscore_const_names conditional
  • Require rust >= 1.40 and drop libc_non_exhaustive conditional
  • Remove array size hacks for Rust < 1.47
  • README.md: Update version-dependent features

Deferred while discussing libc MSRV policy:

  • Require rust >= 1.51 and drop libc_ptr_addr_of conditional
  • Require rust >= 1.62 and drop libc_const_extern_fn conditional

@rust-highfive
Copy link

Some changes occurred in solarish module

cc @jclulow,@pfmooney

Some changes occurred in OpenBSD module

cc @semarie

@rust-highfive
Copy link

r? @Amanieu

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

@Amanieu
Copy link
Member

Amanieu commented Jul 13, 2022

cc @JohnTitor

@@ -1,5 +1,7 @@
//! SGX C types definition

use c_void;
Copy link
Member

Choose a reason for hiding this comment

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

Should this be pub use instead?

Copy link
Member

Choose a reason for hiding this comment

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

Ah nevermind, I see there's one in the crate root.

@Kixunil
Copy link

Kixunil commented Jul 15, 2022

I'm very disappointed hearing this. This is a significant jump in MSRV which not all parties can deploy quickly. As an example, Debian stable is now at 1.48 which is below 1.56. libc is one of the most important crates out there, pretty much required for FFI. Doing this pretty much kills Rust FFI for anyone who's not in the "go fast and break things" camp - pretty much all security-critical software.

@Amanieu
Copy link
Member

Amanieu commented Jul 15, 2022

I don't think supporting 1.48 costs us too much, however the current MSRV for libc is 1.13 which puts a huge burden on maintenance since many useful language features are missing (e.g. traits impls for arrays of more than 32 elements).

@Noah-Kennedy
Copy link

I'm going to second @Kixunil here. As is, this will force a lot of ecosystem crates that make MSRV guarantees to bump their minimum versions. This crate should probably move a bit cautiously here because of how foundational it is to the ecosystem.

@ibraheemdev
Copy link
Member

It looks like 1.40 could be supported while still getting most of the benefit from this PR.

@Kixunil
Copy link

Kixunil commented Jul 15, 2022

@Amanieu nothing wrong with bumping super-ancient 1.13. 1.40 would be perfect for me, but 1.48 is fine too.

@Amanieu
Copy link
Member

Amanieu commented Jul 15, 2022

The problem here is that we don't have clear guidelines on when we can stop supporting a version. If we decide to set the MSRV to 1.48 (for example), at what point can we stop supporting this version?

@Noah-Kennedy
Copy link

@Amanieu I think it's probably time for libc to establish an MSRV policy from what I'm seeing here.

@Kixunil
Copy link

Kixunil commented Jul 15, 2022

@Amanieu my preference would be "what popular Linux distros (insert list) support in repositories" I specifically care about Debian stable but there are other popular distros too.

@pfmooney
Copy link
Contributor

I think it's probably time for libc to establish an MSRV policy from what I'm seeing here.

Stepping back to consider other flag day conditions that libc might encounter could be worthwhile

@Noah-Kennedy
Copy link

@Amanieu my preference would be "what popular Linux distros (insert list) support in repositories" I specifically care about Debian stable but there are other popular distros too.

So, I'm actually not so sure on this, as relying on debian stable will cause a huge maintenance burden over time as debian lags further and further behind due to the infrequent release cycle. I think some sort of time-based policy (e.g, last year's worth of releases) may be the best approach here as it keeps some stability but also doesn't lock in MSRV behind what debian is doing.

@Kixunil
Copy link

Kixunil commented Jul 15, 2022

@Noah-Kennedy Debian tries to target 2 year release cycle. They would rather put off the release if there are unresolved problems but I don't think that's too bad. A few months shouldn't be a huge problem, I guess. If it gets unreasonably prolonged I wouldn't mind MSRV bump. So perhaps "whatever popular distros support unless they unreasonably prolong releases; minimum 2 years" :)

@Noah-Kennedy
Copy link

Hmm, two years sounds like a good timeline actually for MSRV breaks in libc.

@Noah-Kennedy
Copy link

Honestly, libc should be treated as something that doesn't do anything even mildly breaking outside of fixed release dates every few years. It is one of the core foundational elements of the rust ecosystem, so a change in MSRV here requires everyone to bump MSRV, which is a pretty big deal.

This needs to be done with caution, not everyone can update to the newest compiler for entirely valid reasons, and those who have this issue shouldn't be forced to rely on an old version of the rust ecosystem built on an older version of libc.

@joshtriplett
Copy link
Member Author

joshtriplett commented Jul 17, 2022

As an example, Debian stable is now at 1.48 which is below 1.56.

And Debian stable's packaged version of the libc crate is 0.2.80, which works on Debian stable's packaged version of rustc. Debian's rustc is for use by Debian packages. Compatibility with the rustc shipped by Debian stable is not a goal crates on crates.io should be striving to meet.

I don't think supporting 1.48 costs us too much

Not at the moment, but the implied MSRV policy of "support whatever's in Debian stable" absolutely would long-term.

As is, this will force a lot of ecosystem crates that make MSRV guarantees to bump their minimum versions.

I sincerely hope so. MSRV is a prisoner's dilemma: crates keep MSRV low because some other crate asks them to keep MSRV low because some other crate asks them to keep MSRV low, most of which can't actually point to a project that actually needs that MSRV for some reason. As a result, there are far more crates affected than there are users who actually have any desire to use such a Rust version.

We discussed possible MSRV policies in the library team meeting. The primary debate was between "support stable and stable-minus-one to allow time for upgrades" and "support a few extra versions back because we're libc", but the debate was between N-1 and (say) N-3 or N-4, not "1-2 years".

(To be clear, nobody proposed that we upgrade gratuitously, only that we upgrade when there's a rustc feature we need.)

We ended that meeting without setting a concrete MSRV policy, largely because we figured we'd start by making this change and go from there. But it looks like we may need to set a concrete MSRV policy after all.

This needs to be done with caution, not everyone can update to the newest compiler for entirely valid reasons, and those who have this issue shouldn't be forced to rely on an old version of the rust ecosystem built on an older version of libc.

Yes, they absolutely should. If you run old rustc, run a matching set of old crates, such as those packaged alongside your rustc. Whoever packaged your rustc and your crates will then have validated that your rustc builds your crates.

I am entirely in support of distributions that package self-contained versions of rustc and crates and use those to make self-contained packages of Rust software. I run Debian myself, and I appreciate that they package software written in Rust and many other languages. That doesn't mean that crates in the ecosystem need to support running the latest version of a crate with a years-old version of rustc from Debian stable.

@joshtriplett
Copy link
Member Author

The concrete MSRV policy I would propose:

  • Support the last three stable versions of rustc (stable and the prior two versions).
  • Only upgrade if there's a feature we actually need.

@rtzoeller
Copy link
Contributor

@joshtriplett I think the "Only upgrade if there's a feature we actually need" statement still leaves some ambiguity around what "need" really means, but perhaps that's intentional. I.e. if the lack of a language feature can be worked around, how expensive can that workaround be before the feature is "needed"?

Orthogonally, I'd request that a release be cut immediately prior to this PR being merged, and the same for any future MSRV bumps. IMHO a notice period before the MSRV is bumped would also be helpful - it'd give anyone who wants changes made to version of libc supporting a soon-to-be-dropped version of Rust a window to get them submitted.

@udoprog
Copy link

udoprog commented Jul 17, 2022

The way @joshtriplett describes the downstream use of MSRV largely echoes with me. Anyone has the ability to vendor their dependencies.

What MSRV policies across the ecosystem gives is a sliding window of released crates which makes vendoring a specific rustc release possible (in say the debian repository). But the minimal requirement is that the ecosystem can at some point be frozen on a reasonably stable set of package versions which allows everything being vendored to build. The wider the MSRV of all packages the better since it increases the probability that this global set of versions can be found (else package maintainers have to go through the hassle of figuring out how to have more than one version of the same package in parallel).

Another potentially large concern in my mind is having a bug patching policy which is friendly to downstreams, such as the one outlined in Tokio. It serves to guide maintainers which minor version of a package to prefer to pick in the hopes that critical issues in the future will be patched and tested against a compatible version of the vendored package. A similar policy for foundational crates such as libc might be worth considering.

So far this is all a bit speculative and I'd love to hear more concrete user stories around this. Especially ones where people have been hurt by the lack of a stricter MSRV for some package with no reasonable remediation at hand.

@Darksonn
Copy link

The proposal of last three stable versions would force Tokio to break its MSRV policy, which is that the MSRV must always be at least six months old. (i.e. our policy is N-4)

The Tokio project controls most of the dependencies of Tokio, so until now, this is a policy that we've been able to uphold without issues. I see now that it was a mistake not to consult the libc maintainers before picking this policy. The reason this didn't happen is that libc is such a fundamental crate that I never imagined that libc would pick something weaker.

I would really appreciate it if the policy was N-4 rather than N-2.


As for debian stable, Tokio doesn't track debian stable, but there are every so often people who complain that we don't. People definitely try to use the cargo from the debian stable repos to compile their projects.

I'd love to hear more concrete user stories around this. Especially ones where people have been hurt by the lack of a stricter MSRV for some package with no reasonable remediation at hand.

I do have a user story about this, though it was a case where the MSRV being too new was merely annoying and wasted my time, rather than a situation with no reasonable remediation.

The story is that I have a custom program I run in a cronscript on a VPS to manage my RSS feeds. Initially I wanted to compile it on my local machine and scp the binary to the server, but the binary didn't work on the server due to a version mismatch in the dynamic libraries (I think it was glibc in this case, but I've run into the same issue with an sql library in the past). I then tried to compile it on the server, but it didn't compile because Tokio's MSRV was too new. Thus, I was forced to install rustup to compile the application. This is annoying because I wanted Rust to be available to all users on the VPS. Looking at the VPS, it appears that I've somehow managed to install it globally, although it appears that I did it wrong, because upgrading rustc failed when I just tried it.

@Kixunil
Copy link

Kixunil commented Jul 18, 2022

@joshtriplett perhaps it'll help to describe my use case. I write security-critical software that has to run on a well-secured system which should also be reliable. As such I chose Debian stable as the base system. In principle I have only a single reason against picking whichever version of Rust: it's hard to ensure the installed version is not backdoored unless it came from distribution repository.

The alternative for me would be to make effort to make Rustup verify Rust signatures when installing (last time I checked it didn't do that) and then get legit Rustup. Or write my own alternative installer.

Packaged crates don't fit my use case well mainly because there's no way to tell cargo to pull crates from system repository unless they don't exist there. Note that I'm not forgetting crate security. After reviewing a crate I can just rely on its hash being in Cargo.lock, yes, I always use --locked.

So far sticking with MSRV was the solution for me but since it's getting harder over time, I may attempt to do something different.

@taiki-e
Copy link
Member

taiki-e commented Jul 21, 2022

(The MSRV policy for libc is currently being discussed in rust-lang/libs-team#72)

@bors
Copy link
Contributor

bors commented Aug 4, 2022

⌛ Testing commit 71ff679 with merge b5e9d00...

bors added a commit that referenced this pull request Aug 4, 2022
Remove most version detection and conditionals for older versions of Rust

Per library team decision, drop most of the conditionals, simplifying the code
substantially. Update the README accordingly.

I left the conditional for 1.62, since that *just* shipped, and the conditional for 1.51 pending ratification of a libc MSRV policy.

- Require rust >= 1.15 and drop libc_priv_mod_use conditional
- Require rust >= 1.19 and drop libc_union conditional
- Require rust >= 1.24 and drop libc_const_size_of conditional
- Require rust >= 1.25 and drop libc_align conditional
- Require rust >= 1.26 and drop libc_int128 conditional
- Require rust >= 1.30 and drop libc_core_cvoid conditional
- Require rust >= 1.33 and drop libc_packedN conditional
- Require rust >= 1.33 and drop libc_cfg_target_vendor conditional
- Require rust >= 1.37 and drop libc_underscore_const_names conditional
- Require rust >= 1.40 and drop libc_non_exhaustive conditional
- Remove array size hacks for Rust < 1.47
- README.md: Update version-dependent features

Deferred while discussing libc MSRV policy:

- Require rust >= 1.51 and drop libc_ptr_addr_of conditional
- Require rust >= 1.62 and drop libc_const_extern_fn conditional
@bors
Copy link
Contributor

bors commented Aug 4, 2022

💔 Test failed - checks-actions

@joshtriplett
Copy link
Member Author

(Not sure why the aarch64 build for Windows is failing. Will investigate.)

bors bot added a commit to nix-rust/nix that referenced this pull request Aug 4, 2022
1779: Upgrade libc to 0.2.127 r=asomers a=rtzoeller

This is the last version of libc which will support Rust 1.46, per rust-lang/libc#2845.

I think we should ship nix 0.25.0 against this version of libc (at some point, not necessarily now), as it will allow us to maintain an MSRV of 1.46, and subsequently upgrade to a later libc immediately after releasing 0.25.0.

Co-authored-by: Ryan Zoeller <rtzoeller@rtzoeller.com>
@Amanieu
Copy link
Member

Amanieu commented Aug 4, 2022

   --- stderr
  error: expected identifier, found `_`
     --> ../src/fixed_width_ints.rs:64:23
      |
  64  |                   const _: [(); $a] = [(); $b];
      |                         ^
      | 
     ::: ../src/lib.rs
      |
  70  | / cfg_if! {
  71  | |     if #[cfg(windows)] {
  72  | |         mod fixed_width_ints;
  73  | |         pub use fixed_width_ints::*;
  ...   |
  133 | |     }
  134 | | }
      | |_- in this macro invocation
      |
      = note: `_` is a wildcard pattern, not an identifier

1.19.0,
1.24.0,
1.25.0,
1.30.0,
Copy link
Member

Choose a reason for hiding this comment

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

Shouldn't there still be CI for the remaining MSRV? And maybe also the further version steps that are still detected in the build script -- just 1.51?

Copy link
Member Author

Choose a reason for hiding this comment

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

@cuviper I don't think we need the latter, but yes, I'll add 1.47 there.

Copy link
Member

Choose a reason for hiding this comment

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

Pardon me for unresolving, but AFAICT you haven't added 1.47 to CI yet.

@joshtriplett
Copy link
Member Author

   --- stderr
  error: expected identifier, found `_`
     --> ../src/fixed_width_ints.rs:64:23
      |
  64  |                   const _: [(); $a] = [(); $b];

This should work on Rust 1.37 and newer, and that log seems to be saying it has a newer version of Rust than that (which it should). Trying to find why it has a version that doesn't support that.

@joshtriplett
Copy link
Member Author

Ah, I think I figured it out. Despite looking like a Rust error, this is being parsed by garando_syntax, which doesn't understand this syntax.

@Thomasdezeeuw
Copy link
Contributor

I'm a little late to this issue, but if this goes through it means that a number of crates will have to fork libc to maintain their compatibility promises. This includes at least Tokio, Mio and Socket2 (which is host under rust-lang no less). This pr will just split the community, not bring it together.

I think this is a mistake to do in the v0.2.x version.

@joshtriplett
Copy link
Member Author

@Thomasdezeeuw This particular change is allowing for Rust versions more than a year old. What is socket2's compatibility story, and what do its users actually need? (Ideally, responses should probably go in the other discussion issue.)

@Thomasdezeeuw
Copy link
Contributor

@Thomasdezeeuw This particular change is allowing for Rust versions more than a year old. What is socket2's compatibility story, and what do its users actually need? (Ideally, responses should probably go in the other discussion issue.)

The MSRV for Socket2 is 1.46 (https://github.com/rust-lang/socket2#minimum-supported-rust-version-msrv) this pr increases it to 1.47 (according to the change in the README). We are in the process of increasing it to 1.63, but that will be done in v0.5 and might take a while.

Also I see a lot of Rust versions were removed from the CI, but the MSRV wasn't added.

@joshtriplett
Copy link
Member Author

joshtriplett commented Aug 10, 2022 via email

@bors
Copy link
Contributor

bors commented Sep 14, 2022

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

@asomers
Copy link
Contributor

asomers commented Sep 27, 2022

Is there any way to help push this through? I'd really like to finish it, because it's blocking #2813 .

@asomers
Copy link
Contributor

asomers commented Nov 21, 2022

@joshtriplett is there any way to move this PR forward without waiting for ctest2 ?

@ChrisDenton
Copy link
Member

ChrisDenton commented Feb 1, 2023

Looking at the list, I think the MSRV could be bumped to 1.33 before needing to patch ctest2?

@bors
Copy link
Contributor

bors commented Nov 1, 2023

🔒 Merge conflict

This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again.

How do I rebase?

Assuming self is your fork and upstream is this repository, you can resolve the conflict following these steps:

  1. git checkout version-handling (switch to your branch)
  2. git fetch upstream master (retrieve the latest master)
  3. git rebase upstream/master -p (rebase on top of it)
  4. Follow the on-screen instruction to resolve conflicts (check git status if you got lost).
  5. git push self version-handling --force-with-lease (update this PR)

You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial.

Please avoid the "Resolve conflicts" button on GitHub. It uses git merge instead of git rebase which makes the PR commit history more difficult to read.

Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Cargo.lock conflict is handled during merge and rebase. This is normal, and you should still perform step 5 to update this PR.

Error message
Auto-merging src/windows/mod.rs
Removing src/windows/gnu/align.rs
Auto-merging src/wasi.rs
Auto-merging src/vxworks/mod.rs
Auto-merging src/unix/solarish/x86_64.rs
Auto-merging src/unix/solarish/mod.rs
Removing src/unix/no_align.rs
Removing src/unix/newlib/no_align.rs
Auto-merging src/unix/newlib/mod.rs
Removing src/unix/newlib/align.rs
Auto-merging src/unix/mod.rs
Auto-merging src/unix/linux_like/linux/uclibc/x86_64/mod.rs
Removing src/unix/linux_like/linux/uclibc/no_align.rs
Removing src/unix/linux_like/linux/uclibc/mips/mips64/no_align.rs
Auto-merging src/unix/linux_like/linux/uclibc/mips/mips64/mod.rs
Removing src/unix/linux_like/linux/uclibc/mips/mips64/align.rs
Removing src/unix/linux_like/linux/uclibc/mips/mips32/no_align.rs
Auto-merging src/unix/linux_like/linux/uclibc/mips/mips32/mod.rs
Removing src/unix/linux_like/linux/uclibc/mips/mips32/align.rs
Removing src/unix/linux_like/linux/uclibc/arm/no_align.rs
Auto-merging src/unix/linux_like/linux/uclibc/arm/mod.rs
CONFLICT (content): Merge conflict in src/unix/linux_like/linux/uclibc/arm/mod.rs
Removing src/unix/linux_like/linux/uclibc/arm/align.rs
Removing src/unix/linux_like/linux/non_exhaustive.rs
CONFLICT (modify/delete): src/unix/linux_like/linux/no_align.rs deleted in heads/homu-tmp and modified in HEAD. Version HEAD of src/unix/linux_like/linux/no_align.rs left in tree.
Auto-merging src/unix/linux_like/linux/musl/mod.rs
Auto-merging src/unix/linux_like/linux/musl/b64/x86_64/mod.rs
Removing src/unix/linux_like/linux/musl/b64/x86_64/align.rs
Auto-merging src/unix/linux_like/linux/musl/b64/riscv64/mod.rs
Removing src/unix/linux_like/linux/musl/b64/riscv64/align.rs
Auto-merging src/unix/linux_like/linux/musl/b64/aarch64/mod.rs
Removing src/unix/linux_like/linux/musl/b64/aarch64/int128.rs
Removing src/unix/linux_like/linux/musl/b64/aarch64/align.rs
Auto-merging src/unix/linux_like/linux/musl/b32/x86/mod.rs
Removing src/unix/linux_like/linux/musl/b32/x86/align.rs
Auto-merging src/unix/linux_like/linux/musl/b32/riscv32/mod.rs
Removing src/unix/linux_like/linux/musl/b32/riscv32/align.rs
Auto-merging src/unix/linux_like/linux/musl/b32/mips/mod.rs
Removing src/unix/linux_like/linux/musl/b32/mips/align.rs
Auto-merging src/unix/linux_like/linux/musl/b32/arm/mod.rs
Removing src/unix/linux_like/linux/musl/b32/arm/align.rs
Auto-merging src/unix/linux_like/linux/mod.rs
CONFLICT (content): Merge conflict in src/unix/linux_like/linux/mod.rs
Removing src/unix/linux_like/linux/gnu/no_align.rs
Auto-merging src/unix/linux_like/linux/gnu/mod.rs
Auto-merging src/unix/linux_like/linux/gnu/b64/x86_64/x32.rs
Auto-merging src/unix/linux_like/linux/gnu/b64/x86_64/not_x32.rs
Auto-merging src/unix/linux_like/linux/gnu/b64/x86_64/mod.rs
CONFLICT (content): Merge conflict in src/unix/linux_like/linux/gnu/b64/x86_64/mod.rs
Removing src/unix/linux_like/linux/gnu/b64/x86_64/align.rs
Auto-merging src/unix/linux_like/linux/gnu/b64/sparc64/mod.rs
Removing src/unix/linux_like/linux/gnu/b64/sparc64/align.rs
Auto-merging src/unix/linux_like/linux/gnu/b64/s390x.rs
Auto-merging src/unix/linux_like/linux/gnu/b64/riscv64/mod.rs
Removing src/unix/linux_like/linux/gnu/b64/riscv64/align.rs
Auto-merging src/unix/linux_like/linux/gnu/b64/powerpc64/mod.rs
Removing src/unix/linux_like/linux/gnu/b64/powerpc64/align.rs
Auto-merging src/unix/linux_like/linux/gnu/b64/mips64/mod.rs
Removing src/unix/linux_like/linux/gnu/b64/mips64/align.rs
Auto-merging src/unix/linux_like/linux/gnu/b64/loongarch64/mod.rs
CONFLICT (content): Merge conflict in src/unix/linux_like/linux/gnu/b64/loongarch64/mod.rs
CONFLICT (modify/delete): src/unix/linux_like/linux/gnu/b64/loongarch64/align.rs deleted in heads/homu-tmp and modified in HEAD. Version HEAD of src/unix/linux_like/linux/gnu/b64/loongarch64/align.rs left in tree.
Auto-merging src/unix/linux_like/linux/gnu/b64/aarch64/mod.rs
CONFLICT (content): Merge conflict in src/unix/linux_like/linux/gnu/b64/aarch64/mod.rs
Auto-merging src/unix/linux_like/linux/gnu/b64/aarch64/lp64.rs
Removing src/unix/linux_like/linux/gnu/b64/aarch64/int128.rs
Auto-merging src/unix/linux_like/linux/gnu/b64/aarch64/ilp32.rs
CONFLICT (modify/delete): src/unix/linux_like/linux/gnu/b64/aarch64/align.rs deleted in heads/homu-tmp and modified in HEAD. Version HEAD of src/unix/linux_like/linux/gnu/b64/aarch64/align.rs left in tree.
Auto-merging src/unix/linux_like/linux/gnu/b32/x86/mod.rs
Removing src/unix/linux_like/linux/gnu/b32/x86/align.rs
Auto-merging src/unix/linux_like/linux/gnu/b32/sparc/mod.rs
Removing src/unix/linux_like/linux/gnu/b32/sparc/align.rs
Auto-merging src/unix/linux_like/linux/gnu/b32/riscv32/mod.rs
Removing src/unix/linux_like/linux/gnu/b32/riscv32/align.rs
Auto-merging src/unix/linux_like/linux/gnu/b32/mod.rs
Auto-merging src/unix/linux_like/linux/gnu/b32/mips/mod.rs
Removing src/unix/linux_like/linux/gnu/b32/mips/align.rs
Auto-merging src/unix/linux_like/linux/gnu/b32/arm/mod.rs
Removing src/unix/linux_like/linux/gnu/b32/arm/align.rs
Removing src/unix/linux_like/linux/gnu/align.rs
CONFLICT (modify/delete): src/unix/linux_like/linux/align.rs deleted in heads/homu-tmp and modified in HEAD. Version HEAD of src/unix/linux_like/linux/align.rs left in tree.
Removing src/unix/linux_like/emscripten/no_align.rs
Auto-merging src/unix/linux_like/emscripten/mod.rs
CONFLICT (content): Merge conflict in src/unix/linux_like/emscripten/mod.rs
Removing src/unix/linux_like/emscripten/align.rs
Auto-merging src/unix/linux_like/android/mod.rs
Auto-merging src/unix/linux_like/android/b64/x86_64/mod.rs
Removing src/unix/linux_like/android/b64/x86_64/align.rs
Auto-merging src/unix/linux_like/android/b64/aarch64/mod.rs
CONFLICT (content): Merge conflict in src/unix/linux_like/android/b64/aarch64/mod.rs
Removing src/unix/linux_like/android/b64/aarch64/int128.rs
Removing src/unix/linux_like/android/b64/aarch64/align.rs
Auto-merging src/unix/linux_like/android/b32/x86/mod.rs
Removing src/unix/linux_like/android/b32/x86/align.rs
Auto-merging src/unix/linux_like/android/b32/arm.rs
Auto-merging src/unix/bsd/netbsdlike/openbsd/mod.rs
CONFLICT (content): Merge conflict in src/unix/bsd/netbsdlike/openbsd/mod.rs
Auto-merging src/unix/bsd/netbsdlike/netbsd/mod.rs
Auto-merging src/unix/bsd/freebsdlike/mod.rs
Removing src/unix/bsd/freebsdlike/freebsd/x86_64/align.rs
Auto-merging src/unix/bsd/freebsdlike/freebsd/x86.rs
CONFLICT (content): Merge conflict in src/unix/bsd/freebsdlike/freebsd/x86.rs
Auto-merging src/unix/bsd/freebsdlike/freebsd/riscv64.rs
CONFLICT (content): Merge conflict in src/unix/bsd/freebsdlike/freebsd/riscv64.rs
Auto-merging src/unix/bsd/freebsdlike/freebsd/mod.rs
Auto-merging src/unix/bsd/freebsdlike/freebsd/freebsd14/mod.rs
Auto-merging src/unix/bsd/freebsdlike/freebsd/freebsd13/mod.rs
Auto-merging src/unix/bsd/freebsdlike/freebsd/freebsd12/mod.rs
Auto-merging src/unix/bsd/freebsdlike/freebsd/freebsd11/mod.rs
Auto-merging src/unix/bsd/freebsdlike/freebsd/aarch64.rs
CONFLICT (content): Merge conflict in src/unix/bsd/freebsdlike/freebsd/aarch64.rs
Auto-merging src/unix/bsd/freebsdlike/dragonfly/mod.rs
Auto-merging src/unix/bsd/apple/mod.rs
Removing src/unix/bsd/apple/b64/x86_64/align.rs
Auto-merging src/unix/bsd/apple/b64/aarch64/mod.rs
CONFLICT (content): Merge conflict in src/unix/bsd/apple/b64/aarch64/mod.rs
CONFLICT (modify/delete): src/unix/bsd/apple/b64/aarch64/align.rs deleted in heads/homu-tmp and modified in HEAD. Version HEAD of src/unix/bsd/apple/b64/aarch64/align.rs left in tree.
Removing src/unix/bsd/apple/b32/align.rs
Removing src/unix/align.rs
Auto-merging src/lib.rs
Auto-merging src/hermit/mod.rs
Removing src/fuchsia/no_align.rs
Auto-merging src/fuchsia/mod.rs
Removing src/fuchsia/align.rs
Auto-merging libc-test/build.rs
CONFLICT (content): Merge conflict in libc-test/build.rs
Auto-merging ci/build.sh
CONFLICT (content): Merge conflict in ci/build.sh
Auto-merging build.rs
CONFLICT (content): Merge conflict in build.rs
Auto-merging README.md
Auto-merging Cargo.toml
Auto-merging .github/workflows/bors.yml
CONFLICT (content): Merge conflict in .github/workflows/bors.yml
Automatic merge failed; fix conflicts and then commit the result.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.