Strange/funny error message with `include_bytes!`

[ianprime0509]

The "fix-it" hint when using the include_bytes! macro where a &str is expected is rather interesting:

error[E0308]: mismatched types
 --> src/main.rs:1:21
  |
1 | static TEST: &str = include_bytes!("test.txt");
  |                     ^^^^^^^^^^^^^^^^^^^^^^^^^^
  |                     |
  |                     expected str, found array of 3 elements
  |                     help: consider removing the leading `b`: `nclude_bytes!("test.txt")`
  |
  = note: expected type `&'static str`
             found type `&'static [u8; 3]`

I was able to reproduce this on stable 1.24.0 and nightly. Here are the relevant rustc --version --verbose outputs:

Stable:

rustc 1.24.0 (4d90ac38c 2018-02-12)
binary: rustc
commit-hash: 4d90ac38c0b61bb69470b61ea2cccea0df48d9e5
commit-date: 2018-02-12
host: x86_64-unknown-linux-gnu
release: 1.24.0
LLVM version: 4.0

Nightly:

rustc 1.25.0-nightly (27a046e93 2018-02-18)
binary: rustc
commit-hash: 27a046e9338fb0455c33b13e8fe28da78212dedc
commit-date: 2018-02-18
host: x86_64-unknown-linux-gnu
release: 1.25.0-nightly
LLVM version: 6.0

I don't know anything about the compiler internals, but my best guess is that the fix-it suggestion is generated based on the expanded macro output (which starts with a b), but the suggested "fix" is generated from the source text without knowing that the two are different. Not a serious problem, but it's certainly entertaining :) I tried searching the issue tracker to see if anyone else had experienced this, but I couldn't find anything, so my apologies if this is a duplicate of something.

EDIT: Right after filing the issue, I decided to go and track it down in the source: it originates here, and could probably be fixed easily by checking if the first character is actually a b before outputting the message. Not so sure about the error suggested by the code that immediately follows, which will add a b to include_str! if a &[u8] is expected.

[estebank]

I believe that we should verify wether any given span has a macro backtrace before providing suggestions in a general way. I'm sure there're other cases of this lurking that haven't yet been reported. Performing the check in span_suggestion could be done, but it wouldn't catch cases where a span is synthesized. In this case, if the result of call_span_if_macro is different to expr.span, the suggestion should not be shown because it's trying to operate on the text of the call site, which would always be incorrect unless applied within the macro itself (which would happen if you were using macro expansion when calling rustc). The same applies to the case immediately below and I think, the dereference case.

[oli-obk]

cc @flip1995

[flip1995]

Can we even do the macro check in the span_suggestion? If I understand this correctly, we need the context for the macro check, which we don't have in the span_suggestion. Or am I missing something here?

Should I just take the easy route here and add a check after each call to call_span_if_macro if the returned span is equal to the expr.span?

[oli-obk]

Clippy's in_macro function

https://github.com/rust-lang-nursery/rust-clippy/blob/master/clippy_lints/src/utils/mod.rs#L57-L65

does not access anything but the span. So we could probably move that method onto Span and then call it inside span_suggestion