Skip to content
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

Fetch miri flags from cargo config #2451

Closed
wants to merge 3 commits into from

Conversation

avrong
Copy link
Contributor

@avrong avrong commented Jul 29, 2022

Closes #2347

This PR introduces cargo config parsing, and in a current implementation uses miri.flags property if there is no MIRIFLAGS env variable present. Maybe the best way to do that is to have some kind of merge of the parameters in both configs, sort of like cargo configs do it by themselves depending on location.

I did not make other tests, nor changed the docs, would be happy to do that if it's better to have them :)
Didn't figure out yet how to make a independent test to check the handling of .cargo/config.toml flags.

@RalfJung
Copy link
Member

Thanks for the PR!

What does cargo do when RUSTFLAGS is set and there are also flags set via config.toml? We should do the same thing.

And yes this should also be documented. :) Tests could be a bit tricky, do you have ideas for that?

@avrong
Copy link
Contributor Author

avrong commented Jul 31, 2022

Regarding RUSTFLAGS, it does the same thing. Exclusively chooses one of the sources in the order.

Thinking of tests, as I understand we can simply test this by making a cargo project where cargo miri would be failing if one of the flags is not present, which we will define in .cargo/config.toml. I see that we can use e.g. some I/O operation such as opening a file and specifying -Zmiri-disable-isolation.

cargo-miri/bin.rs Outdated Show resolved Hide resolved
cargo-miri/bin.rs Outdated Show resolved Hide resolved
cargo-miri/bin.rs Outdated Show resolved Hide resolved
@RalfJung
Copy link
Member

RalfJung commented Aug 2, 2022

Thinking of tests, as I understand we can simply test this by making a cargo project where cargo miri would be failing if one of the flags is not present, which we will define in .cargo/config.toml. I see that we can use e.g. some I/O operation such as opening a file and specifying -Zmiri-disable-isolation.

Our tests for cargo-miri are in test-cargo-miri/run-test.py. cargo miri run in that project needs isolation disabled so I guess you could

  • remove .cargo/config.toml at the beginning of test_cargo_miri_run (just in case of stray files)
  • after the first test, create a .cargo/config.toml that sets isolation`
  • run the test again without MIRIFLAGS, which would then test that the config.toml is honored.
  • clean up .cargo/config.toml again

Copy link
Member

@RalfJung RalfJung left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR. :) I just have some minor nits.

@RalfJung
Copy link
Member

RalfJung commented Aug 3, 2022

@rustbot author
(use @rustbot review when this is ready for review again)

@rustbot rustbot added the S-waiting-on-author Status: Waiting for the PR author to address review comments label Aug 3, 2022
@bors
Copy link
Contributor

bors commented Aug 3, 2022

☔ The latest upstream changes (presumably #2459) made this pull request unmergeable. Please resolve the merge conflicts.

@avrong
Copy link
Contributor Author

avrong commented Aug 4, 2022

@rustbot review

I also added alongside others one test for checking the priority between MIRIFLAGS envar and miri.flags setting in the cargo config.

@rustbot rustbot added S-waiting-on-review Status: Waiting for a review to complete and removed S-waiting-on-author Status: Waiting for the PR author to address review comments labels Aug 4, 2022
@RalfJung
Copy link
Member

RalfJung commented Aug 6, 2022

@rustbot author

@rustbot rustbot added S-waiting-on-author Status: Waiting for the PR author to address review comments and removed S-waiting-on-review Status: Waiting for a review to complete labels Aug 6, 2022
@@ -541,6 +541,27 @@ pub fn phase_runner(mut binary_args: impl Iterator<Item = String>, phase: Runner
}
}

fn get_miriflags() -> Option<Vec<String>> {
// Fetch miri flags from cargo config.
let mut cmd = cargo();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need to do a bit more work here: the user might have passed --config ... to cargo miri run, which would be ignored this way. See get_cargo_metadata for how to forward that. Also they might have set the manifest path, which even get_cargo_metadata gets wrong.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Once #2474 lands there will be a function cargo_extra_flags you can call to get all the flags you need.

However, you can only call that function in phase_cargo_miri; the arguments are lost here in phase_runner. So you'll need to do the flag handling there, and then put the results into an env var that is picked up again in phase_runner.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the "right" way to do that is to have a variable like CARGO_ENCODED_MIRIFLAGS. Then phase_cargo_miri can determine the flags (from either MIRIFLAGS or via the config -- or from CARGO_ENCODED_MIRIFLAGS if that is already set -- and then store the flags losslessly (without spaces causing trouble) into CARGO_ENCODED_MIRIFLAGS here phase_runner can retreive it.

If that's more work than what you signed up for, then storing it into MIRIFLAGS and not supporting spaces within arguments for now would also work.

@@ -90,6 +90,12 @@ def test_no_rebuild(name, cmd, env={}):
fail("Something was being rebuilt when it should not be (or we got no output)");

def test_cargo_miri_run():
# Try to remove cargo config to avoid unexpected settings
try:
os.remove('.cargo/config.toml')
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just realized this seems to edit the same file as

miri/ci.sh

Line 49 in aa53f3f

echo 'build.rustc-wrapper = "thisdoesnotexist"' > .cargo/config.toml
...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh yeah, the path should be absolute here

Copy link
Member

@RalfJung RalfJung Aug 10, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's not what I mean. It can be relative, the other paths in the python file are also relative.

What I mean is that removing that file removes testing the build.rustc-wrapper = "thisdoesnotexist" configuration!

@RalfJung
Copy link
Member

@avrong we haven't heard from you in a while; what is the status of this PR?

@avrong
Copy link
Contributor Author

avrong commented Sep 22, 2022

@RalfJung sorry for a long delay. Will be looking at this again soon

@RalfJung
Copy link
Member

@avrong I'm going to close this due to inactivity, but feel free to pick it up again any time!

@RalfJung RalfJung closed this Oct 26, 2022
@badumbatish
Copy link

i'll study the PR and initial issue on this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: Waiting for the PR author to address review comments
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Set MIRIFLAGS from .cargo/config.toml
5 participants