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

remove type_use #9538

Merged
merged 1 commit into from
Sep 27, 2013
Merged

remove type_use #9538

merged 1 commit into from
Sep 27, 2013

Conversation

thestinger
Copy link
Contributor

This is broken, and results in poor performance due to the undefined
behaviour in the LLVM IR. LLVM's mergefunc is a much better way of
doing this since it merges based on the equality of the bytecode.

For example, consider std::repr. It generates different code per
type, but is not included in the type bounds of generics.

The mergefunc pass works for most of our code but currently hits an
assert on libstd. It is receiving attention upstream so it will be
ready soon, but I don't think removing this broken code should wait any
longer. I've opened #9536 about enabling it by default.

Closes #8651
Closes #3547
Closes #2537
Closes #6971
Closes #9222

This is broken, and results in poor performance due to the undefined
behaviour in the LLVM IR. LLVM's `mergefunc` is a *much* better way of
doing this since it merges based on the equality of the bytecode.

For example, consider `std::repr`. It generates different code per
type, but is not included in the type bounds of generics.

The `mergefunc` pass works for most of our code but currently hits an
assert on libstd. It is receiving attention upstream so it will be
ready soon, but I don't think removing this broken code should wait any
longer. I've opened #9536 about enabling it by default.

Closes #8651
Closes #3547
Closes #2537
Closes #6971
Closes #9222
bors added a commit that referenced this pull request Sep 27, 2013
This is broken, and results in poor performance due to the undefined
behaviour in the LLVM IR. LLVM's `mergefunc` is a *much* better way of
doing this since it merges based on the equality of the bytecode.

For example, consider `std::repr`. It generates different code per
type, but is not included in the type bounds of generics.

The `mergefunc` pass works for most of our code but currently hits an
assert on libstd. It is receiving attention upstream so it will be
ready soon, but I don't think removing this broken code should wait any
longer. I've opened #9536 about enabling it by default.

Closes #8651
Closes #3547
Closes #2537
Closes #6971
Closes #9222
@bors bors closed this Sep 27, 2013
@bors bors merged commit c3e4e06 into rust-lang:master Sep 27, 2013
@thestinger thestinger deleted the type_use branch October 1, 2013 05:46
flip1995 pushed a commit to flip1995/rust that referenced this pull request Nov 21, 2022
`result_large_err` show largest variants in err msg

fixes rust-lang#9538

changelog: Sugg: [`result_large_err`]: Now show largest enum variants in error message
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants