Maybe allow rust_proc_macro rules to write files to OUT_DIR

[adsnaider]

I don't know if this is a good idea but cargo doesn't stop a proc-macro author from writing to OUT_DIR, however, bazel does error if a file is written to OUT_DIR. I don't think it's a good idea to let proc-macro authors write to OUT_DIR but it's already the case that some crates do so.

The original request comes from this bug: HKalbasi/zngur#100. We transitively use sailfish which does some internal caching by writing compiled outputs to OUT_DIR.

This is the error

error: proc-macro derive panicked
  --> external/rules_rust++crate+crates_std__zngur-generator-0.8.0/src/template.rs:45:10
   |
45 | #[derive(Template)]
   |          ^^^^^^^^
   |
   = help: message: called `Result::unwrap()` on an `Err` value: Os { code: 30, kind: ReadOnlyFilesystem, message: "Read-only file system" }

error: proc-macro derive panicked
  --> external/rules_rust++crate+crates_std__zngur-generator-0.8.0/src/template.rs:97:10
   |
97 | #[derive(Template)]
   |          ^^^^^^^^
   |
   = help: message: called `Result::unwrap()` on an `Err` value: Os { code: 30, kind: ReadOnlyFilesystem, message: "Read-only file system" }

...

[Ryex]

crabtime also uses OUT_DIR to store generated crates to compile it's macro invocations.

[UebelAndre]

Do folk know if there's appetite for having these projects write elsewhere? Like have the ability to set an env var and write to a directory other than OUT_DIR?

[adsnaider]

@UebelAndre, what's motivation for that? Ideally rules_rust is as compatible to cargo as possible so crates work out of the box. Is there a benefit to having a different output directory? That would require crates to be patched which isn't ideal if I'm understanding you correctly

[UebelAndre]

Making OUT_DIR (which is the output of another action and is immutable) writable seems fairly heavy handed where we'd need to copy it (can be expensive), recreate a symlink tree (has edge cases and is not windows friendly), or somehow change permissions (dangerous)? I don't see a path forward where this feels like a great idea but someone can show me the path 😅

With that said, I think there are two fairly efficient paths forward for the Bazel rules which are

• Writing these outputs can be inhibited in the crate doing this
• The crate supports specifying where you want to write these outputs

I would like to have rules_rust match user expectations who come from Cargo but there are certainly limitations and I've had to make a number of pull-requests in other crates to support these limitations. In many cases (like using env! vs std::env::var) the original design was a fairly arbitrary decision that the authors were all fine with.