codegen_llvm: verify that inline assembly operands are scalars #54747
Conversation
|
r? @cramertj (rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
r? @nagisa |
| span_err!(bx.sess(), statement.source_info.span, E0668, | ||
| "malformed inline assembly"); | ||
| if input_vals.is_err() { | ||
| span_err!(bx.sess(), statement.source_info.span, E0669, |
There was a problem hiding this comment.
Perhaps you could use the span(s) of the operands to make it clearer to the user where the error lies.
It is fine to use different codes.
Would definitely be nice to point out the exact operand with a span as @parched mentioned, but you might have to carry through some extra information for it to work. I’m fine with making that a task for the future and landing this first. |
|
I'll have a look at getting the span of the operand into the error message, but from what I can tell it's not trivial. I'd say we land this and then I'll add improving the error message to my TODO list :) |
|
Please squash the commits as well. |
nagisa
added
S-waiting-on-author
Otherwise, LLVM translation will fail with a panic. Signed-off-by: Levente Kurusa <lkurusa@acm.org>
levex
force-pushed
the
inline-asm-bad-operands
branch
from
33b67d9 to
3d7476e
Compare
Done! |
|
@bors r+ |
|
📌 Commit 3d7476e has been approved by |
bors
added
S-waiting-on-bors
codegen_llvm: verify that inline assembly operands are scalars Another set of inline assembly fixes. This time let's emit an error message when the operand value cannot be coerced into the operand constraint. Two questions: 1) Should I reuse `E0668` which was introduced in #54568 or just use `E0669` as it stands because they do mean different things, but maybe that's not too user-friendly. Just a thought. 2) The `try_fold` returns the operand which failed to be converted into a scalar value, any suggestions on how to use that in the error message? Thanks!
|
☀️ Test successful - status-appveyor, status-travis |
Rollup of 9 pull requests Successful merges: - #54747 (codegen_llvm: verify that inline assembly operands are scalars) - #54848 (Better Diagnostic for Trait Object Capture) - #54850 (Fix #54707 - parse_trait_item_ now handles interpolated blocks as function body decls) - #54858 (second round of refactorings for universes) - #54862 (Implement RFC 2539: cfg_attr with multiple attributes) - #54869 (Fix mobile docs) - #54870 (Stabilize tool lints) - #54893 (Fix internal compiler error on malformed match arm pattern.) - #54904 (Stabilize the `Option::replace` method) Failed merges: - #54909 ( Add chalk rules related to associated type defs) r? @ghost
Rollup of 9 pull requests Successful merges: - #54747 (codegen_llvm: verify that inline assembly operands are scalars) - #54848 (Better Diagnostic for Trait Object Capture) - #54850 (Fix #54707 - parse_trait_item_ now handles interpolated blocks as function body decls) - #54858 (second round of refactorings for universes) - #54862 (Implement RFC 2539: cfg_attr with multiple attributes) - #54869 (Fix mobile docs) - #54870 (Stabilize tool lints) - #54893 (Fix internal compiler error on malformed match arm pattern.) - #54904 (Stabilize the `Option::replace` method) Failed merges: - #54909 ( Add chalk rules related to associated type defs) r? @ghost
Another set of inline assembly fixes. This time let's emit an error message when the operand value cannot be coerced into the operand constraint.
Two questions:
E0668which was introduced in codegen_llvm: check inline assembly constraints with LLVM #54568 or just useE0669as it stands because they do mean different things, but maybe that's not too user-friendly. Just a thought.try_foldreturns the operand which failed to be converted into a scalar value, any suggestions on how to use that in the error message?Thanks!