TypedValueParser cannot parse/validate an OsStr with full error context

[kpreid]

Please complete the following tasks

• I have searched the discussions
• I have searched the open and rejected issues

Clap Version

4.0.11 (and also 3.2)

Describe your use case

There seems to be no way to simultaneously:

• run custom parsing or validation code on an argument (via value_parser = ...),
• accept OsStr input (non-UTF-8) rather than str, and
• produce errors with context information identifying the erroneous value etc.

There is an implementation of TypedValueParser for functions which adds context for the error but it only accepts &str input, and if one is writing one's own impl TypedValueParser for … then it is not possible to access the Error operations to add context. The documentation recommends Command::error(), but that takes a mutable Command which is not available from within a TypedValueParser.

Describe the solution you'd like

It should be possible to construct a clap::Error, while implementing a parser, that has all the usual context.

Alternatives, if applicable

A second implementation for functions that take &OsStr would work, but does not seem an ideal solution to me since it doesn't allow composing TypedValueParsers.

Additional Context

In previous discussion, epage wrote:

But we should also support people writing their own value parsers and this is a bug hole for it. Can you create an issue?

No one filed that issue yet, so I am now. (Another discussion post.)

[kpreid]

(I think this should be labeled a bug rather than an enhancement, since it's functionality that existed in clap 3, but the "enhancement" issue template was more fitting for what there was to say about it.)

[epage]

For anyone else reading this, I would recommend double checking if you need to implement TypedValueParser. Too frequently people immediately jump to implementing it when that is the harder and more verbose route

Current alternatives:

• Any Fn(&str) -> Result<T, E> already implements it
• value_parser! can adapt types that implement FromStr, From<&str>, From<String>, From<&OsStr> and From<OsString>
• You can take existing TypedValueParsers and call TypedValueParser::map on them

[epage]

@kpreid could you expand on your use case? I'm curious in what situations someone needs to parse OsStr or OsString types. That'll also help in understanding if we should also look into supporting TryFrom, TypedValueParser::try_map, or a host of additional solutions on top of exposing more error context.

[epage]

For this issue, there are two core problems

• We don't expose a way to set Error::context
• We don't expose a way to enable coloring and other similar features

[kpreid]

could you expand on your use case?

In the particular case, I want to validate that --output <FILE> has a recognizable filename extension. I could do this validation on the final struct post-clap-parsing of course, but then I still don't have the ability to provide all the nice formatted error context, at least without doing a lot of digging to get an &mut Command (which, besides being inelegant, also doesn't fit well the clap derive system which allows the code that runs after clap parsing to not care about anything but the struct fields).

A more elaborate case of actual parsing involving OsStr input might be, say, expecting a glob pattern or a numeric-sequence pattern.

That'll also help in understanding if we should also look into supporting…

Prior to clap 3.2 I was using the validator_os option. So, TypedValueParser::try_map would be perhaps a good option, if it then supports returning an error that will be given context (as opposed to the map function having to assemble the desired context itself). While setting arbitrary context would be sufficient, it would be preferable to be able to express “this is a validation error; please insert all the context you would for that” without having to duplicate that fragment of clap's internal logic. That way, good and consistent messages appear by default.

[kpreid]

I just confirmed that release 4.0.12 solves the problem I had. Thanks!