internal compiler error: in take_expression_fragment, at rust/ast/rust-ast.h:1855

[bjorn3]

macro_rules! maybe_return { ($e:expr) => ($e); }

fn frob(x: i32) -> i32{
    maybe_return! {x}
    // should return -1 
    -1
}

results in an ice with the version of gccrs on compiler explorer (1bb9a29).

rust1: internal compiler error: in take_expression_fragment, at rust/ast/rust-ast.h:1855
0x2042789 internal_error(char const*, ...)
	???:0
0x80023f fancy_abort(char const*, int, char const*)
	???:0
0x92a158 Rust::AST::ASTFragment::take_expression_fragment()
	???:0
0x9271f4 Rust::AttrVisitor::visit(Rust::AST::ArithmeticOrLogicalExpr&)
	???:0
0x9283a5 Rust::AttrVisitor::visit(Rust::AST::BlockExpr&)
	???:0
0x9268be Rust::AttrVisitor::visit(Rust::AST::Function&)
	???:0
0x8d27fe Rust::MacroExpander::expand_crate()
	???:0
0x8bec2e Rust::Session::expansion(Rust::AST::Crate&)
	???:0
0x8c1de4 Rust::Session::parse_file(char const*)
	???:0
0x8c29c0 Rust::Session::parse_files(int, char const**)
	???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
Compiler returned: 1

Originally posted by @bjorn3 in #22 (comment)

[CohenArthur]

Thanks a lot! Looking into this right now. I think this is probably the parser going haywire when parsing the invocation, because the ICE indicates that the macro was expanded as a statement - and adding a semicolon at the end of the invocation causes the expected behavior.

[powerboat9]

It looks like this might be resolved