Repository navigation
asm const ptr: move name generation to asm-specific logic - #164808
Open
folkertdev wants to merge 2 commits into
Open
folkertdev wants to merge 2 commits into
folkertdev wants to merge 2 commits into
Conversation
Instead of putting it into the generic `alloc_to_backend` function.
Contributor
Author
|
r? @Amanieu |
Member
|
@bors r+ |
Contributor
Zalathar
added a commit
to Zalathar/rust
that referenced
this pull request
Nov 13, 2026
…, r=Amanieu asm const ptr: move name generation to asm-specific logic tracking issue: rust-lang#128464 I'm trying to make a fix for rust-lang#164774, and this name generation gets in the way. So, move the logic needed to give constants that are passed to global assembly a globally unique name out of the generic helper, and into asm-specific logic instead. LLVM `Value`s are deduplicated so we need to prevent generating a globally unique name for the same value multiple times. So, I added a small cache. A benefit is that we also deduplicate LLVM constants now, compare the added test versus https://godbolt.org/z/1ajW19hdT. r? codegen cc @nbdd0121
Zalathar
added a commit
to Zalathar/rust
that referenced
this pull request
Nov 13, 2026
Add a `!type` annotation to a vtable for every supertrait that is a prefix of the vtable tracking issue: rust-lang#68262 This fixes a miscompilation where a vtable was incorrectly eliminated because it was only used by a supertrait. In https://godbolt.org/z/8TE1WMvac, `call_super` could be applied to both `A` and `B`, but it incorrectly just always calls the `B` method. The vtable for A has been eliminated. The fix here only works for the first supertrait in the list, or later ones if they have no methods. So in `trait Foo: A + B`, there is still a bug when B actually has methods (and its vtable is not a prefix of `Foo`s vtable). In that case the vtable for `B` does not get any `!type` annotations, which provides incomplete information to VFE and it may therefore miscompile. That needs some further refactoring, which is blocked on rust-lang#164808. Best reviewed commit-by-commit.
rust-bors Bot
pushed a commit
that referenced
this pull request
Nov 13, 2026
Rollup of 17 pull requests Successful merges: - #160618 (require a consistent codegen backend when -Zllvm-target-feature is present) - #164043 (alloc: Unstably add `Vec::repeat` and `Vec::repeat_in`) - #164808 (asm const ptr: move name generation to asm-specific logic) - #164823 (Use `DerefMut` and `IndexMut` before `&raw mut` autoborrow) - #165475 (Add a `!type` annotation to a vtable for every supertrait that is a prefix of the vtable) - #165568 (rustdoc: Suggest corrections for reference label typos) - #165924 (rustc_codegen_gcc subtree update 2026-11-13) - #165927 (Remove `const_struct` from `rustc_codegen_ssa`) - #164362 (Emit note for `non_exhaustive` within defining crate for `unreachable_patterns`) - #164997 (Fix as str suggestion in subpattern) - #165825 (make `Complex<x87_f80>` ABI-compatible with C) - #165868 (Small changes to dyn compatibility) - #165879 (Add `#[rustc_test_entrypoint_marker]` back !) - #165903 (Fix borrowck ICE when a borrow outlives a local in a const block) - #165914 (Use `trim_prefix` in bootstrap) - #165919 (tests: accept better behavior on underaligned accesses) - #165936 (Enhance documentation for try_clone File implementation)
Member
@bors r- |
Contributor
|
This pull request was unapproved. This PR was contained in a rollup (#165944), which was unapproved. |
Zalathar
added a commit
to Zalathar/rust
that referenced
this pull request
Nov 14, 2026
Add a `!type` annotation to a vtable for every supertrait that is a prefix of the vtable tracking issue: rust-lang#68262 This fixes a miscompilation where a vtable was incorrectly eliminated because it was only used by a supertrait. In https://godbolt.org/z/8TE1WMvac, `call_super` could be applied to both `A` and `B`, but it incorrectly just always calls the `B` method. The vtable for A has been eliminated. The fix here only works for the first supertrait in the list, or later ones if they have no methods. So in `trait Foo: A + B`, there is still a bug when B actually has methods (and its vtable is not a prefix of `Foo`s vtable). In that case the vtable for `B` does not get any `!type` annotations, which provides incomplete information to VFE and it may therefore miscompile. That needs some further refactoring, which is blocked on rust-lang#164808. Best reviewed commit-by-commit.
This branch has not been deployed
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
tracking issue: #128464
I'm trying to make a fix for #164774, and this name generation gets in the way.
So, move the logic needed to give constants that are passed to global assembly a globally unique name out of the generic helper, and into asm-specific logic instead.
LLVM
Values are deduplicated so we need to prevent generating a globally unique name for the same value multiple times. So, I added a small cache. A benefit is that we also deduplicate LLVM constants now, compare the added test versus https://godbolt.org/z/1ajW19hdT.r? codegen
cc @nbdd0121