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

Disable automatic inlining of resource dtors and other things #2177

Closed
nikomatsakis opened this issue Apr 9, 2012 · 4 comments
Closed

Disable automatic inlining of resource dtors and other things #2177

nikomatsakis opened this issue Apr 9, 2012 · 4 comments
Labels
A-codegen Area: Code generation A-linkage Area: linking into static, shared libraries and binaries

Comments

@nikomatsakis
Copy link
Contributor

Right now, resource destructors seem to always be inlined. This recently led to #2170 because the reachability map was incorrect. I fixed this the wrong way: by marking all resource bodies as reachable. The right fix seems to me to be not inlining resource bodies by default, but that change seemed a bit more involved. In particular, I wanted to check with @marijnh whether resources are being inlined intentionally? If so, is there a deep reason for that?

In general I'd like to be able to say that "no user-specified code is inlined unless either generic or marked #[inline]".

@ghost ghost assigned marijnh Apr 12, 2012
@marijnh
Copy link
Contributor

marijnh commented Apr 16, 2012

There was no deep reason for this. Embarrassingly, I think it was an accident. I agree it should be changed.

@nikomatsakis
Copy link
Contributor Author

One other, related, thing: right now, we always inline generic functions. I think the original plan was to having generic functions only be inlined if they were tagged #[inline]. In the event that you made a cross-crate call to non-inlined generic function, the call would only be permitted the generic types were bound to box types (or something like that). Then, for all exported generic functions, we would make sure to export a version that operates on box types.

@marijnh
Copy link
Contributor

marijnh commented Apr 16, 2012

I don't think that adds much, beyond the annoying need to specify all exported generics as #[inline]. Yes, you'd have some check on implicit code duplication, but I don't believe implicit code duplication is a big enough problem to warrant such a heavy measure.

@nikomatsakis
Copy link
Contributor Author

I'm not sure. I think the goal was to make the model of what code is
inlined simple to describe: "those things marked with #[inline]". But
maybe it's better to have the model be "generic things or things that are
marked #[inline]". You can always create monomorphic wrappers if you'd
prefer.

bors added a commit to rust-lang-ci/rust that referenced this issue Sep 22, 2022
…test, r=RalfJung

add test for backtrace with global allocator

closes rust-lang#1996
Kobzol pushed a commit to Kobzol/rust that referenced this issue Dec 30, 2024
Kobzol pushed a commit to Kobzol/rust that referenced this issue Dec 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-codegen Area: Code generation A-linkage Area: linking into static, shared libraries and binaries
Projects
None yet
Development

No branches or pull requests

2 participants