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

rustc: allow "omitting" visit glue. #11793

Closed
wants to merge 1 commit into from

Conversation

huonw
Copy link
Member

@huonw huonw commented Jan 25, 2014

This adds -Z noop-reflection which causes all visit glues to be
empty. As an example of its effects, an optimised libsyntax.so is 300
KB (5%) smaller and requires 14MB less memory to compile.

This is likely most useful for #[no_std] crates using closures or trait
objects (which require a tydesc to be created for their contained types)
to avoid the code bloat of the otherwise unused visit glue.

This adds `-Z noop-reflection` which causes all visit glues to be
empty. As an example of its effects, an optimised libsyntax.so is 300
KB (5%) smaller and requires 14MB less memory to compile.

This is likely most useful for #[no_std] crates using closures or trait
objects (which require a tydesc to be created for their contained types)
to avoid the code bloat of the otherwise unused visit glue.
@thestinger
Copy link
Contributor

Although I really hate visit glue, I would prefer fixing the root cause by removing the TyDesc from closures and trait objects and storing a destructor pointer directly instead for proc and ~Trait. I don't think it would be incredibly hard to switch to that.

@thestinger
Copy link
Contributor

There are definitely a few explicit uses of visit glue in libsyntax.

@alexcrichton
Copy link
Member

I also fear that this may not be the best solution for this problem. My biggest concern is that you can't retroactively go back and remove visit glue from libraries you're linking to (you'd have to recompile them). For example the no-landing-pads option will retroactively modify code when performing LTO, which isn't great because it only runs on LTO, but it's at least possible.

I feel like the general usage pattern of {:?} is that for executables it's fine, but for libraries it should be easy to use during development but hard to deploy in a release build of the library.

Regardless, I'd be curious to get some more opinions on this.

@pcwalton
Copy link
Contributor

I think #[deriving(Format)] may be a reasonable replacement for visit glue, and we should just remove it entirely. Regardless I think @thestinger's suggestion should be as a followup after this patch, if at all. (Being able to fetch size and align is awfully useful and we should discuss whether we'll regret removing that ability.)

cc @nikomatsakis, who has been having similar thoughts.

@huonw
Copy link
Member Author

huonw commented Jan 26, 2014

I'm happy to work on #[deriving(Format)] (and the removal of the visit glue, if that's deemed the appropriate course).

@alexcrichton
Copy link
Member

We have previously decided to rename fmt::Default to fmt::Show and then we'd have deriving(Show). The only current work in this area is #11298, so I think that as long as you talk to @bjz, you're more than welcome to take over that work!

@alexcrichton
Copy link
Member

We decided in today's meeting that this isn't quite the strategy that we'd like to pursue.

We definitely think that visit glue is leading to codegen/compile-time problems, but for now we shouldn't be omitting it like this. We're debating the idea of removing :?, but we all agree that no action should be taken until deriving(Show) is an option.

bors added a commit to rust-lang-ci/rust that referenced this pull request Dec 1, 2023
teach `eager_or_lazy` about panicky arithmetic operations

Fixes rust-lang#9422
Fixes rust-lang#9814
Fixes rust-lang#11793

It's a bit sad that we have to do this because arithmetic operations seemed to me like the prime example where a closure would not be necessary, but this has "side effects" (changes behavior when going from lazy to eager) as some of these panic on overflow/underflow if compiled with `-Coverflow-checks` (which is the default in debug mode).
Given the number of backlinks in the mentioned issues, this seems to be a FP that is worth fixing, probably.

changelog: [`unnecessary_lazy_evaluations`]: don't lint if closure has panicky arithmetic operations
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants