-
Notifications
You must be signed in to change notification settings - Fork 96
Fix some redaction bugs #112
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
Merged
Merged
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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
Oops, something went wrong.
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.
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 we discussed offline, I have no problem with the implementation of an
arg_nameoverride, but it highlights a new issue that seems to underly the need forarg_name, I assume?You changed most (all?) of the fields in your test structs (at least in this commit) to add an underscore to the fields. I'm assuming you did this because you are getting warnings that these fields are
unused?This sounds very related to the problems that we've seen in other Rust code bases after rust-lang/rust#85200 landed. Many downstream structs that depended on
Debugin order to generate logging output (among other things) were forced to either add the leading underscore or add#[allow(unused)]. (Personally, I was not a fan of the code breakage that caused, but the decision-makers felt the cost was worth it.)I'm not sure if that change or some other change broke how
arghworks, but, from what you told me, it looks like the change happened between rustc 1.56 and 1.57.I would like to know if you can track down the origin of the change in 1.57 to see if there is a better, internal workaround in the
arghmacro that could cause the attributed field to get marked "used", and avoid the warning?If that's not feasible, and you feel it's OK to just pass the burden down to the users of
argh, I can buy that argument, but as a workaround, would you consider making the default value ofarg_name(if not supplied) strip the leading underscore, if there is one, so the implicit result is as if the user supplied thearg_namethat way?And if you can do that, is that the only reason to implement an
arg_nameparameter to theargh()attribute? If you have some other good use cases, can you modify your tests to demonstrate a different example, usingarg_namein some useful way other than for stripping the_?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.
Yeah, I updated these fields to be prefixed with
_to silence theunusedwarnings. I'm guessing the source of this was rust-lang/rust#85200, especially since that landed in 1.57.I don't think we have a great way to do that. The problem we're running into is that all these tests are doing is calling
FromArgs::redact_arg_values, which is just using the same argument parser thatFromArgs::from_argsuses, but we don't actually store any of the values in theFromArgsimplementation, so those fields never get used.To avoid the warning, we could change the derived
FromArgs::redact_arg_valuesto parse the arguments and throw them away, but I'm a little hesitant on doing this, since other implementations of FromArgs would observe these calls, and they could have side effects. There'd also be some overhead in doing this, which the optimizer might not be able to get rid of if the impls have side effects.Perhaps a better way of doing this would be to get rid of
FromArgs::redact_arg_values, and replace it withFromArgs::from_args_with_redacted_args(). That function would return the parsed value and the redacted CLI arguments.However, I'm not sure how painful this is going to be in practice. In order to trip over this, users would need to have an impl of
FromArgs, and the only use of it is callingredact_arg_values. I'm struggling to see how users would encounter this outside of testing argh.Sure, I filed #113 to track this. I think we can implement that in a future PR though.
Yeah there are other use cases for
arg_name. I had a test case that used this here: https://github.com/google/argh/pull/112/files#diff-16442fbfe34613b50b21a4a6a5211ed1ff15a68ebba662d38059ca44ce7d1ae2R951There 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.
OK cool. Well, if #113 gets implemented, then most of the
arg_name = ...can (and probably should) be removed, because they would be redundant. So your "my-msg" example might be the only one left behind to demonstrate howarg_namechanges the base behavior.