Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compiling ambiguous macro invocation hangs forever #5067

Closed
stevenblenkinsop opened this issue Feb 21, 2013 · 11 comments
Closed

Compiling ambiguous macro invocation hangs forever #5067

stevenblenkinsop opened this issue Feb 21, 2013 · 11 comments
Labels
A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) I-crash Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics. P-medium Medium priority

Comments

@stevenblenkinsop
Copy link

Trying to compile this code containing an ambiguous macro causes the compiler to hang forever and max out memory:

macro_rules! make_vec(
    (a $e1:expr $($(, a $e2:expr)*)*) => ([$e1 $($(, $e2)*)*]);
)

fn main() {
    let _ = make_vec!(a 1, a 2, a 3);
}

rustc 0.5
host: x86_64-apple-darwin

@catamorphism
Copy link
Contributor

Reproduced as of 4a5e8c5

Backtrace:

#0  0x0000000100a937c5 in glue_drop_19989 ()
#1  0x0000000100a93aa2 in glue_drop_20005 ()
#2  0x0000000100a93a16 in glue_free_20001 ()
#3  0x0000000100a939a1 in glue_drop_19999 ()
#4  0x0000000100b4c3d8 in ext::tt::macro_parser::parse::anon::expr_fn_22797 ()
#5  0x00000001008780fc in uint::range_step::_dbf93249fa86a4bd::_06 ()
#6  0x0000000100877fa9 in uint::range::_555af5271cf0ae9::_06 ()
#7  0x0000000100b474f4 in ext::tt::macro_parser::parse::_4cb9211e6da3397::_06 ()
#8  0x0000000100b53045 in ext::tt::macro_rules::add_new_extension::generic_extension::anon::expr_fn_22947 ()
#9  0x0000000100b52c96 in iter::eachi_22942::anon::expr_fn_22945 ()
#10 0x000000010087436b in vec::__extensions__::each_6884::anon::expr_fn_6886 ()
#11 0x0000000100872e7b in vec::each_6846::anon::expr_fn_6852 ()
#12 0x0000000100872d6e in vec::as_imm_buf_6849::_76567a8977b7947f::_06 ()
#13 0x0000000100872c1a in vec::each_6846::_c97c9de192e2ac95::_06 ()
#14 0x00000001008742f5 in vec::__extensions__::each_6884::_42d0327b1fcd8913::_06 ()
#15 0x0000000100b52c13 in iter::eachi_22942::_43ae4c53d7f2785::_06 ()
#16 0x0000000100b52b93 in vec::__extensions__::eachi_22939::_d7f9bbd7ce525cae::_06 ()
#17 0x0000000100b5278b in ext::tt::macro_rules::add_new_extension::generic_extension::_612cddf6d24ae4::_06 ()
#18 0x0000000100b56e9b in ext::tt::macro_rules::add_new_extension::anon::expr_fn_23067 ()
#19 0x0000000100afa850 in ext::expand::expand_expr::_3612288c626ca4a::_06 ()
#20 0x0000000100b0483e in ext::expand::expand_crate::anon::expr_fn_21721 ()
#21 0x00000001009905b4 in fold::__extensions__::meth_15920::fold_expr::_a9118ad64aa217e::_06 ()
#22 0x0000000100980de8 in fold::noop_fold_local::anon::expr_fn_15276 ()
#23 0x0000000100967d82 in option::map_14843::_10edfb7beead866d::_06 ()
#24 0x0000000100967ce3 in option::__extensions__::map_14840::_ba1ce0cc6134b934::_06 ()
#25 0x0000000100980c04 in fold::noop_fold_local::_4005d84b6236af3::_06 ()
#26 0x000000010098dc87 in fold::wrap_15853::anon::expr_fn_15856 ()
#27 0x00000001009918df in fold::__extensions__::meth_15941::fold_local::_2326fa4da97afec9::_06 ()
#28 0x000000010096f86b in fold::noop_fold_decl::anon::expr_fn_14996 ()
#29 0x0000000100876934 in vec::map_6941::anon::expr_fn_6944 ()
#30 0x0000000100872e7b in vec::each_6846::anon::expr_fn_6852 ()
#31 0x0000000100872d6e in vec::as_imm_buf_6849::_76567a8977b7947f::_06 ()
#32 0x0000000100872c1a in vec::each_6846::_c97c9de192e2ac95::_06 ()
#33 0x000000010087680d in vec::map_6941::_e529897178cd16c::_06 ()
#34 0x000000010096f331 in fold::noop_fold_decl::_835bf0d0d6aef58::_06 ()
#35 0x000000010098c207 in fold::wrap_15761::anon::expr_fn_15764 ()
#36 0x00000001009901cf in fold::__extensions__::meth_15917::fold_decl::_ddb0f9c66531d997::_06 ()
#37 0x000000010096ad0f in fold::noop_fold_stmt::_cdae6f3fce5642c2::_06 ()
#38 0x000000010098b4c7 in fold::wrap_15715::anon::expr_fn_15718 ()
#39 0x0000000100b009ac in ext::expand::expand_stmt::_b5ba7a6ff0557ece::_06 ()
#40 0x0000000100b058fe in ext::expand::expand_crate::anon::expr_fn_21757 ()
#41 0x000000010098f782 in fold::__extensions__::meth_15908::fold_stmt::_132f4f3220116793::_06 ()
#42 0x000000010096aa38 in fold::noop_fold_block::anon::expr_fn_14926 ()
#43 0x0000000100876934 in vec::map_6941::anon::expr_fn_6944 ()
#44 0x0000000100872e7b in vec::each_6846::anon::expr_fn_6852 ()
#45 0x0000000100872d6e in vec::as_imm_buf_6849::_76567a8977b7947f::_06 ()
#46 0x0000000100872c1a in vec::each_6846::_c97c9de192e2ac95::_06 ()
#47 0x000000010087680d in vec::map_6941::_e529897178cd16c::_06 ()
#48 0x00000001008766fe in vec::__extensions__::map_6938::_dddce24f9d4b3050::_06 ()
#49 0x000000010096a6b9 in fold::noop_fold_block::_3ce2ed96932f52d::_06 ()
#50 0x000000010098ae27 in fold::wrap_15692::anon::expr_fn_15695 ()
#51 0x000000010098f437 in fold::__extensions__::meth_15905::fold_block::_bcc5eee69f78d19e::_06 ()
#52 0x0000000100964f86 in fold::noop_fold_item_underscore::_ee3665e2af9ebe80::_06 ()
#53 0x000000010098f15f in fold::__extensions__::meth_15899::fold_item_underscore::_20b45acd839eff24::_06 ()
#54 0x000000010096396c in fold::noop_fold_item::_1b9a3be6faf8edd7::_06 ()
#55 0x0000000100afd2a9 in ext::expand::expand_item::_b1fa382e62bda90::_06 ()
#56 0x0000000100b0585e in ext::expand::expand_crate::anon::expr_fn_21755 ()
#57 0x000000010098ecff in fold::__extensions__::meth_15893::fold_item::_5921b8e062e01364::_06 ()
#58 0x000000010097d4b8 in fold::noop_fold_mod::anon::expr_fn_15180 ()
#59 0x0000000100877222 in vec::filter_mapped_6955::anon::expr_fn_6958 ()
#60 0x0000000100872e7b in vec::each_6846::anon::expr_fn_6852 ()
#61 0x0000000100872d6e in vec::as_imm_buf_6849::_76567a8977b7947f::_06 ()
#62 0x0000000100872c1a in vec::each_6846::_c97c9de192e2ac95::_06 ()
#63 0x0000000100877108 in vec::filter_mapped_6955::_71cc5ed03fa06ab7::_06 ()
#64 0x000000010097d394 in fold::noop_fold_mod::_1161a4ca3fa6e5bb::_06 ()
#65 0x0000000100afbe0f in ext::expand::expand_mod_items::_8c4164b358186694::_06 ()
#66 0x0000000100b057ce in ext::expand::expand_crate::anon::expr_fn_21753 ()
#67 0x0000000100990f55 in fold::__extensions__::meth_15926::fold_mod::_3e418619a34db868::_06 ()
#68 0x0000000100962173 in fold::noop_fold_crate::_99468a714c2466aa::_06 ()
#69 0x000000010098a787 in fold::wrap_15669::anon::expr_fn_15672 ()
#70 0x000000010098e321 in fold::__extensions__::meth_15876::fold_crate::_78bac320468be4d2::_06 ()
#71 0x0000000100b0445d in ext::expand::expand_crate::_3d56f396e40d45d::_06 ()
#72 0x0000000101ad1406 in driver::driver::compile_rest::anon::expr_fn_81354 ()
#73 0x0000000101ad0b1c in driver::driver::time_81337::_ca8b201e95b5826::_06 ()
#74 0x0000000101acb78e in driver::driver::compile_rest::_4c5957856ca98447::_06 ()
#75 0x0000000101ad6619 in driver::driver::compile_upto::_7ae65df72940ea29::_06 ()
#76 0x0000000101ad6a4c in driver::driver::compile_input::_a9a269979a1247c::_06 ()
#77 0x0000000101b22f18 in run_compiler::_3eed7ed095be4467::_06 ()
#78 0x0000000101b44777 in main::anon::expr_fn_83837 ()
#79 0x0000000101b40660 in monitor::anon::expr_fn_83683 ()
#80 0x0000000101b36dca in task::__extensions__::try_83253::anon::expr_fn_83520 ()
#81 0x00000001000cfe5c in task::spawn::spawn_raw::make_child_wrapper::anon::expr_fn_11434 ()
#82 0x0000000102106a05 in task_start_wrapper (a=0x0) at rust_task.cpp:162
(gdb) 

@catamorphism
Copy link
Contributor

Seems non-critical for 0.7. Nominating for milestone 1 (well-defined).

@graydon
Copy link
Contributor

graydon commented May 2, 2013

Accepted for well-defined. we need to write down what is and is not macro-parsable.

@pnkfelix
Copy link
Member

visited for bug triage 2013 june 27. still a problem.

It would be good to define whether our goal is to eliminate all such macro definitions, or if it would be acceptable to fail instead at the point of expansion, when the macro expander determines that there is more than one possible parse. (The latter would integrate well with a proper Earley parsing scheme and probably with any reasonable GLR parsing scheme as well.)

@emberian
Copy link
Member

emberian commented Apr 7, 2014

Still a problem, unfortunately. I have no knowledge about this, but what @pnkfelix says sounds impressive.

@reem
Copy link
Contributor

reem commented Dec 1, 2014

Triage: still a problem, no updates.

@mitaa
Copy link
Contributor

mitaa commented May 12, 2015

This does not compile anymore (PR #20563)
playpen

<anon>:2:17: 2:36 error: `$e1:expr` is followed by a sequence repetition, which is not allowed for `expr` fragments
<anon>:2     (a $e1:expr $($(, a $e2:expr)*)*) => ([$e1 $($(, $e2)*)*]);
                         ^~~~~~~~~~~~~~~~~~~

@Stebalien
Copy link
Contributor

triage: still an issue (on nightly).

@ghost
Copy link

ghost commented Oct 29, 2015

Still occurs using this updated code:

macro_rules! make_vec(
    (a $e1:expr $($(, a $e2:expr)*)*) => ([$e1 $($(, $e2)*)*]);
);

fn main() {
    let _ = make_vec!(a 1, a 2, a 3);
}

@alexcrichton alexcrichton added A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) and removed A-syntaxext Area: Syntax extensions labels Oct 29, 2015
@jonas-schievink
Copy link
Contributor

This code is enough to trigger the bug:

macro_rules! m {
    ( $()* ) => {}
}

m!();

I guess repetitions should check that their innards can not be not empty.

@arielb1 arielb1 added I-crash Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics. and removed I-wrong labels Dec 2, 2015
@dtolnay
Copy link
Member

dtolnay commented Jul 30, 2016

Still an issue in 1.12.0-nightly using the minimal repro in the previous comment.

sophiajt pushed a commit to sophiajt/rust that referenced this issue Sep 26, 2016
reject macros with empty repetitions

Fixes rust-lang#5067 by checking the lhs of `macro_rules!` for repetitions which could match an empty token tree.
sophiajt pushed a commit to sophiajt/rust that referenced this issue Sep 27, 2016
reject macros with empty repetitions

Fixes rust-lang#5067 by checking the lhs of `macro_rules!` for repetitions which could match an empty token tree.
bors added a commit to rust-lang-ci/rust that referenced this issue May 2, 2020
…1995

Add `skip_while_next` lint

Fixes rust-lang#4036

changelog: Add `skip_while_next` lint
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) I-crash Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics. P-medium Medium priority
Projects
None yet
Development

No branches or pull requests