Remove some unused code #50198
Merged
Remove some unused code #50198
Conversation
This file contains 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
|
r? @eddyb (rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
eddyb
reviewed
Apr 24, 2018
| @@ -20,7 +20,7 @@ use std::ops::Neg; | |||
| pub struct DoubleFloat<F>(F, F); | |||
| pub type DoubleDouble = DoubleFloat<ieee::Double>; | |||
|
|
|||
| // These are legacy semantics for the Fallback, inaccrurate implementation of | |||
| // These are legacy semantics for the Fallback, inaccurate implementation of | |||
There was a problem hiding this comment.
There was a problem hiding this comment.
Perhaps it was meant to be ironic... 😏
eddyb
reviewed
Apr 24, 2018
src/librustc_const_math/float.rs
Outdated
| } | ||
|
|
||
| _ => Err(CmpBetweenUnequalTypes), | ||
| _ => None, |
There was a problem hiding this comment.
I don't like this - why not retire ConstFloat instead, and use rustc_apfloat directly in miri? Also, you could use self.try_cmp(*other).ok() in the implementation of partial_ord if you really wanted to
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
eddyb
reviewed
Apr 25, 2018
src/librustc_mir/hair/cx/mod.rs
Outdated
| let parse_float = |num: &str, fty| -> ConstFloat { | ||
| ConstFloat::from_str(num, fty).unwrap_or_else(|_| { | ||
| // FIXME(#31407) this is only necessary because float parsing is buggy | ||
| tcx.sess.span_fatal(sp, "could not evaluate float literal (see issue #31407)"); |
There was a problem hiding this comment.
ups. it's back (luckily we do have a test for that)
|
@oli-obk so |
|
|
eddyb
reviewed
Apr 26, 2018
src/librustc/mir/interpret/error.rs
Outdated
| pub use self::ConstMathErr::*; | ||
|
|
||
| #[derive(Debug, PartialEq, Eq, Clone, RustcEncodable, RustcDecodable)] | ||
| pub enum Op { |
There was a problem hiding this comment.
You can just reuse mir::BinOp and have another variant for negation (just like division by zero has its own variant). Also, you can move these variants to EvalErrorKind.
There was a problem hiding this comment.
BinOp has more variants, so I'd have to reinsert the unreachable! branch or fill out error descriptions for things that'll never happen
There was a problem hiding this comment.
Also the ConstMathErr type is used elsewhere (e.g. mir assertions). Do we really want to allow all possible EvalErrorKinds in mir assertions?
There was a problem hiding this comment.
I guess you could rename ConstMathErr to ArithErr and Op to ArithOp.
There was a problem hiding this comment.
That or just inline Op into the error enum, since I don't think it's used elsewhere (so e.g. AddOverflow).
There was a problem hiding this comment.
I didn't miss these comments, I just wanted to see how far it goes, and simply using EvalErrorKind everywhere makes a lot of code much simpler. Should I undo it and keep ConstMathErr/ArithErr?
There was a problem hiding this comment.
Yeah, just because we can get a simple &str from them, and it's a finite set of things that we can generate builtin panics for. Unleessss we can turn Assert into something we can stash miri errors into! E.g.:
rust/src/librustc/mir/interpret/error.rs
Line 63 in 88cd367
could be used instead of:
Lines 1192 to 1195 in 88cd367
by "simply" having
EvalErrorKind parametrized on some O which would be u64 (by default / everywhere) except in mir::TerminatorKind::Assert where it would be Operand<'tcx>.One downside of it is you have to write MIR visiting code for
EvalErrorKind but it shouldn't be too bad.
There was a problem hiding this comment.
If you don't like that crazy idea, I prefer ArithErr.
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
|
☔ The latest upstream changes (presumably #50228) made this pull request unmergeable. Please resolve the merge conflicts. |
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
eddyb
reviewed
Apr 27, 2018
| @@ -1188,17 +1174,6 @@ impl<'tcx> TerminatorKind<'tcx> { | |||
| } | |||
| } | |||
|
|
|||
| #[derive(Clone, Debug, RustcEncodable, RustcDecodable)] | |||
| pub enum AssertMessage<'tcx> { | |||
There was a problem hiding this comment.
Hmm, can you put Nevermind, terminators are once per block, what am I even thinking.Box around the use of AssertMessage in TerminatorKind::Assert? Just to avoid the memory usage blowup.
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
|
As a side effect, we now even get better errors for div by zero. |
|
☔ The latest upstream changes (presumably #48605) made this pull request unmergeable. Please resolve the merge conflicts. |
eddyb
reviewed
Apr 30, 2018
src/librustc/mir/mod.rs
Outdated
| write!(fmt, "{:?}", "generator resumed after panicking")?; | ||
| } | ||
| } | ||
| write!(fmt, "\"{:?}\"", msg)?; |
There was a problem hiding this comment.
You can combine these write! calls now.
There was a problem hiding this comment.
Also, isn't there a description method? Or fmt::Display impl? Debug seems the wrong thing to put the user-facing message into.
There was a problem hiding this comment.
done & we need debug, because we're recursively printing the Operands, and they were printed with debug printing before.
|
LGTM. If you want to also remove |
|
@bors r=eddyb |
|
📌 Commit 487f7bc has been approved by |
bors
added
S-waiting-on-bors
|
☀️ Test successful - status-appveyor, status-travis |
This was referenced May 1, 2018
eddyb
reviewed
Mar 11, 2021
oli-obk
added a commit
to oli-obk/rust
that referenced
this pull request
Mar 11, 2021
These were removed in rust-lang#50198
JohnTitor
added a commit
to JohnTitor/rust
that referenced
this pull request
Mar 11, 2021
Reintroduce accidentally deleted assertions. These were removed in rust-lang#50198
JohnTitor
added a commit
to JohnTitor/rust
that referenced
this pull request
Mar 11, 2021
Reintroduce accidentally deleted assertions. These were removed in rust-lang#50198
JohnTitor
added a commit
to JohnTitor/rust
that referenced
this pull request
Mar 11, 2021
Reintroduce accidentally deleted assertions. These were removed in rust-lang#50198
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.