Make pretty printing for f16 and f128 consistent by tgross35 · Pull Request #126654 · rust-lang/rust (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation6 Commits1 Checks6 Files changed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
Currently the docs show e.g.
{transmute(0xfffeffffffffffffffffffffffffffff): f128}
for f128 constants. This should fix that to instead use apfloat for printing, as is done for f32 and f64.
r? @jackh726
rustbot has assigned @jackh726.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.
Use r? to explicitly pick a reviewer
Status: Awaiting review from the assignee but also interested parties.
Relevant to the compiler team, which will review and decide on the PR/issue.
labels
Currently the docs show e.g.
{transmute(0xfffeffffffffffffffffffffffffffff): f128}for f128 constants. This should fix that to instead use apfloat for
printing, as is done for f32 and f64.
Change pretty printing for Make pretty printing for f16 and f128 to be consistentf16 and f128 consistent
📌 Commit 1299aef has been approved by jackh726
It is now in the queue for this repository.
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
fmease added a commit to fmease/rust that referenced this pull request
…jackh726
Make pretty printing for f16 and f128 consistent
Currently the docs show e.g.
{transmute(0xfffeffffffffffffffffffffffffffff): f128}for f128 constants. This should fix that to instead use apfloat for printing, as is done for f32 and f64.
This was referenced
Jun 19, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request
Rollup of 7 pull requests
Successful merges:
- rust-lang#123782 (Test that opaque types can't have themselves as a hidden type with incompatible lifetimes)
- rust-lang#124580 (Suggest removing unused tuple fields if they are the last fields)
- rust-lang#125787 (Migrate
bin-emit-no-symbolsrun-maketest tormake) - rust-lang#126553 (match lowering: expand or-candidates mixed with candidates above)
- rust-lang#126594 (Make async drop code more consistent with regular drop code)
- rust-lang#126654 (Make pretty printing for
f16andf128consistent) - rust-lang#126656 (rustc_type_ir: Omit some struct fields from Debug output)
r? @ghost
@rustbot modify labels: rollup
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request
Rollup merge of rust-lang#126654 - tgross35:f16-f128-pretty-print, r=jackh726
Make pretty printing for f16 and f128 consistent
Currently the docs show e.g.
{transmute(0xfffeffffffffffffffffffffffffffff): f128}for f128 constants. This should fix that to instead use apfloat for printing, as is done for f32 and f64.
| @@ -1710,6 +1710,10 @@ pub trait PrettyPrinter<'tcx>: Printer<'tcx> + fmt::Write { |
|---|
| ty::Bool if int == ScalarInt::FALSE => p!("false"), |
| ty::Bool if int == ScalarInt::TRUE => p!("true"), |
| // Float |
| ty::Float(ty::FloatTy::F16) => { |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be made a nested match so we get exhaustiveness checking?
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Labels
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Relevant to the compiler team, which will review and decide on the PR/issue.