Don't emit non-asm contents error for naked function composed of errors#95553
Don't emit non-asm contents error for naked function composed of errors#95553bors merged 2 commits intorust-lang:masterfrom
Conversation
|
r? @cjgillot (rust-highfive has picked a reviewer for you, use r? to override) |
cjgillot
left a comment
There was a problem hiding this comment.
Thanks @jam1garner.
This looks good. There is just a stray comment, and it will be good to go.
9563b21 to
0df84cd
Compare
|
This has added/changed tests only to verify behaviour of |
Good point, added, thank you ❤️ |
|
@bors r+ |
|
📌 Commit bf26d87 has been approved by |
|
⌛ Testing commit bf26d87 with merge 92a7455650cc247b4af679fea688bc863205a5ec... |
|
💔 Test failed - checks-actions |
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
@bors retry |
|
⌛ Testing commit bf26d87 with merge 72af5dc9f464de95b6266f831a1bc1f9871ae7f2... |
|
💔 Test failed - checks-actions |
|
The job Click to see the possible cause of the failure (guessed by this bot) |
Rollup of 5 pull requests Successful merges: - rust-lang#95202 (Reduce the cost of loading all built-ins targets) - rust-lang#95553 (Don't emit non-asm contents error for naked function composed of errors) - rust-lang#95613 (Fix rustdoc attribute display) - rust-lang#95617 (Fix &mut invalidation in ptr::swap doctest) - rust-lang#95618 (core: document that the align_of* functions return the alignment in bytes) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Motivation
For naked functions an error is emitted when they are composed of anything other than a single asm!() block. However, this error triggers in a couple situations in which it adds no additional information or is actively misleading.
One example is if you do have an asm!() block but simply one with a syntax error:
This results in two errors, one for the syntax error itself and another telling you that you need an asm block in your function:
This issue also comes up when utilizing
compile_error!()for improving your diagnostics, such as raising a compiler error when compiling for an unsupported target.Implementation
The rules this PR implements are as follows:
The rule of thumb is effectively "if an error is present and its correction could change things, don't raise an error".