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.

Sign up for GitHub

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

Jump to bottom

Make Options::apply fallible #113

Open
wants to merge 5 commits into
base: main
Choose a base branch
from
Open

Make Options::apply fallible #113

wants to merge 5 commits into from

Conversation

BenWiederhake
Copy link
Contributor

This PR shows one way we could make Options::apply fallible.

This feature trivially enables error prioritization, e.g. raising different errors for --a=invalid --b=invalid and --b=invalid --a=invalid, which is what the GNU tools do.

Closes #112

@BenWiederhake BenWiederhake force-pushed the dev-fallible-apply branch 2 times, most recently from 500a487 to c711166 Compare March 29, 2024 13:06
@BenWiederhake
Copy link
Contributor Author

Changes since initial push:

  • Add date example, since this usecase motivated this change.
  • Fix a test in shuf that exposes the same problem I noticed while writing date test: --help exits the entire test runner, thus hiding potential test failures. This is a workaround that needs a proper fix later.
  • Something with clippy changed, it now complains about code I didn't even touch. So I fixed it by adding #[allow(unused)] to a handful of things.

@BenWiederhake
Copy link
Contributor Author

BenWiederhake commented Mar 29, 2024 •
edited
Loading

Changes since last push: cargo fmt 😅

This was referenced Mar 29, 2024
Open
Draft
Open
Open
@BenWiederhake BenWiederhake mentioned this pull request May 6, 2024
Merged
@BenWiederhake
Copy link
Contributor Author

Changes since last push:

@BenWiederhake
Copy link
Contributor Author

Changes since last push:

  • Resolved another trivial conflict (forgot to add the return-type in Settings::apply for the cksum-test)
  • Fixed the date value-prefix logic. (We should make some nicer logic than this, but it's out-of-scope for this PR.)

This was referenced May 9, 2024
Draft
Merged
tertsdiepraam
tertsdiepraam requested changes May 20, 2024
View reviewed changes
Copy link
Member

@tertsdiepraam tertsdiepraam left a comment

Choose a reason for hiding this comment

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

Awesome! My only real issue is with the Value thing I commented on. Once that's resolved: LGTM!

tests/coreutils/date.rs
enum Iso8601Format {
#[default]
#[value("date")]
// TODO: Express the concept "accepts prefixes" more nicely.
Copy link
Member

Choose a reason for hiding this comment

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

I thought I built this into Value already? It's working here for example:

uutils-args/tests/coreutils/ls.rs

Line 480 in a3ecc62

let (s, _operands) = Settings::default().parse(["ls", "--format=acr"]).unwrap();

tests/coreutils/date.rs

impl Options<Arg> for Settings {
fn apply(&mut self, arg: Arg) -> Result<(), uutils_args::Error> {
if self.chosen_format != Format::Unspecified {
Copy link
Member

Choose a reason for hiding this comment

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

So, I take a bit of issue with this example, because I don't like how Unspecified is a special thing that only exists for parsing. Essentially, it comes down to this: #11.

BUT! I don't care enough to block this. We can improve this later and we should move towards shipping this crate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@tertsdiepraam tertsdiepraam tertsdiepraam requested changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Options::apply should permit returning an error
2 participants
@BenWiederhake @tertsdiepraam