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

debuginfo: Extraneous descriptions of enum discriminator are emitted #12840

Closed
vadimcn opened this issue Mar 12, 2014 · 6 comments
Closed

debuginfo: Extraneous descriptions of enum discriminator are emitted #12840

vadimcn opened this issue Mar 12, 2014 · 6 comments
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.)

Comments

@vadimcn
Copy link
Contributor

vadimcn commented Mar 12, 2014

This probably isn't a huge deal, but... if one were to examine the output of llvm-dwarfdump for, say, libstd (if compiled with -g flag), you'd find that rustc emits a description of the type of enum discriminator field for each monomorphization of generic enums. For Option alone, there's probably a couple hundred of them.
I think this is unnecessary, because discriminator never depends on enum's type parameters, so all monomorphizations could share the same discriminator description.

Edit: This doesn't apply, of course, to optimized forms of Option, such as Option<&T>, which don't have the discriminator field to begin with.

@thestinger
Copy link
Contributor

It does depend on the type parameters in some cases. The compiler has logic for specialized enum representations.

@vadimcn
Copy link
Contributor Author

vadimcn commented Mar 12, 2014

You are right, I forgot about the pointer Option's. The point still stands, though, for unoptimized forms.

@michaelwoerister
Copy link
Member

I'll look into it.

@michaelwoerister
Copy link
Member

This shouldn't be hard to optimize. Just cache discriminator types with the enums DefId as key.

michaelwoerister added a commit to michaelwoerister/rust that referenced this issue Apr 10, 2014
An optimization for sharing the type metadata of generic enum discriminators between monomorphized instances (fixes issue rust-lang#12840)
alexcrichton pushed a commit to alexcrichton/rust that referenced this issue Apr 10, 2014
An optimization for sharing the type metadata of generic enum discriminators between monomorphized instances (fixes issue rust-lang#12840)
bors added a commit that referenced this issue Apr 10, 2014
Closes #13441 (debuginfo: Fixes and improvements for #12840, #12886, and #13213)
Closes #13433 (Remove references to @trait from a compiler error message)
Closes #13430 (Fix outdated lint warning about inner attribute)
Closes #13425 (Remove a pile of (mainly) internal `~[]` uses)
Closes #13419 (Stop using transmute_mut in RefCell)
Closes #13417 (Remove an unnecessary file `src/libnative/io/p`.)
Closes #13409 (Closing assorted resolve bugs)
Closes #13406 (Generalized the pretty-print entry points to support `-o <file>`.)
Closes #13403 (test: Add a test for #7663)
Closes #13402 (rustdoc: Prune the paths that do not appear in the index.)
Closes #13396 (rustc: Remove absolute rpaths)
Closes #13371 (Rename ast::Purity and ast::Impure Function. Closes #7287)
Closes #13350 (collections: replace all ~[T] with Vec<T>.)
@michaelwoerister
Copy link
Member

This should have been closed automatically with #13441, but wasn't because of PR rollup #13443.

@huonw
Copy link
Member

huonw commented Apr 12, 2014

Thanks @michaelwoerister!

@huonw huonw closed this as completed Apr 12, 2014
fasterthanlime pushed a commit to fasterthanlime/rust that referenced this issue Jul 24, 2022
internal: Use ItemTree for variant, field and module attribute collection in attrs_query

Less parsing = very good, should speed up lang item collection as that basically probes attributes of all enum variants which currently triggers parsing

Not fond of how this is searching for the correct index, ideally we'd map between HIR and item tree Id here but I am not sure how, storing the item tree ids in the HIR version doesn't work due to the usage of `Trace`...
flip1995 pushed a commit to flip1995/rust that referenced this issue Jul 11, 2024
Don't lint `assertions_on_constants` on any const assertions

close rust-lang#12816
close rust-lang#12847
cc rust-lang#12817

----

changelog: Fix false positives in consts for `assertions_on_constants` and `unnecessary_operation`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants