Skip to content

use real vtable type in the trait object representation #11915

New issue

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

#

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

Already on GitHub? # to your account

Jump to bottom
Closed
thestinger opened this issue Jan 29, 2014 · 4 comments
Closed

use real vtable type in the trait object representation #11915

thestinger opened this issue Jan 29, 2014 · 4 comments
Labels
A-trait-system Area: Trait system I-slow Issue: Problems and improvements with respect to performance of generated code.

Comments

@thestinger
Copy link
Contributor

There's no reason to be casting to and from an opaque type as it confuses LLVM and breaks devirtualization and other optimizations. I think it will involve some pain to have trans::meth spit out the vtable type without generating one though.
@thestinger thestinger mentioned this issue Jan 30, 2014
Merged
@reem
Copy link
Contributor

reem commented Sep 15, 2014

Triage: This would be nice for downstream users of TraitObject who want to create type-erased data structures by keeping the vtable inline etc.

@steveklabnik
Copy link
Member

Triage: no change. TraitObject still looks like

pub struct TraitObject {
    pub data: *mut (),
    pub vtable: *mut (),
}

@steveklabnik steveklabnik added the A-trait-system Area: Trait system label Sep 3, 2015
@steveklabnik
Copy link
Member

Triage: no real changes here, and I'm not aware of any plans to. Given no real comments since 2014, I'm going to give this one a close, as I don't think it's likely to ever be prioritized.

If anyone feels passionate about changing this, ping @rust-lang/compiler to see if they think it's still viable.

@eddyb
Copy link
Member

eddyb commented Mar 1, 2017

This has nothing to do with TraitObject, although I'm not sure LLVM is limited by this anymore.

@tmandry tmandry mentioned this issue Jan 15, 2020
Open
flip1995 pushed a commit to flip1995/rust that referenced this issue Feb 20, 2025
@llogiq
Handle more cases in is_normalizable (rust-lang#13833)
f6d23c8 
By assuming that a recursive type is normalizable within the deeper
calls to `is_normalizable_helper()`, more cases can be handled by this
function.

In order to fix stack overflows, a recursion limit has also been added
for recursive generic type instantiations.

Fix rust-lang#9798
Fix rust-lang#10508
Fix rust-lang#11915

changelog: [`large_enum_variant`]: more precise detection of variants
with large size differences
# for free to join this conversation on GitHub. Already have an account? # to comment
Assignees
No one assigned
Labels
A-trait-system Area: Trait system I-slow Issue: Problems and improvements with respect to performance of generated code.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@steveklabnik @eddyb @thestinger @reem