Feature request: YAML as compile-time only dependency

[devinrsmith]

I think that the YAML dependency could be a compile-time only dependency. That would be the best of both world IMO - keep the source neat and tidy, no need for runtime parsing of the parser, and no runtime YAML dependency!

build-scripts
code generation / build-dependencies

[Kage-Yami]

I was also thinking along these lines, but after reading Specifying Dependencies -> Build dependencies, don't they only apply to build.rs (and in fact specifically don't apply to the app itself)? If so, then I don't see how this would work, as I would think the CLI definition needs to happen in the app, rather than a build script...

[CreepySkeleton]

@Kage-Yami is right here, dev-depandencies are exposed only to the build script, the app has no access to them. This is not doable, at least not with current API.

[CreepySkeleton]

We can actually make a proc-macro that parses .yaml and expands to resulting clap::App, no runtime cost involved!

[pksunkara]

The main concern with a proc-macro that parser .yaml is custom spans. For example, let's assume we have a proc-macro load_yaml that builds an App out of yml file. And if the yml file has an error, we should emit a proc-macro-error pointing to the issue which is difficult without us being able to build custom spans (since we won't be tokenizing yml file directly but instead reading the file from fs).

Can we use serde to change something about how we can load the yml during compile time?

NOTE: I looked at the related code, and it looks like current yaml is a run time dependency because it's loading yaml from the yml static string (expanded by include_str!).

[CreepySkeleton]

We can't exactly point there indeed, just because files included via include*! or non-rs files don't really have span info attached to them. What we can do is to print line/column the error was encountered at, and I think it should be "good enough". serde would grant us this info out of box.

[pksunkara]

Yeah, but can we create a span with the line, column info? That would make the error reporting easy

[CreepySkeleton]

We can't create a span with a custom line/column info since the only ways are call_site, def_site, mixed_site. We can't set this info on already existing span because there's no such API, even unstable.

Could you explain what you expect from such API? The error cannot be rendered for files that are not part of a crate.

[pksunkara]

We can't set this info on already existing span because there's no such API, even unstable.

I wanted to make up Span. For files that can not be token streams, but we still want to parse, I wanted to make up Span when I get error and let compile_error! or Diagnostic API take care of printing it for me.

So, I looked into it and proc_macro2 stores the source map locally and thus we can't fool it by making up Span.

[pickfire]

Is const able to help to compile this during compile time? https://github.com/rust-lang/rfcs/blob/master/text/0246-const-vs-static.md

[CreepySkeleton]

@pickfire Nope, since yaml loader is not const at all. We need a proper procedural macro for that.

[epage]

See #3087. I expect any effort in this direction would be in an independent crate.