Doesn't support `concat!`

[Gaming32]

The standard include_bytes! macro allows certain macros to be passed as its parameter. For instance, concat!. However, include_optional_bytes! only allows raw string literals to be passed. This also applies to the other two macros, *bytes were just an example.

[EliasHolzmann]

Thanks for your report!

I fear this is a bit more tricky than I first expected. Rust uses a lazy-resolve algorithm during macro expansion, meaning that the outer macro is expanded first. Inner macros are then only expanded if they are still part of the token stream generated by the outer macro.

The standard library uses an eager-resolve algorithm (-> first inner macros, then outer macros) for some macros, seemingly including include_bytes!, which explains why include_bytes!(concat!(...)) works. However, this functionality isn't exposed to external crates.

My first naive idea was to simply forward the token stream passed to include_X_optional! macro transparently to the generated include_X! macro call that is used to do the actual inclusion. However, this won't work: Before we generate the include_X! macro call, we need to verify whether the file exists (as the call isn't generated if there is no file, and None is emitted instead). For that, we need the path to the file (and not the token stream that still contains the concat! call).

I currently see two options:

1. We manually implement support for nested concat!() and env!() (and possibly other) calls and resolve them during macro expansion. Sadly, this is very much not trivial. Maybe there is already a library for this. with_builtin_macros::with_eager_expansions looks promising, but the repo is a bit stale (last update 2 years ago, one open issue), and it is mainly intended for macro_rules! style macros, no idea if this works for proc-macro style macros. Also, I'm not really a fan of adding another dependency just to support this edge case.

2. include_dir had the same problem, we could do what they did:

   Most crates will want to use the $CARGO_MANIFEST_DIR or $OUT_DIR variables. For example, to include a folder relative to your crate you might use include_dir!("$CARGO_MANIFEST_DIR/assets").

Both solutions would be fine with me. If you want, feel free to open a PR with one of the options. Otherwise, I might have a go at this in a few weeks if I find the time and motivation.

[Gaming32]

Option 1 would definitely be needed for me, as my use case doesn't actually involve environment variables at all. Rather, I'm appending a second file extension to the file. I might have a go at it later.