[3/n] allow JSON schemas relative to the out dir

[sunshowers]

In upcoming work related to RFD 634 we're going to need to read JSON files out of the build script output directory. Add support for that.

[ahl]

should this be #[serde(default)] and should RelativeTo derive Default?

[sunshowers]

Maybe? That's what I had at first, but I figured if you're using the struct style in the first place, you're probably intending to specify relative_to.

[ahl]

I think I was thrown off by a description of a default variant of RelativeTo

[ahl]

Could this be impl syn::Parse for SpecSource?

[sunshowers]

Interesting idea, and definitely better than what I did. I keep forgetting how syn works, haha. Might be worth putting this pattern somewhere in a list of serde_tokenstream recipes.

Changed it to this + lookahead1 as commented below. I did a bunch of testing on span attributions, and the big thing is that you cannot have the MacroSettings struct use ParseWrapper<SpecSource> directly. Instead, it must be a TokenStreamWrapper that is later parsed.

(related, we don't have a directory of failing inputs to test span attributions for progenitor with -- is it worth building that?)

[ahl]

it seems like all/most of these should be { workspace = true }. I'm not sure why they're not.

[sunshowers]

Yeah they should. Should I do this as a followup?

[ahl]

either way; I'm happy to do it myself later

[ahl]

1. is that an intrinsic property of ParseWrapper or is it fixable?
2. How much do we care? We use ParseWrapper in several other places.

[sunshowers]

It's an artifact of the D::Error::custom being called here: https://docs.rs/serde_tokenstream/latest/src/serde_tokenstream/ibidem.rs.html#59 -- serde flattens custom errors into their Display implementation, so that loses span information. The span used ends up being the span of the entire value associated with the key (so for spec, the entire { path = ..., relative_to = ... }).

Can this be fixed? Maybe we could use a side channel similar to the WRAPPER_TOKENS thread local in ibidem.rs. Worth investigating.

This probably doesn't matter for scalars like ParseWrapper<syn::Ident>. It only matters for compound structures like SpecSource. But I see that we have:

    pre_hook: Option<ParseWrapper<ClosureOrPath>>,
    pre_hook_async: Option<ParseWrapper<ClosureOrPath>>,
    post_hook: Option<ParseWrapper<ClosureOrPath>>,
    post_hook_async: Option<ParseWrapper<ClosureOrPath>>,

which would all be impacted.

[sunshowers]

oxidecomputer/serde_tokenstream#221 fixes this. Once that lands and a new serde_tokenstream version is out, we can change this code to use ParseWrapper directly. (Note that ParseWrapper isn't totally compatible with the error collector/diagnostic sink proc macro pattern where we collect all errors into a common place, but that is a pre-existing limitation.)