cc @lcnr @eddyb
We sometimes have super verbose things in MIR like
assert(const true, "index out of bounds: the len is {} but the index is {}", const 4_usize, const 2_usize) -> bb1; // scope 0 at $DIR/array_index.rs:5:18: 5:33
// ty::Const
// + ty: bool
// + val: Value(Scalar(0x01))
// mir::Constant
// + span: $DIR/array_index.rs:5:18: 5:33
// + literal: Const { ty: bool, val: Value(Scalar(0x01)) }
// ty::Const
// + ty: usize
// + val: Value(Scalar(0x0000000000000004))
// mir::Constant
// + span: $DIR/array_index.rs:5:18: 5:33
// + literal: Const { ty: usize, val: Value(Scalar(0x0000000000000004)) }
// ty::Const
// + ty: usize
// + val: Value(Scalar(0x0000000000000002))
// mir::Constant
// + span: $DIR/array_index.rs:5:18: 5:33
// + literal: Const { ty: usize, val: Value(Scalar(0x0000000000000002)) }
These constants give no useful additional information, as everything is already contained in the mir terminator. I think we could start out with just not printing these statements if the type is an integer, bool or char, which should cover most use cases. A more complex analysis could later look at constant in more detail and decide whether the verbose printing could be helpful.
I'd like to try this.
ooh, sorry, evanrichter (idk their github handle) is working on it already since yesterday.
@mglagla we can work together if you want, as I'm new to rustc dev. would you like to claim by saying @rustbot claim?
@evanrichter No, it's alright, I merely wanted to test if I could find the relevant part of code to edit and I did. I only would make a pull request if nobody worked on this already.
@mglagla sounds like you are ahead of me and I am busy this week. If the issue is still available next week I'll claim it
@evanrichter do think you'll have time to work on this?
@xldenis not until Wednesday at least
Hey guys, sorry to snipe this - there hadn't been any activity in a few weeks so I had a go at fixing this.
@oli-obk I've implemented your suggestion in the linked PR. One note though is that your post above did not specify if we should suppress only ty::Const messages, only mir::Constant messages, or both. My change removes them both for the types you listed, but I could see why we'd want to keep mir::Constant messages. I'm not familiar enough with the project to know what people would prefer, I'm happy to change it to what you think is best.
My commit landed just over a week ago, we should be able to close this issue.
Most helpful comment
Hey guys, sorry to snipe this - there hadn't been any activity in a few weeks so I had a go at fixing this.
@oli-obk I've implemented your suggestion in the linked PR. One note though is that your post above did not specify if we should suppress only
ty::Constmessages, onlymir::Constantmessages, or both. My change removes them both for the types you listed, but I could see why we'd want to keepmir::Constantmessages. I'm not familiar enough with the project to know what people would prefer, I'm happy to change it to what you think is best.