Skip to content

Tracking Issue for __rust_no_alloc_shim_is_unstable #123015

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.

Sign up for GitHub

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

Jump to bottom
Open
1 of 3 tasks
Mark-Simulacrum opened this issue Mar 24, 2024 · 4 comments
Open
1 of 3 tasks

Tracking Issue for __rust_no_alloc_shim_is_unstable #123015

Mark-Simulacrum opened this issue Mar 24, 2024 · 4 comments
Labels
A-allocators Area: Custom and system allocators A-linkage Area: linking into static, shared libraries and binaries C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@Mark-Simulacrum
Copy link
Member

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

Unresolved Questions

Implementation history
@Mark-Simulacrum Mark-Simulacrum added A-linkage Area: linking into static, shared libraries and binaries A-allocators Area: Custom and system allocators T-lang Relevant to the language team, which will review and decide on the PR/issue. C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC labels Mar 24, 2024
@Mark-Simulacrum
Copy link
Member Author

cc @bjorn3 -- wanted to file something official for this internal unstable detail (don't think anything existed already).

@bjorn3
Copy link
Member

bjorn3 commented Mar 25, 2024

#102318 is not really useful as the alloc error handler is still part of the allocator shim. #112331 would entirely remove the allocation error handler. After that the allocator shim only contains the __rust_alloc_error_handler_should_panic static when #[global_allocator] is used. Maybe a weak static in liballoc with the default value when -Zoom is not passed would work for that?

@ojeda ojeda mentioned this issue Aug 6, 2024
Open
94 tasks
@bjorn3 bjorn3 mentioned this issue Dec 20, 2024
Draft
bors added a commit to rust-lang-ci/rust that referenced this issue Dec 20, 2024
@bors
Auto merge of rust-lang#134522 - bjorn3:weak_linkage_allocator, r=<try>
25f4036 
[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 issue Dec 20, 2024
@bors
Auto merge of rust-lang#134522 - bjorn3:weak_linkage_allocator, r=<try>
3659c42 
[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 issue Dec 20, 2024
@bors
Auto merge of rust-lang#134522 - bjorn3:weak_linkage_allocator, r=<try>
f0b0345 
[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 issue Jan 17, 2025
@bors
Auto merge of rust-lang#134522 - bjorn3:weak_linkage_allocator, r=<try>
d5915d9 
[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 <strike>macOS and</strike> 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 issue Jan 17, 2025
@bors
Auto merge of rust-lang#134522 - bjorn3:weak_linkage_allocator, r=<try>
0b44463 
[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 <strike>macOS and</strike> 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
@bjorn3 bjorn3 mentioned this issue Feb 7, 2025
Merged
@riking
Copy link

riking commented Mar 21, 2025 •
edited
Loading

After #127173, definitions of this symbol must be migrated to include the #[rustc_std_internal_symbol] attribute, it looks like.

@bjorn3
Copy link
Member

bjorn3 commented Mar 21, 2025

It should be to avoid breakage in the future, but currently there is an exception to not mangle this symbol for now.

aarongable pushed a commit to chromium/chromium that referenced this issue Apr 3, 2025
@chbaker0
Use #[global_allocator] to provide Rust allocator implementation
cfa3bee 
The allocator shim hack we have been using no longer works with
upstream Rust. Replace it with a less-unsupported method: provide a
rust-lang/rust#123015, which still requires
us to provide a few symbol definitions.

Bug: 408221149, 407024458
Change-Id: If1808ca24b12dc80ead35a25521313a3d2e148d5

Cq-Include-Trybots: luci.chromium.try:android-rust-arm32-rel,android-rust-arm64-dbg,android-rust-arm64-rel,linux-rust-x64-dbg,linux-rust-x64-rel,mac-rust-x64-dbg,win-rust-x64-dbg,win-rust-x64-rel
Change-Id: If1808ca24b12dc80ead35a25521313a3d2e148d5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6427855
Reviewed-by: Alan Zhao <[email protected]>
Reviewed-by: Lei Zhang <[email protected]>
Reviewed-by: Łukasz Anforowicz <[email protected]>
Commit-Queue: Collin Baker <[email protected]>
Auto-Submit: Collin Baker <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1442472}
aarongable pushed a commit to chromium/chromium that referenced this issue Apr 3, 2025
Revert "Use #[global_allocator] to provide Rust allocator implementat…
461576c 
…ion"

This reverts commit cfa3bee.

Reason for revert:
LUCI Bisection has identified this change as the culprit of a build failure. See the analysis: https://ci.chromium.org/ui/p/chromium/bisection/compile-analysis/b/8718569842029294465

Sample failed build: https://ci.chromium.org/b/8718569842029294465

If this is a false positive, please report it at http://b.corp.google.com/createIssue?component=1199205&description=Analysis%3A+https%3A%2F%2Fchromium-review.googlesource.com%2Fc%2Fchromium%2Fsrc%2F%2B%2F6427855&format=PLAIN&priority=P3&title=Wrongly+blamed+https%3A%2F%2Fci.chromium.org%2Fui%2Fp%2Fchromium%2Fbisection%2Fcompile-analysis%2Fb%2F8718569842029294465&type=BUG

Original change's description:
> Use #[global_allocator] to provide Rust allocator implementation
>
> The allocator shim hack we have been using no longer works with
> upstream Rust. Replace it with a less-unsupported method: provide a
> rust-lang/rust#123015, which still requires
> us to provide a few symbol definitions.
>
> Bug: 408221149, 407024458
> Change-Id: If1808ca24b12dc80ead35a25521313a3d2e148d5
>
> Cq-Include-Trybots: luci.chromium.try:android-rust-arm32-rel,android-rust-arm64-dbg,android-rust-arm64-rel,linux-rust-x64-dbg,linux-rust-x64-rel,mac-rust-x64-dbg,win-rust-x64-dbg,win-rust-x64-rel
> Change-Id: If1808ca24b12dc80ead35a25521313a3d2e148d5
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6427855
> Reviewed-by: Alan Zhao <[email protected]>
> Reviewed-by: Lei Zhang <[email protected]>
> Reviewed-by: Łukasz Anforowicz <[email protected]>
> Commit-Queue: Collin Baker <[email protected]>
> Auto-Submit: Collin Baker <[email protected]>
> Cr-Commit-Position: refs/heads/main@{#1442472}
>

Bug: 408221149, 407024458
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Change-Id: Iea9e23aa18919381618a761629ff0f9e42e0441b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6432708
Commit-Queue: [email protected] <[email protected]>
Owners-Override: [email protected] <[email protected]>
Bot-Commit: [email protected] <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1442490}
aarongable pushed a commit to chromium/chromium that referenced this issue Apr 4, 2025
@chbaker0
Reland "Use #[global_allocator] to provide Rust allocator implementat…
e3a1797 
…ion"

This is a reland of commit cfa3bee

Original was reverted due to a cronet gn2bp failure. The script
filtered out GN rules in //build/rust/std, but this caused an exception
when //build/rust/std:allocator was referenced later.

Moving the rules to //build/rust/allocator sidesteps the issue.

Original change's description:
> Use #[global_allocator] to provide Rust allocator implementation
>
> The allocator shim hack we have been using no longer works with
> upstream Rust. Replace it with a less-unsupported method: provide a
> rust-lang/rust#123015, which still requires
> us to provide a few symbol definitions.
>
> Bug: 408221149, 407024458
> Change-Id: If1808ca24b12dc80ead35a25521313a3d2e148d5
>
> Cq-Include-Trybots: luci.chromium.try:android-rust-arm32-rel,android-rust-arm64-dbg,android-rust-arm64-rel,linux-rust-x64-dbg,linux-rust-x64-rel,mac-rust-x64-dbg,win-rust-x64-dbg,win-rust-x64-rel
> Change-Id: If1808ca24b12dc80ead35a25521313a3d2e148d5
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6427855
> Reviewed-by: Alan Zhao <[email protected]>
> Reviewed-by: Lei Zhang <[email protected]>
> Reviewed-by: Łukasz Anforowicz <[email protected]>
> Commit-Queue: Collin Baker <[email protected]>
> Auto-Submit: Collin Baker <[email protected]>
> Cr-Commit-Position: refs/heads/main@{#1442472}

Bug: 408221149, 407024458
Cq-Include-Trybots: luci.chromium.try:android-rust-arm32-rel,android-rust-arm64-dbg,android-rust-arm64-rel,linux-rust-x64-dbg,linux-rust-x64-rel,mac-rust-x64-dbg,win-rust-x64-dbg,win-rust-x64-rel
Change-Id: I36fef217297bfe64ae81519be24b8c653f6fdfa1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6432410
Reviewed-by: Mohannad Farrag <[email protected]>
Reviewed-by: Łukasz Anforowicz <[email protected]>
Auto-Submit: Collin Baker <[email protected]>
Commit-Queue: Łukasz Anforowicz <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1442922}
@anforowicz anforowicz mentioned this issue Apr 9, 2025
Closed
3 tasks
@jieyouxu jieyouxu added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Apr 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-allocators Area: Custom and system allocators A-linkage Area: linking into static, shared libraries and binaries C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@riking @Mark-Simulacrum @bjorn3 @jieyouxu