- 
                Notifications
    You must be signed in to change notification settings 
- Fork 13.9k
Remove some unused code #50198
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 some unused code #50198
Conversation
| r? @eddyb (rust_highfive has picked a reviewer for you, use r? to override) | 
        
          
                src/librustc_apfloat/ppc.rs
              
                Outdated
          
        
      There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps it was meant to be ironic... 😏
        
          
                src/librustc_const_math/float.rs
              
                Outdated
          
        
      There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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  | 
        
          
                src/librustc_mir/hair/cx/mod.rs
              
                Outdated
          
        
      There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where did this ICE go?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ups. it's back (luckily we do have a test for that)
| @oli-obk so  | 
| 
 | 
        
          
                src/librustc/mir/interpret/error.rs
              
                Outdated
          
        
      There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess you could rename ConstMathErr to ArithErr and Op to ArithOp.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
| ArrayIndexOutOfBounds(Span, u64, u64), | 
could be used instead of:
Lines 1192 to 1195 in 88cd367
| BoundsCheck { | |
| len: Operand<'tcx>, | |
| index: Operand<'tcx> | |
| }, | 
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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  | 
        
          
                src/librustc/mir/mod.rs
              
                Outdated
          
        
      There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. | 
        
          
                src/librustc/mir/mod.rs
              
                Outdated
          
        
      | write!(fmt, "{:?}", "generator resumed after panicking")?; | ||
| } | ||
| } | ||
| write!(fmt, "\"{:?}\"", msg)?; | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can combine these write! calls now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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  | 
| ☀️ Test successful - status-appveyor, status-travis | 
These were removed in rust-lang#50198
Reintroduce accidentally deleted assertions. These were removed in rust-lang#50198
Reintroduce accidentally deleted assertions. These were removed in rust-lang#50198
Reintroduce accidentally deleted assertions. These were removed in rust-lang#50198
No description provided.