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.
Added sanity check to to catch empty
host
parameter in./x.py test --host=''
#107858New 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
Added sanity check to to catch empty
host
parameter in./x.py test --host=''
#107858Changes from 3 commits
755ea9f
62f67bf
0118a8b
a874d7d
89b37c9
707e11f
48f755e
8491691
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 error message seems to believe that this can only happen if we have hosts as an empty parameter, but I'm not convinced by skimming the code above that's the only way to hit this. Can we document the rationale for that conclusion in a comment, plus why we don't validate host='' at flag parsing time?
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.
As far as I understand, there are three cases:
./x.py
is invoked with nohost
parameter. This will make the host value default to this machine../x.py
is invoked with an explicitely set emptyhost
parameter, but also an explicitely set non-emptytarget
parameter. This will set the host value to the target value../x.py
is invoked with an explicitely set emptyhost
parameter and notarget
parameter.Case 3 is what we are fixing here. I think I achieved this by the check on line 294. This also takes case 1 and 2 into consideration and does not treat those as bad cases.
When is that - or where is that? :)
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.
Flag parsing is in flags.rs and config.rs, I believe. (Maybe we can put this check there, but I suspect that it's not that simple - it is sometimes valid to pass --host with an empty string. Not 100% confident about that 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.
Would you mind us keeping this check here ? This fixes the issue at hand and is tied together with the other logic of testing for empty host and target parameters.
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 am still not following the logic here, or exactly why you think this code specifically targets the case you mention. But the code here (https://github.com/rust-lang/rust/blob/master/src/bootstrap/config.rs#L1005) seems like it's able to directly detect that we're setting host + target to empty sets and error based on that.
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 would rather have it there, I can try to look into that. It was just mentioned in the issue ( #77906 ) that this would be the spot to fix it. And now it is fixed there.
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'm not sure why @jyn514 suggested fixing #77906 here. It seems to me that if a fix is necessary at all, we would want to fix this in a more general manner -- for example, if nothing is run, we error rather than saying "all is successful", without trying to determine why nothing was run (e.g., exclude rules excluding all targets, etc.)
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 know why this place in the code was picked, but to me it seems like a fine place. We can check what we need to check, emit errors with a return code 1 and it fits some of the other checks that is being done here (and could be done). But how do we determine this? This is my second pull request for this project, so I don't imagine my opinion matters too much.
I am not sure I understand this. If nothing is run due to empty host or exclude rules or something third, I think it is important to tell the user that the build was unsuccessful and tell them why. The why is important because that gives them a path forward - a way to fix the issue. Do we disagree on this?
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 think we agree that providing arguments that lead to a no-op build necessarily should error, but it doesn't seem bad to error in that case. Regardless, this PR is giving a very specific error message about providing empty hosts but isn't touching the code in a way that I can quickly say "that is the only way to reach this error message". Telling the user that they have empty hosts when that may not be the case is very confusing, and I cannot easily follow the conditions to in fact confirm that is the case for this error.