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

Invalid format string detection is over-eager #16

Open
coriolinus opened this issue Jul 13, 2021 · 1 comment
Open

Invalid format string detection is over-eager #16

coriolinus opened this issue Jul 13, 2021 · 1 comment

Comments

@coriolinus
Copy link

Example

// for purposes of this example, this struct is defined in an external crate and cannot be modified.
#[derive(Debug)]
struct Point {
    x: i32,
    y: i32,
}

// therefore, this wrapper exists to add `FromStr` and `Display` implementations.
#[derive(Debug, parse_display::FromStr, parse_display::Display)]
#[display("<{0.x}, {0.y}>")]
struct PointWrapper(Point);

Expected Behavior

As all fields of the wrapped type are specified, no error occurs.

Observed Behavior

error: field `0` is not appear in format.
 --> src/main.rs:8:11
  |
8 | #[display("<{0.x}, {0.y}>")]
  |           ^^^^^^^^^^^^^^^^
@frozenlib
Copy link
Owner

The ability to initialize a field with a constructor of its type does not exist, which is why this error is generated.

If a variable such as "{a.b}" is used in a format string, as in your example, I can implement the initialization ability using the constructor of the field type.

However, when using a variable such as "{a.b.c}" as shown in the following example, I cannot implement it because the macro cannot obtain the constructor name of the "a.b" part.

struct Point {
    x: i32,
    y: i32,
}
struct KeyValue {
    key: i32,
    value: Point,
}

// The macro can't obtain the constructor name `Point`.
#[derive(parse_display::FromStr)]
#[display("key = {0.key}, value = <{0.value.x}, {0.value.y}>")]
struct Wrapper(KeyValue);

For this reason, I have not implemented it until now, as it would be a strange "only available when the field nest is shallow" specification.

However, I think this specification is still useful, and if I can't think of a better one, I will try to implement it.

If Pre-RFC: Struct constructor name inference is available, then I can support variable such as {a.b.c}.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants