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

Use .name_str() to format primitive types in error messages #85187

Merged
merged 2 commits into from
May 12, 2021

Conversation

FabianWolff
Copy link
Contributor

This pull request fixes #84976. The problem described there is caused by this code

IntMismatch(ref values) => {
write!(f, "expected `{:?}`, found `{:?}`", values.expected, values.found)
}
FloatMismatch(ref values) => {
write!(f, "expected `{:?}`, found `{:?}`", values.expected, values.found)
}

using Debug formatting ({:?}), while the proper solution is to call name_str() of ty::IntTy, ty::UintTy and ty::FloatTy, respectively.

@rust-highfive
Copy link
Collaborator

r? @jackh726

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 11, 2021
ty::IntVarValue::IntType(ty) => ty.name_str(),
ty::IntVarValue::UintType(ty) => ty.name_str(),
};
write!(f, "expected `{}`, found `{}`", expected, found)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does the Display output not just call write u32/i32?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If not, that's fine. That's what I would expect.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no Display implementation for IntType, UintType etc., only a derived Debug implementation that causes the wrong formatting observed in #84976 (U32 instead of u32 etc.).

@@ -0,0 +1,21 @@
fn foo(length: &u32) -> i32 {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Maybe add a short comment here on what this test is for?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@jackh726
Copy link
Member

@bors r+ rollup

@bors
Copy link
Contributor

bors commented May 11, 2021

📌 Commit 69a4ae2 has been approved by jackh726

@bors bors added S-waiting-on-bors 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 May 11, 2021
bors added a commit to rust-lang-ci/rust that referenced this pull request May 11, 2021
Rollup of 8 pull requests

Successful merges:

 - rust-lang#83501 (rustdoc: Add unstable CLI option to show basic type layout information)
 - rust-lang#85018 (shrinking the deprecated method span)
 - rust-lang#85124 (rustdoc: remove explicit boolean comparisons.)
 - rust-lang#85136 (Change param name (k to key and v to value) in std::env module)
 - rust-lang#85162 (Fix typo in variable name)
 - rust-lang#85187 (Use .name_str() to format primitive types in error messages)
 - rust-lang#85191 (Improve rustdoc gui tester)
 - rust-lang#85196 (Revert "Auto merge of rust-lang#84797 - richkadel:cover-unreachable-statements…)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit c4c654f into rust-lang:master May 12, 2021
@rustbot rustbot added this to the 1.54.0 milestone May 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Mismatched integer types with a block causes an error with incorrect names of types
5 participants