Support #[global_allocator] without the allocator shim by bjorn3 · Pull Request #86844 · rust-lang/rust (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation129 Commits14 Checks0 Files changed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
This makes it possible to use liballoc/libstd in combination with --emit obj if you use #[global_allocator]. This is what rust-for-linux uses right now and systemd may use in the future. Currently they have to depend on the exact implementation of the allocator shim to create one themself as --emit obj doesn't create an allocator shim.
Note that currently the allocator shim also defines the oom error handler, which is normally required too. Once #![feature(default_alloc_error_handler)] becomes the only option, this can be avoided. In addition when using only fallible allocator methods and either --cfg no_global_oom_handling for liballoc (like rust-for-linux) or --gc-sections no references to the oom error handler will exist.
To avoid this feature being insta-stable, you will have to define __rust_no_alloc_shim_is_unstable to avoid linker errors.
(Labeling this with both T-compiler and T-lang as it originally involved both an implementation detail and had an insta-stable user facing change. As noted above, the __rust_no_alloc_shim_is_unstable symbol requirement should prevent unintended dependence on this unstable feature.)
Area: linking into static, shared libraries and binaries
Area: Custom and system allocators
Relevant to the language team, which will review and decide on the PR/issue.
Relevant to the compiler team, which will review and decide on the PR/issue.
labels
Some changes occured to rustc_codegen_cranelift
cc @bjorn3
r? @jackh726
(rust-highfive has picked a reviewer for you, use r? to override)
This comment has been minimized.
This comment has been minimized.
41 tasks
It took me a few while to understand this, so essentially instead of generating __rust_alloc that forwards to __rg_alloc or __rdl_alloc based on allocator kind, this PR makes #[global_allocator] generate __rust_alloc directly, while in case global allocator is absent, generate a shim that forwards __rust_alloc to __rdl_alloc.
Would it make sense to (in addition to this PR), just generate a
#[global_allocator] static GLOBAL: System = System;
at somewhere in higher level when global allocator is absent, instead of having the logic duplicated in codegen? This would allow __rdl_alloc etc to be removed completely (and is more consistent with what document describes in https://doc.rust-lang.org/std/alloc/struct.System.html).
Would it make sense to just generate a
#[global_allocator] static GLOBAL: System = System;
at somewhere in higher level instead of having the logic duplicated in codegen? This would allow
__rdl_allocetc to be removed completely (and is more consistent with what document describes in https://doc.rust-lang.org/std/alloc/struct.System.html).
You can use say --crate-type cdylib --crate-type lib, in which case the cdylib would need the allocator shim, but the lib must not get the allocator shim. Both use the same object files, except for the allocator shim object file that only the bin gets.
I posted a message in the wg-allocators Zulip stream to see if anyone there has opinions on this PR before it's merged.
herrnst pushed a commit to herrnst/linux-asahi that referenced this pull request
This is the second upgrade to the Rust toolchain, from 1.68.2 to 1.71.0 (i.e. the latest).
See the upgrade policy [1] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").
No unstable features (that we use) were stabilized.
Therefore, the only unstable feature allowed to be used outside
the kernel crate is still new_uninit, though other code to be
upstreamed may increase the list.
Please see [2] for details.
For the upgrade, this patch requires the following changes:
Removal of the
__rust_*allocator functions, together with the addition of the__rust_no_alloc_shim_is_unstablestatic. See [3] for details.Some more compiler builtins added due to
<f{32,64}>::midpoint()that got added in Rust 1.71 [4].
The vast majority of changes are due to our alloc fork being upgraded
at once.
There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream.
Instead of taking a look at the diff of this patch, an alternative
approach is reviewing a diff of the changes between upstream alloc and
the kernel's. This allows to easily inspect the kernel additions only,
especially to check if the fallible methods we already have still match
the infallible ones in the new version coming from upstream.
Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.
To apply these approaches, one may follow steps similar to the following
to generate a pair of patches that show the differences between upstream
Rust and the kernel (for the subset of alloc we use) before and after
applying this patch:
# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc
# Apply this patch.
git -C linux am rust-upgrade.patch
# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/allocNow one may check the new.patch to take a look at the additions (first
approach) or at the difference between those two patches (second
approach). For the latter, a side-by-side tool is recommended.
Link: https://rust-for-linux.com/rust-version-policy [1] Link: Rust-for-Linux/linux#2 [2] Link: rust-lang/rust#86844 [3] Link: rust-lang/rust#92048 [4] Signed-off-by: Miguel Ojeda ojeda@kernel.org
herrnst pushed a commit to herrnst/linux-asahi that referenced this pull request
This is the second upgrade to the Rust toolchain, from 1.68.2 to 1.71.0 (i.e. the latest).
See the upgrade policy [1] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").
No unstable features (that we use) were stabilized.
Therefore, the only unstable feature allowed to be used outside
the kernel crate is still new_uninit, though other code to be
upstreamed may increase the list.
Please see [2] for details.
For the upgrade, this patch requires the following changes:
Removal of the
__rust_*allocator functions, together with the addition of the__rust_no_alloc_shim_is_unstablestatic. See [3] for details.Some more compiler builtins added due to
<f{32,64}>::midpoint()that got added in Rust 1.71 [4].
The vast majority of changes are due to our alloc fork being upgraded
at once.
There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream.
Instead of taking a look at the diff of this patch, an alternative
approach is reviewing a diff of the changes between upstream alloc and
the kernel's. This allows to easily inspect the kernel additions only,
especially to check if the fallible methods we already have still match
the infallible ones in the new version coming from upstream.
Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.
To apply these approaches, one may follow steps similar to the following
to generate a pair of patches that show the differences between upstream
Rust and the kernel (for the subset of alloc we use) before and after
applying this patch:
# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc
# Apply this patch.
git -C linux am rust-upgrade.patch
# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/allocNow one may check the new.patch to take a look at the additions (first
approach) or at the difference between those two patches (second
approach). For the latter, a side-by-side tool is recommended.
Link: https://rust-for-linux.com/rust-version-policy [1] Link: Rust-for-Linux/linux#2 [2] Link: rust-lang/rust#86844 [3] Link: rust-lang/rust#92048 [4] Signed-off-by: Miguel Ojeda ojeda@kernel.org
herrnst pushed a commit to herrnst/linux-asahi that referenced this pull request
This is the second upgrade to the Rust toolchain, from 1.68.2 to 1.71.0 (i.e. the latest).
See the upgrade policy [1] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").
No unstable features (that we use) were stabilized.
Therefore, the only unstable feature allowed to be used outside
the kernel crate is still new_uninit, though other code to be
upstreamed may increase the list.
Please see [2] for details.
For the upgrade, this patch requires the following changes:
Removal of the
__rust_*allocator functions, together with the addition of the__rust_no_alloc_shim_is_unstablestatic. See [3] for details.Some more compiler builtins added due to
<f{32,64}>::midpoint()that got added in Rust 1.71 [4].
The vast majority of changes are due to our alloc fork being upgraded
at once.
There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream.
Instead of taking a look at the diff of this patch, an alternative
approach is reviewing a diff of the changes between upstream alloc and
the kernel's. This allows to easily inspect the kernel additions only,
especially to check if the fallible methods we already have still match
the infallible ones in the new version coming from upstream.
Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.
To apply these approaches, one may follow steps similar to the following
to generate a pair of patches that show the differences between upstream
Rust and the kernel (for the subset of alloc we use) before and after
applying this patch:
# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc
# Apply this patch.
git -C linux am rust-upgrade.patch
# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/allocNow one may check the new.patch to take a look at the additions (first
approach) or at the difference between those two patches (second
approach). For the latter, a side-by-side tool is recommended.
Link: https://rust-for-linux.com/rust-version-policy [1] Link: Rust-for-Linux/linux#2 [2] Link: rust-lang/rust#86844 [3] Link: rust-lang/rust#92048 [4] Signed-off-by: Miguel Ojeda ojeda@kernel.org
herrnst pushed a commit to herrnst/linux-asahi that referenced this pull request
This is the second upgrade to the Rust toolchain, from 1.68.2 to 1.71.0 (i.e. the latest).
See the upgrade policy [1] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").
No unstable features (that we use) were stabilized.
Therefore, the only unstable feature allowed to be used outside
the kernel crate is still new_uninit, though other code to be
upstreamed may increase the list.
Please see [2] for details.
For the upgrade, this patch requires the following changes:
Removal of the
__rust_*allocator functions, together with the addition of the__rust_no_alloc_shim_is_unstablestatic. See [3] for details.Some more compiler builtins added due to
<f{32,64}>::midpoint()that got added in Rust 1.71 [4].
The vast majority of changes are due to our alloc fork being upgraded
at once.
There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream.
Instead of taking a look at the diff of this patch, an alternative
approach is reviewing a diff of the changes between upstream alloc and
the kernel's. This allows to easily inspect the kernel additions only,
especially to check if the fallible methods we already have still match
the infallible ones in the new version coming from upstream.
Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.
To apply these approaches, one may follow steps similar to the following
to generate a pair of patches that show the differences between upstream
Rust and the kernel (for the subset of alloc we use) before and after
applying this patch:
# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc
# Apply this patch.
git -C linux am rust-upgrade.patch
# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/allocNow one may check the new.patch to take a look at the additions (first
approach) or at the difference between those two patches (second
approach). For the latter, a side-by-side tool is recommended.
Link: https://rust-for-linux.com/rust-version-policy [1] Link: Rust-for-Linux/linux#2 [2] Link: rust-lang/rust#86844 [3] Link: rust-lang/rust#92048 [4] Signed-off-by: Miguel Ojeda ojeda@kernel.org
herrnst pushed a commit to herrnst/linux-asahi that referenced this pull request
This is the second upgrade to the Rust toolchain, from 1.68.2 to 1.71.0 (i.e. the latest).
See the upgrade policy [1] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").
No unstable features (that we use) were stabilized.
Therefore, the only unstable feature allowed to be used outside
the kernel crate is still new_uninit, though other code to be
upstreamed may increase the list.
Please see [2] for details.
For the upgrade, this patch requires the following changes:
Removal of the
__rust_*allocator functions, together with the addition of the__rust_no_alloc_shim_is_unstablestatic. See [3] for details.Some more compiler builtins added due to
<f{32,64}>::midpoint()that got added in Rust 1.71 [4].
The vast majority of changes are due to our alloc fork being upgraded
at once.
There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream.
Instead of taking a look at the diff of this patch, an alternative
approach is reviewing a diff of the changes between upstream alloc and
the kernel's. This allows to easily inspect the kernel additions only,
especially to check if the fallible methods we already have still match
the infallible ones in the new version coming from upstream.
Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.
To apply these approaches, one may follow steps similar to the following
to generate a pair of patches that show the differences between upstream
Rust and the kernel (for the subset of alloc we use) before and after
applying this patch:
# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc
# Apply this patch.
git -C linux am rust-upgrade.patch
# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/allocNow one may check the new.patch to take a look at the additions (first
approach) or at the difference between those two patches (second
approach). For the latter, a side-by-side tool is recommended.
Link: https://rust-for-linux.com/rust-version-policy [1] Link: Rust-for-Linux/linux#2 [2] Link: rust-lang/rust#86844 [3] Link: rust-lang/rust#92048 [4] Signed-off-by: Miguel Ojeda ojeda@kernel.org
herrnst pushed a commit to herrnst/linux-asahi that referenced this pull request
This is the second upgrade to the Rust toolchain, from 1.68.2 to 1.71.0 (i.e. the latest).
See the upgrade policy [1] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").
No unstable features (that we use) were stabilized.
Therefore, the only unstable feature allowed to be used outside
the kernel crate is still new_uninit, though other code to be
upstreamed may increase the list.
Please see [2] for details.
For the upgrade, this patch requires the following changes:
Removal of the
__rust_*allocator functions, together with the addition of the__rust_no_alloc_shim_is_unstablestatic. See [3] for details.Some more compiler builtins added due to
<f{32,64}>::midpoint()that got added in Rust 1.71 [4].
The vast majority of changes are due to our alloc fork being upgraded
at once.
There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream.
Instead of taking a look at the diff of this patch, an alternative
approach is reviewing a diff of the changes between upstream alloc and
the kernel's. This allows to easily inspect the kernel additions only,
especially to check if the fallible methods we already have still match
the infallible ones in the new version coming from upstream.
Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.
To apply these approaches, one may follow steps similar to the following
to generate a pair of patches that show the differences between upstream
Rust and the kernel (for the subset of alloc we use) before and after
applying this patch:
# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc
# Apply this patch.
git -C linux am rust-upgrade.patch
# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/allocNow one may check the new.patch to take a look at the additions (first
approach) or at the difference between those two patches (second
approach). For the latter, a side-by-side tool is recommended.
Link: https://rust-for-linux.com/rust-version-policy [1] Link: Rust-for-Linux/linux#2 [2] Link: rust-lang/rust#86844 [3] Link: rust-lang/rust#92048 [4] Signed-off-by: Miguel Ojeda ojeda@kernel.org
herrnst pushed a commit to herrnst/linux-asahi that referenced this pull request
This is the second upgrade to the Rust toolchain, from 1.68.2 to 1.71.0 (i.e. the latest).
See the upgrade policy [1] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").
No unstable features (that we use) were stabilized.
Therefore, the only unstable feature allowed to be used outside
the kernel crate is still new_uninit, though other code to be
upstreamed may increase the list.
Please see [2] for details.
For the upgrade, this patch requires the following changes:
Removal of the
__rust_*allocator functions, together with the addition of the__rust_no_alloc_shim_is_unstablestatic. See [3] for details.Some more compiler builtins added due to
<f{32,64}>::midpoint()that got added in Rust 1.71 [4].
The vast majority of changes are due to our alloc fork being upgraded
at once.
There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream.
Instead of taking a look at the diff of this patch, an alternative
approach is reviewing a diff of the changes between upstream alloc and
the kernel's. This allows to easily inspect the kernel additions only,
especially to check if the fallible methods we already have still match
the infallible ones in the new version coming from upstream.
Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.
To apply these approaches, one may follow steps similar to the following
to generate a pair of patches that show the differences between upstream
Rust and the kernel (for the subset of alloc we use) before and after
applying this patch:
# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc
# Apply this patch.
git -C linux am rust-upgrade.patch
# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/allocNow one may check the new.patch to take a look at the additions (first
approach) or at the difference between those two patches (second
approach). For the latter, a side-by-side tool is recommended.
Link: https://rust-for-linux.com/rust-version-policy [1] Link: Rust-for-Linux/linux#2 [2] Link: rust-lang/rust#86844 [3] Link: rust-lang/rust#92048 [4] Signed-off-by: Miguel Ojeda ojeda@kernel.org
vtta pushed a commit to vtta/linux-archive that referenced this pull request
This is the second upgrade to the Rust toolchain, from 1.68.2 to 1.71.1 (i.e. the latest).
See the upgrade policy [1] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").
Unstable features
No unstable features (that we use) were stabilized.
Therefore, the only unstable feature allowed to be used outside
the kernel crate is still new_uninit, though other code to be
upstreamed may increase the list.
Please see [2] for details.
Required changes
For the upgrade, this patch requires the following changes:
Removal of the
__rust_*allocator functions, together with the addition of the__rust_no_alloc_shim_is_unstablestatic. See [3] for details.Some more compiler builtins added due to
<f{32,64}>::midpoint()that got added in Rust 1.71 [4].
alloc upgrade and reviewing
The vast majority of changes are due to our alloc fork being upgraded
at once.
There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream.
Instead of taking a look at the diff of this patch, an alternative
approach is reviewing a diff of the changes between upstream alloc and
the kernel's. This allows to easily inspect the kernel additions only,
especially to check if the fallible methods we already have still match
the infallible ones in the new version coming from upstream.
Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.
To apply these approaches, one may follow steps similar to the following
to generate a pair of patches that show the differences between upstream
Rust and the kernel (for the subset of alloc we use) before and after
applying this patch:
# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc
# Apply this patch.
git -C linux am rust-upgrade.patch
# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/allocNow one may check the new.patch to take a look at the additions (first
approach) or at the difference between those two patches (second
approach). For the latter, a side-by-side tool is recommended.
Link: https://rust-for-linux.com/rust-version-policy [1] Link: Rust-for-Linux#2 [2] Link: rust-lang/rust#86844 [3] Link: rust-lang/rust#92048 [4] Closes: Rust-for-Linux#68 Reviewed-by: Martin Rodriguez Reboredo yakoyoku@gmail.com Reviewed-by: Trevor Gross tmgross@umich.edu Link: https://lore.kernel.org/r/20230729220317.416771-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda ojeda@kernel.org
herrnst pushed a commit to herrnst/linux-asahi that referenced this pull request
This is the second upgrade to the Rust toolchain, from 1.68.2 to 1.71.0 (i.e. the latest).
See the upgrade policy [1] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").
No unstable features (that we use) were stabilized.
Therefore, the only unstable feature allowed to be used outside
the kernel crate is still new_uninit, though other code to be
upstreamed may increase the list.
Please see [2] for details.
For the upgrade, this patch requires the following changes:
Removal of the
__rust_*allocator functions, together with the addition of the__rust_no_alloc_shim_is_unstablestatic. See [3] for details.Some more compiler builtins added due to
<f{32,64}>::midpoint()that got added in Rust 1.71 [4].
The vast majority of changes are due to our alloc fork being upgraded
at once.
There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream.
Instead of taking a look at the diff of this patch, an alternative
approach is reviewing a diff of the changes between upstream alloc and
the kernel's. This allows to easily inspect the kernel additions only,
especially to check if the fallible methods we already have still match
the infallible ones in the new version coming from upstream.
Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.
To apply these approaches, one may follow steps similar to the following
to generate a pair of patches that show the differences between upstream
Rust and the kernel (for the subset of alloc we use) before and after
applying this patch:
# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc
# Apply this patch.
git -C linux am rust-upgrade.patch
# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/allocNow one may check the new.patch to take a look at the additions (first
approach) or at the difference between those two patches (second
approach). For the latter, a side-by-side tool is recommended.
Link: https://rust-for-linux.com/rust-version-policy [1] Link: Rust-for-Linux/linux#2 [2] Link: rust-lang/rust#86844 [3] Link: rust-lang/rust#92048 [4] Signed-off-by: Miguel Ojeda ojeda@kernel.org
herrnst pushed a commit to herrnst/linux-asahi that referenced this pull request
This is the second upgrade to the Rust toolchain, from 1.68.2 to 1.71.0 (i.e. the latest).
See the upgrade policy [1] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").
No unstable features (that we use) were stabilized.
Therefore, the only unstable feature allowed to be used outside
the kernel crate is still new_uninit, though other code to be
upstreamed may increase the list.
Please see [2] for details.
For the upgrade, this patch requires the following changes:
Removal of the
__rust_*allocator functions, together with the addition of the__rust_no_alloc_shim_is_unstablestatic. See [3] for details.Some more compiler builtins added due to
<f{32,64}>::midpoint()that got added in Rust 1.71 [4].
The vast majority of changes are due to our alloc fork being upgraded
at once.
There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream.
Instead of taking a look at the diff of this patch, an alternative
approach is reviewing a diff of the changes between upstream alloc and
the kernel's. This allows to easily inspect the kernel additions only,
especially to check if the fallible methods we already have still match
the infallible ones in the new version coming from upstream.
Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.
To apply these approaches, one may follow steps similar to the following
to generate a pair of patches that show the differences between upstream
Rust and the kernel (for the subset of alloc we use) before and after
applying this patch:
# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc
# Apply this patch.
git -C linux am rust-upgrade.patch
# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/allocNow one may check the new.patch to take a look at the additions (first
approach) or at the difference between those two patches (second
approach). For the latter, a side-by-side tool is recommended.
Link: https://rust-for-linux.com/rust-version-policy [1] Link: Rust-for-Linux/linux#2 [2] Link: rust-lang/rust#86844 [3] Link: rust-lang/rust#92048 [4] Signed-off-by: Miguel Ojeda ojeda@kernel.org
herrnst pushed a commit to herrnst/linux-asahi that referenced this pull request
This is the second upgrade to the Rust toolchain, from 1.68.2 to 1.71.0 (i.e. the latest).
See the upgrade policy [1] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").
No unstable features (that we use) were stabilized.
Therefore, the only unstable feature allowed to be used outside
the kernel crate is still new_uninit, though other code to be
upstreamed may increase the list.
Please see [2] for details.
For the upgrade, this patch requires the following changes:
Removal of the
__rust_*allocator functions, together with the addition of the__rust_no_alloc_shim_is_unstablestatic. See [3] for details.Some more compiler builtins added due to
<f{32,64}>::midpoint()that got added in Rust 1.71 [4].
The vast majority of changes are due to our alloc fork being upgraded
at once.
There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream.
Instead of taking a look at the diff of this patch, an alternative
approach is reviewing a diff of the changes between upstream alloc and
the kernel's. This allows to easily inspect the kernel additions only,
especially to check if the fallible methods we already have still match
the infallible ones in the new version coming from upstream.
Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.
To apply these approaches, one may follow steps similar to the following
to generate a pair of patches that show the differences between upstream
Rust and the kernel (for the subset of alloc we use) before and after
applying this patch:
# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc
# Apply this patch.
git -C linux am rust-upgrade.patch
# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/allocNow one may check the new.patch to take a look at the additions (first
approach) or at the difference between those two patches (second
approach). For the latter, a side-by-side tool is recommended.
Link: https://rust-for-linux.com/rust-version-policy [1] Link: Rust-for-Linux/linux#2 [2] Link: rust-lang/rust#86844 [3] Link: rust-lang/rust#92048 [4] Signed-off-by: Miguel Ojeda ojeda@kernel.org
herrnst pushed a commit to herrnst/linux-asahi that referenced this pull request
This is the second upgrade to the Rust toolchain, from 1.68.2 to 1.71.0 (i.e. the latest).
See the upgrade policy [1] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").
No unstable features (that we use) were stabilized.
Therefore, the only unstable feature allowed to be used outside
the kernel crate is still new_uninit, though other code to be
upstreamed may increase the list.
Please see [2] for details.
For the upgrade, this patch requires the following changes:
Removal of the
__rust_*allocator functions, together with the addition of the__rust_no_alloc_shim_is_unstablestatic. See [3] for details.Some more compiler builtins added due to
<f{32,64}>::midpoint()that got added in Rust 1.71 [4].
The vast majority of changes are due to our alloc fork being upgraded
at once.
There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream.
Instead of taking a look at the diff of this patch, an alternative
approach is reviewing a diff of the changes between upstream alloc and
the kernel's. This allows to easily inspect the kernel additions only,
especially to check if the fallible methods we already have still match
the infallible ones in the new version coming from upstream.
Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.
To apply these approaches, one may follow steps similar to the following
to generate a pair of patches that show the differences between upstream
Rust and the kernel (for the subset of alloc we use) before and after
applying this patch:
# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc
# Apply this patch.
git -C linux am rust-upgrade.patch
# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/allocNow one may check the new.patch to take a look at the additions (first
approach) or at the difference between those two patches (second
approach). For the latter, a side-by-side tool is recommended.
Link: https://rust-for-linux.com/rust-version-policy [1] Link: Rust-for-Linux/linux#2 [2] Link: rust-lang/rust#86844 [3] Link: rust-lang/rust#92048 [4] Signed-off-by: Miguel Ojeda ojeda@kernel.org
herrnst pushed a commit to herrnst/linux-asahi that referenced this pull request
This is the second upgrade to the Rust toolchain, from 1.68.2 to 1.71.0 (i.e. the latest).
See the upgrade policy [1] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").
No unstable features (that we use) were stabilized.
Therefore, the only unstable feature allowed to be used outside
the kernel crate is still new_uninit, though other code to be
upstreamed may increase the list.
Please see [2] for details.
For the upgrade, this patch requires the following changes:
Removal of the
__rust_*allocator functions, together with the addition of the__rust_no_alloc_shim_is_unstablestatic. See [3] for details.Some more compiler builtins added due to
<f{32,64}>::midpoint()that got added in Rust 1.71 [4].
The vast majority of changes are due to our alloc fork being upgraded
at once.
There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream.
Instead of taking a look at the diff of this patch, an alternative
approach is reviewing a diff of the changes between upstream alloc and
the kernel's. This allows to easily inspect the kernel additions only,
especially to check if the fallible methods we already have still match
the infallible ones in the new version coming from upstream.
Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.
To apply these approaches, one may follow steps similar to the following
to generate a pair of patches that show the differences between upstream
Rust and the kernel (for the subset of alloc we use) before and after
applying this patch:
# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc
# Apply this patch.
git -C linux am rust-upgrade.patch
# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/allocNow one may check the new.patch to take a look at the additions (first
approach) or at the difference between those two patches (second
approach). For the latter, a side-by-side tool is recommended.
Link: https://rust-for-linux.com/rust-version-policy [1] Link: Rust-for-Linux/linux#2 [2] Link: rust-lang/rust#86844 [3] Link: rust-lang/rust#92048 [4] Signed-off-by: Miguel Ojeda ojeda@kernel.org
herrnst pushed a commit to herrnst/linux-asahi that referenced this pull request
This is the second upgrade to the Rust toolchain, from 1.68.2 to 1.71.0 (i.e. the latest).
See the upgrade policy [1] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").
No unstable features (that we use) were stabilized.
Therefore, the only unstable feature allowed to be used outside
the kernel crate is still new_uninit, though other code to be
upstreamed may increase the list.
Please see [2] for details.
For the upgrade, this patch requires the following changes:
Removal of the
__rust_*allocator functions, together with the addition of the__rust_no_alloc_shim_is_unstablestatic. See [3] for details.Some more compiler builtins added due to
<f{32,64}>::midpoint()that got added in Rust 1.71 [4].
The vast majority of changes are due to our alloc fork being upgraded
at once.
There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream.
Instead of taking a look at the diff of this patch, an alternative
approach is reviewing a diff of the changes between upstream alloc and
the kernel's. This allows to easily inspect the kernel additions only,
especially to check if the fallible methods we already have still match
the infallible ones in the new version coming from upstream.
Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.
To apply these approaches, one may follow steps similar to the following
to generate a pair of patches that show the differences between upstream
Rust and the kernel (for the subset of alloc we use) before and after
applying this patch:
# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc
# Apply this patch.
git -C linux am rust-upgrade.patch
# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/allocNow one may check the new.patch to take a look at the additions (first
approach) or at the difference between those two patches (second
approach). For the latter, a side-by-side tool is recommended.
Link: https://rust-for-linux.com/rust-version-policy [1] Link: Rust-for-Linux/linux#2 [2] Link: rust-lang/rust#86844 [3] Link: rust-lang/rust#92048 [4] Signed-off-by: Miguel Ojeda ojeda@kernel.org
herrnst pushed a commit to herrnst/linux-asahi that referenced this pull request
This is the second upgrade to the Rust toolchain, from 1.68.2 to 1.71.0 (i.e. the latest).
See the upgrade policy [1] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").
No unstable features (that we use) were stabilized.
Therefore, the only unstable feature allowed to be used outside
the kernel crate is still new_uninit, though other code to be
upstreamed may increase the list.
Please see [2] for details.
For the upgrade, this patch requires the following changes:
Removal of the
__rust_*allocator functions, together with the addition of the__rust_no_alloc_shim_is_unstablestatic. See [3] for details.Some more compiler builtins added due to
<f{32,64}>::midpoint()that got added in Rust 1.71 [4].
The vast majority of changes are due to our alloc fork being upgraded
at once.
There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream.
Instead of taking a look at the diff of this patch, an alternative
approach is reviewing a diff of the changes between upstream alloc and
the kernel's. This allows to easily inspect the kernel additions only,
especially to check if the fallible methods we already have still match
the infallible ones in the new version coming from upstream.
Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.
To apply these approaches, one may follow steps similar to the following
to generate a pair of patches that show the differences between upstream
Rust and the kernel (for the subset of alloc we use) before and after
applying this patch:
# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc
# Apply this patch.
git -C linux am rust-upgrade.patch
# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/allocNow one may check the new.patch to take a look at the additions (first
approach) or at the difference between those two patches (second
approach). For the latter, a side-by-side tool is recommended.
Link: https://rust-for-linux.com/rust-version-policy [1] Link: Rust-for-Linux/linux#2 [2] Link: rust-lang/rust#86844 [3] Link: rust-lang/rust#92048 [4] Signed-off-by: Miguel Ojeda ojeda@kernel.org
herrnst pushed a commit to herrnst/linux-asahi that referenced this pull request
This is the second upgrade to the Rust toolchain, from 1.68.2 to 1.71.0 (i.e. the latest).
See the upgrade policy [1] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").
No unstable features (that we use) were stabilized.
Therefore, the only unstable feature allowed to be used outside
the kernel crate is still new_uninit, though other code to be
upstreamed may increase the list.
Please see [2] for details.
For the upgrade, this patch requires the following changes:
Removal of the
__rust_*allocator functions, together with the addition of the__rust_no_alloc_shim_is_unstablestatic. See [3] for details.Some more compiler builtins added due to
<f{32,64}>::midpoint()that got added in Rust 1.71 [4].
The vast majority of changes are due to our alloc fork being upgraded
at once.
There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream.
Instead of taking a look at the diff of this patch, an alternative
approach is reviewing a diff of the changes between upstream alloc and
the kernel's. This allows to easily inspect the kernel additions only,
especially to check if the fallible methods we already have still match
the infallible ones in the new version coming from upstream.
Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.
To apply these approaches, one may follow steps similar to the following
to generate a pair of patches that show the differences between upstream
Rust and the kernel (for the subset of alloc we use) before and after
applying this patch:
# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc
# Apply this patch.
git -C linux am rust-upgrade.patch
# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/allocNow one may check the new.patch to take a look at the additions (first
approach) or at the difference between those two patches (second
approach). For the latter, a side-by-side tool is recommended.
Link: https://rust-for-linux.com/rust-version-policy [1] Link: Rust-for-Linux/linux#2 [2] Link: rust-lang/rust#86844 [3] Link: rust-lang/rust#92048 [4] Signed-off-by: Miguel Ojeda ojeda@kernel.org
herrnst pushed a commit to herrnst/linux-asahi that referenced this pull request
This is the second upgrade to the Rust toolchain, from 1.68.2 to 1.71.0 (i.e. the latest).
See the upgrade policy [1] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").
No unstable features (that we use) were stabilized.
Therefore, the only unstable feature allowed to be used outside
the kernel crate is still new_uninit, though other code to be
upstreamed may increase the list.
Please see [2] for details.
For the upgrade, this patch requires the following changes:
Removal of the
__rust_*allocator functions, together with the addition of the__rust_no_alloc_shim_is_unstablestatic. See [3] for details.Some more compiler builtins added due to
<f{32,64}>::midpoint()that got added in Rust 1.71 [4].
The vast majority of changes are due to our alloc fork being upgraded
at once.
There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream.
Instead of taking a look at the diff of this patch, an alternative
approach is reviewing a diff of the changes between upstream alloc and
the kernel's. This allows to easily inspect the kernel additions only,
especially to check if the fallible methods we already have still match
the infallible ones in the new version coming from upstream.
Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.
To apply these approaches, one may follow steps similar to the following
to generate a pair of patches that show the differences between upstream
Rust and the kernel (for the subset of alloc we use) before and after
applying this patch:
# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc
# Apply this patch.
git -C linux am rust-upgrade.patch
# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/allocNow one may check the new.patch to take a look at the additions (first
approach) or at the difference between those two patches (second
approach). For the latter, a side-by-side tool is recommended.
Link: https://rust-for-linux.com/rust-version-policy [1] Link: Rust-for-Linux/linux#2 [2] Link: rust-lang/rust#86844 [3] Link: rust-lang/rust#92048 [4] Signed-off-by: Miguel Ojeda ojeda@kernel.org
herrnst pushed a commit to herrnst/linux-asahi that referenced this pull request
This is the second upgrade to the Rust toolchain, from 1.68.2 to 1.71.0 (i.e. the latest).
See the upgrade policy [1] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").
No unstable features (that we use) were stabilized.
Therefore, the only unstable feature allowed to be used outside
the kernel crate is still new_uninit, though other code to be
upstreamed may increase the list.
Please see [2] for details.
For the upgrade, this patch requires the following changes:
Removal of the
__rust_*allocator functions, together with the addition of the__rust_no_alloc_shim_is_unstablestatic. See [3] for details.Some more compiler builtins added due to
<f{32,64}>::midpoint()that got added in Rust 1.71 [4].
The vast majority of changes are due to our alloc fork being upgraded
at once.
There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream.
Instead of taking a look at the diff of this patch, an alternative
approach is reviewing a diff of the changes between upstream alloc and
the kernel's. This allows to easily inspect the kernel additions only,
especially to check if the fallible methods we already have still match
the infallible ones in the new version coming from upstream.
Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.
To apply these approaches, one may follow steps similar to the following
to generate a pair of patches that show the differences between upstream
Rust and the kernel (for the subset of alloc we use) before and after
applying this patch:
# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc
# Apply this patch.
git -C linux am rust-upgrade.patch
# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/allocNow one may check the new.patch to take a look at the additions (first
approach) or at the difference between those two patches (second
approach). For the latter, a side-by-side tool is recommended.
Link: https://rust-for-linux.com/rust-version-policy [1] Link: Rust-for-Linux/linux#2 [2] Link: rust-lang/rust#86844 [3] Link: rust-lang/rust#92048 [4] Signed-off-by: Miguel Ojeda ojeda@kernel.org
bors added a commit to rust-lang-ci/rust that referenced this pull request
…=bjorn3
read_volatile __rust_no_alloc_shim_is_unstable in alloc_zeroed
It was pointed out in rust-lang#128854 (comment) that the magic volatile read was probably missing from alloc_zeroed. I can't find any mention of alloc_zeroed on rust-lang#86844, so it looks like this was just missed initially.
bors added a commit to rust-lang-ci/rust that referenced this pull request
[WIP] Use weak linkage instead of compiler generated shims
rust-lang#86844 (unstably) made it possible to avoid the allocator shim when using #[global_allocator]. This PR makes it possible to also avoid the allocator shim when using the default allocator in libstd by making use of weak linkage. Eventual stabilization of avoiding the allocator shim may be blocked on it working with the default allocator too.
This is still keeping the __rust_no_alloc_shim_is_unstable symbol for now until rust-lang#123015 gets stabilized.
TODO: Update comments everywhere, test on macOS and Windows and write a better PR description why we want this. Also prevent codegen of weak symbols when there is a non-weak definition of the same symbol in the same codegen unit.
try-job: x86_64-msvc try-job: x86_64-apple-1 try-job: x86_64-apple-2
bors added a commit to rust-lang-ci/rust that referenced this pull request
[WIP] Use weak linkage instead of compiler generated shims
rust-lang#86844 (unstably) made it possible to avoid the allocator shim when using #[global_allocator]. This PR makes it possible to also avoid the allocator shim when using the default allocator in libstd by making use of weak linkage. Eventual stabilization of avoiding the allocator shim may be blocked on it working with the default allocator too.
This is still keeping the __rust_no_alloc_shim_is_unstable symbol for now until rust-lang#123015 gets stabilized.
TODO: Update comments everywhere, test on macOS and Windows and write a better PR description why we want this. Also prevent codegen of weak symbols when there is a non-weak definition of the same symbol in the same codegen unit.
try-job: x86_64-msvc try-job: x86_64-apple-1 try-job: x86_64-apple-2
bors added a commit to rust-lang-ci/rust that referenced this pull request
[WIP] Use weak linkage instead of compiler generated shims
rust-lang#86844 (unstably) made it possible to avoid the allocator shim when using #[global_allocator]. This PR makes it possible to also avoid the allocator shim when using the default allocator in libstd by making use of weak linkage. Eventual stabilization of avoiding the allocator shim may be blocked on it working with the default allocator too.
This is still keeping the __rust_no_alloc_shim_is_unstable symbol for now until rust-lang#123015 gets stabilized.
TODO: Update comments everywhere, test on macOS and Windows and write a better PR description why we want this. Also prevent codegen of weak symbols when there is a non-weak definition of the same symbol in the same codegen unit.
try-zzz-job: x86_64-msvc try-job: x86_64-apple-1 try-job: x86_64-apple-2
bors added a commit to rust-lang-ci/rust that referenced this pull request
[WIP] Use weak linkage instead of compiler generated shims
rust-lang#86844 (unstably) made it possible to avoid the allocator shim when using #[global_allocator]. This PR makes it possible to also avoid the allocator shim when using the default allocator in libstd by making use of weak linkage. Eventual stabilization of avoiding the allocator shim may be blocked on it working with the default allocator too.
This is still keeping the __rust_no_alloc_shim_is_unstable symbol for now until rust-lang#123015 gets stabilized.
TODO: Update comments everywhere, test on macOS and Windows and write a better PR description why we want this. Also prevent codegen of weak symbols when there is a non-weak definition of the same symbol in the same codegen unit.
try-zzz-job: x86_64-msvc try-job: x86_64-apple-1 try-job: x86_64-apple-2
bors added a commit to rust-lang-ci/rust that referenced this pull request
[WIP] Use weak linkage instead of compiler generated shims
rust-lang#86844 (unstably) made it possible to avoid the allocator shim when using #[global_allocator]. This PR makes it possible to also avoid the allocator shim when using the default allocator in libstd by making use of weak linkage. Eventual stabilization of avoiding the allocator shim may be blocked on it working with the default allocator too.
This is still keeping the __rust_no_alloc_shim_is_unstable symbol for now until rust-lang#123015 gets stabilized.
TODO: Update comments everywhere, test on macOS and Windows and write a better PR description why we want this. Also prevent codegen of weak symbols when there is a non-weak definition of the same symbol in the same codegen unit.
try-job: x86_64-msvc try-zzz-job: x86_64-apple-1 try-zzz-job: x86_64-apple-2
Labels
Area: Custom and system allocators
Area: linking into static, shared libraries and binaries
Relevant for the Rust-for-Linux project
This PR was explicitly merged by bors.
Performance regression.
The performance regression has been triaged.
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Relevant to the compiler team, which will review and decide on the PR/issue.
Relevant to the language team, which will review and decide on the PR/issue.