How to disable warning about escaped newline skipping multiple lines?

I'm making a crate that can parse Rust literals (among other things), for use in lightweight proc-macros. To verify that it parses the same as Rust itself, I have a test that passes a string with an escaped newline followed by multiple empty lines to a macro. That string triggers a warning from rustc, but unlike other warnings it doesn't say how to disable it. I've searched but haven't found anything. Is there a way?

1 Like

Looks like this warning isn’t a lint, so you cannot disable it via some #![allow(…)] attribute. (Even #[allow(warnings)] doesn’t do it). I’m not really aware of any way to do it directly in the code[1]; neither of any way to specifically disable only this warning, either. As far as solutions involving out-of-code control, and broad disabling of all warnings go, the rustc argument --cap-lints allow does manage to hide this warning, too.

  1. happy to be corrected of course, I myself just couldn’t find a way ↩︎

1 Like

I did some casual scanning and I don't think there's a way besides something like a rustc flag (there is some internal can_emit_warnings flag that gets set to false if --cap-lints is "allow"). It's possible I missed something though.

There's another non-fatal unescape error: unskipped unescaped whitespace following a trailing \. (Only a few unescaped ascii whitespace characters are skipped.)

At a guess, it's not a lint because it's buried deep in the parsing code and most errors are fatal, not warnings.

1 Like

I’d also guess that treating it as a lint would require extra bookkeeping. Instead of just emitting the error, you’d probably have to note it down, have it associated with the AST somehow (even though it used to be part of the lexing process), and come back to it once you’re far enough into compilation to even know what lint levels are set at that place in the code. Not that any of this would really be any hard, but it has to be done at all, and probably just nobody did it yet… (I wonder whether or not there are existing other lints that are created earlier in compilation, but only emitted later once lint levels are available).

The closest is probably unstable_syntax_pre_expansion, e.g. #[cfg(any())] macro m() {}. It's a bit later than this one — it runs as a validation pass on the parse tree — but similarly before the majority of the lint infrastructure exists, and can't be controlled by lint levels. In fact, despite being a future compatibility warning, it's mostly pretending; I had to copy the decoration shape from where it's actually implemented because that's downstream of where that lint needed to exist prior to expansion.

(In fact, due to being emitted prior to expansion and the relevant spans not showing up post expansion, I'm not sure it'd even be "covered" by any lint attributes in the source.)

Thanks everyone. I found out this warning is even emitted for code disabled with cfg. I suppose there's not much point submitting a bug report or feature request about it though. It's a very niche use case and sounds like it'd be difficult to fix if there's not already a system to delay emitting of warnings until they can be selected for.