-
Notifications
You must be signed in to change notification settings - Fork 34
WIP: rustfix-mode flag
#353
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
base: main
Are you sure you want to change the base?
Conversation
|
Hmm. If you want to try out one specific example without running the entire test suite, you can also cd into the test directory and use cargo test there. I think you'll mostly need to override global_rustfix if there is a per test mode set. You can look how the no-rustfix flag is propagated to this location |
To make that concrete, I should be able to do the following? cd tests/integrations/basic
cargo testWill doing that check the
To be honest, I am having trouble figuring out the "propagation" part. When I grepped for Lines 196 to 201 in 2a32015
As such, is this where you would expect the |
| _ => *self, | ||
| }; | ||
| let output = output.clone(); | ||
| let no_run_rustfix = config.find_one_custom("no-rustfix")?; |
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.
This is how the value is loaded.
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.
When this function is entered, *self is already set to some RustfixMode. Should it be obvious to me how *self was determined?
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.
Oh I forgot this was how it's done. See my other comment for what's happening
| eprintln!("{}", std::backtrace::Backtrace::force_capture()); | ||
| match args.content.parse::<RustfixMode>() { | ||
| Ok(mode) => { | ||
| parser.set_custom_once("rustfix-mode", mode, span); |
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 set rustfix instead of rustfix-mode the other rustfix flag (line 158) gets overridden if the flag is set instead of both of the flags getting run
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.
Just to be clear, this rustflix flag?
Lines 156 to 158 in 2a32015
| comment_defaults | |
| .base() | |
| .add_custom("rustfix", RustfixMode::MachineApplicable); |
Could you point me to where that flag is checked?
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.
Flags are automatically handled. I'd need to look it up but likely you can grep for Box<dyn Flag>
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.
Flags are automatically handled. I'd need to look it up but likely you can grep for Box
I apologize. I am genuinely trying to understand what is going on here. But automatically handled by what? ui_test or something else?
If I grep for Box, I get 123 hits. Grepping for Box::new reduces that to 54. But is there anything more specific I could look for?
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.
Oh lmao sorry. Github ate the generic params because it thought they are HTML. Edited
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.
@oli-obk Can I just confirm that this is how you want/expect ui_test to work? I'm just asking because I don't think I've seen a .fixed file with a $HASH annotation before.
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 think you should use the $HASH in Cargo.stdout files, such as the one you linked.
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.
Thanks, @kirtchev-adacore. My question to @oli-obk stands, though.
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.
@oli-obk Can I just confirm that this is how you want/expect
ui_testto work? I'm just asking because I don't think I've seen a.fixedfile with a$HASHannotation before.
Well, I like dumping lots of info normally to users, so printing the command somewhere is useful. Not sure the current style is the thing I want long term, but just replacing output hashes with $HASH is what I do whenever it shows up in stdout/stderr.
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.
Thanks for your suggestion, @kirtchev-adacore. I pushed that change. I think there may still be some non-determinism in the ordering of the fields, though. For example, I see this in the diff between the previous version and the one I just pushed:
Regardless, I suspect this is tangential to my real problem: I cannot tell whether the .fixed files are being generated and checked. I wish there was an easy way to make that determination.
I will update the below once the branch works.
TODO (check if already done)