Add a "raw" option for asm! which ignores format string specifiers

[Amanieu]

This is useful when including raw assembly snippets using include_str!.

[rust-highfive]

r? @LeSeulArtichaut

(rust-highfive has picked a reviewer for you, use r? to override)

[LeSeulArtichaut]

I don't think I should be reviewing this. r? @nagisa maybe?

[nagisa]

Huh, this is an interesting artifact of the fact that we do not require the assembly fragments to be a literal string. I do wonder, however, if it would perhaps make more sense to automatically consider assembly to be "raw" if the assembly doesn't come from string literals?

I think the ability to interpolate {}s within a separate file is all that straightforward to understand. Is there a design space exploration for this anywhere?

[Amanieu]

We do require that asm fragments are string literals: include_str! expands to a string literal.

[nagisa]

We do require that asm fragments are string literals: include_str! expands to a string literal.

Hm, confusing, because

fn main() {
    println!(include_str("format"), 42); // where `format` contains `{}`
}

does not work and compiler demands a literal string literal:

error: format argument must be a string literal
 --> test.rs:2:14
  |
2 |     println!(include_str("format"), 42);
  |              ^^^^^^^^^^^^^^^^^^^^^
  |
help: you might be missing a string literal to format with
  |
2 |     println!("{} {}", include_str("format"), 42);
  |              ^^^^^^^^

I wonder why the discrepancy. I bet it'll have something to do with macro expansion order perhaps?

[Amanieu]

There's a typo in your code, you forgot the ! after include_str.

[nagisa]

Ah, silly me.

@bors r+

[bors]

📌 Commit d0443bb has been approved by nagisa

[bors]

⌛ Testing commit d0443bb with merge e6b4c25...

[bors]

☀️ Test successful - checks-actions
Approved by: nagisa
Pushing e6b4c25 to master...