Merged
Conversation
Contributor
|
r? @eddyb (rust_highfive has picked a reviewer for you, use r? to override) |
eddyb
reviewed
Apr 24, 2018
src/librustc_apfloat/ppc.rs
Outdated
Member
There was a problem hiding this comment.
Contributor
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
Member
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
Contributor
|
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
Contributor
Author
There was a problem hiding this comment.
ups. it's back (luckily we do have a test for that)
Member
|
@oli-obk so |
Contributor
Author
|
|
eddyb
reviewed
Apr 26, 2018
src/librustc/mir/interpret/error.rs
Outdated
Member
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.
Contributor
Author
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
Contributor
Author
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?
Member
There was a problem hiding this comment.
I guess you could rename ConstMathErr to ArithErr and Op to ArithOp.
Member
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).
Contributor
Author
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?
Member
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.
Member
There was a problem hiding this comment.
If you don't like that crazy idea, I prefer ArithErr.
Contributor
|
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 |
Collaborator
|
☔ The latest upstream changes (presumably #50228) made this pull request unmergeable. Please resolve the merge conflicts. |
Contributor
|
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
src/librustc/mir/mod.rs
Outdated
Member
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.
Contributor
|
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 |
Contributor
Author
|
As a side effect, we now even get better errors for div by zero. |
Collaborator
|
☔ 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)?; |
Member
There was a problem hiding this comment.
You can combine these write! calls now.
Member
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.
Contributor
Author
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.
Member
|
LGTM. If you want to also remove |
Contributor
Author
|
@bors r=eddyb |
Collaborator
|
📌 Commit 487f7bc has been approved by |
Collaborator
Collaborator
|
☀️ 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
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
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.