Compiler warnings about inefficient incremental compilation

[weiznich]

While compiling diesel/ring rustc emitted the following warning:

warning: Quasi-quoting might make incremental compilation very inefficient: NtExpr(..)

@sgrif suspects this to be a bug in rustc rather than in diesel. So I will report this also here.

Environment:
rustc 1.17.0-nightly (8c4f2c6 2017-03-22)
export CARGO_INCREMENTAL=1 RUSTFLAGS="-Zincremental-info"

[sgrif]

This is coming from the use of #[doc=$macro_var] inside of a macro it seems

[briansmith]

This is coming from the use of #[doc=$macro_var] inside of a macro it seems

Yes, this seems to be what ring is doing that triggers this warning.

Does the use of #[doc=$macro_var] actually hurt incremental compilation performance? I.e. is this warning a false positive or is it a real issue when #[doc=$macro_var] is used?

If it really is causing performance problems, is there something I can do that is equivalent that won't? And/or is there something that can be changed in rustc to fix the compilation performance for this construct?

If it isn't really causing incremental compilation to be slow, then could we change rustc to stop emitting this warning. And/or could we add a way to use #[allow(...)] to turn off the warning?

[michaelwoerister]

Does the use of #[doc=$macro_var] actually hurt incremental compilation performance?

I don't know how #[doc=$macro_var] works but the thing it is attached to will probably always be considered changed by incr. comp., even if it hasn't.

[briansmith]

I don't know how #[doc=$macro_var] works but the thing it is attached to will probably always be considered changed by incr. comp., even if it hasn't.

It seems strange that that would be true, since it's just documentation, which doesn't affect code generation. IMO documentation should be ignored when comparing things for changes.

[michaelwoerister]

It seems strange that that would be true, since it's just documentation, which doesn't affect code generation.

If we can guarantee that it has no influence on a regular compilation session then yes, we can bake special knowledge into the compiler to ignore this attribute. This must be some kind of special case though, because we already filter out doc comments.

Does someone have a minimal test case for this lying around?

[michaelwoerister]

I'm closing this in favor of #40946 where there's been some concrete discussion about a solution.