Issue 1:
When using the try!() macro, directly on an iterator element. The compiler crashes, and fails to tell what is wrong with the code.

I tried this code:

for try!(element) in elements {
// Do stuff here
}

Cargo crashed when attempting to compile the code. Commenting that part out, or removing the try!() call, caused the code to compile, so I think it is safe to assume that the "try!(element)" part is what is causing the issue.

Meta

rustc --version --verbose:

rustc 1.2.0 (082e476 2015-08-03)

binary: rustc

commit-hash: 082e476

commit-date: 2015-08-03

host: x86_64-apple-darwin

release: 1.2.0

Backtrace:

Magnuss-MacBook-Air:stocks Magnus$ RUST_BACKTRACE=1 cargo build --verbose

Fresh rustc-serialize v0.3.15

Compiling stocks v0.1.0 (file:///Users/Magnus/MagnusUlf/Rust/stocks)

Running rustc src/main.rs --crate-name stocks --crate-type bin -g --out-dir /Users/Magnus/MagnusUlf/Rust/stocks/target/debug --emit=dep-info,link -L dependency=/Users/Magnus/MagnusUlf/Rust/stocks/target/debug -L dependency=/Users/Magnus/MagnusUlf/Rust/stocks/target/debug/deps --extern rustc_serialize=/Users/Magnus/MagnusUlf/Rust/stocks/target/debug/deps/librustc_serialize-c1e8163a38ed3d54.rlib

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

thread 'rustc' panicked at 'fold_mac disabled by default', ../src/libsyntax/fold.rs:190

stack backtrace:

1: 0x10d92c7b5 - sys::backtrace::write::hf5ea20500b66cd24uns

2: 0x10d935013 - panicking::on_panic::hbe02cb0d925cad49iGw

3: 0x10d8f0dd2 - rt::unwind::begin_unwind_inner::h12ba0ba9dffdecc2uow

4: 0x10b59c1d6 - rt::unwind::begin_unwind::h2011421250315581831

5: 0x10b807e8c - ptr::P::map::h3829385840473244073

6: 0x10b7f808b - ext::expand::expand_expr::closure.64700

7: 0x10b7f61b0 - ext::expand::expand_expr::h00bf5a43419a5a9b93a

8: 0x10b846b90 - fold::noop_fold_stmt::h4092105005077979799

9: 0x10b8228ae - ext::expand::expand_stmt::h8332ca149d4a1896QEb

10: 0x10b84f4a3 - ext::expand::expand_block_elts::closure.65407

11: 0x10b84f156 - iter::FlatMap<I, U, F>.Iterator::next::h7837221099035994564

12: 0x10b84e067 - vec::Vec.FromIterator::from_iter::h4964964009179316507

13: 0x10b84d66d - ext::expand::expand_block_elts::closure.65401

14: 0x10b8098ea - ext::expand::expand_block_elts::h962105c93a5677c6MPb

15: 0x10b84d322 - ext::expand::expand_block::ha3009aa3e00113ce7Ob

16: 0x10b8092bc - ext::expand::expand_and_rename_fn_decl_and_block::h281d482393d5142bbjc

17: 0x10b81085d - ext::expand::expand_item_underscore::h6f178e8b5a32d33fgtb

18: 0x10b8744f4 - fold::Folder::fold_item_simple::h6794700446803303180

19: 0x10b8740c3 - ptr::P::map::h1211983651740850239

20: 0x10b80dd2d - ext::expand::expand_annotatable::hb4dbc2b7d2ec92e58Zb

21: 0x10b809a71 - ext::expand::expand_item::h3540f4af8f7fd9f8Fsb

22: 0x10b81697a - iter::FlatMap<I, U, F>.Iterator::next::h12102230822894758553

23: 0x10b815887 - vec::Vec.FromIterator::from_iter::h16893642646688759245

24: 0x10b81504f - fold::noop_fold_mod::h14542714455252956640

25: 0x10b810fee - ext::expand::expand_item_underscore::h6f178e8b5a32d33fgtb

26: 0x10b8744f4 - fold::Folder::fold_item_simple::h6794700446803303180

27: 0x10b8740c3 - ptr::P::map::h1211983651740850239

28: 0x10b80e7ad - ext::expand::expand_annotatable::hb4dbc2b7d2ec92e58Zb

29: 0x10b809a71 - ext::expand::expand_item::h3540f4af8f7fd9f8Fsb

30: 0x10b87d79f - ext::expand::expand_crate::ha5b4cf319725184aGrc

31: 0x10a252402 - driver::phase_2_configure_and_expand::closure.21456

32: 0x10a206822 - driver::phase_2_configure_and_expand::hcb65c5920cf60903ita

33: 0x10a1f609d - driver::compile_input::hb6d2be5b0fa2247fTba

34: 0x10a2d313f - run_compiler::h21d74b88eec3fe3bx7b

35: 0x10a2d09f3 - boxed::F.FnBox::call_box::h1689969825914258414

36: 0x10a2d01b7 - rt::unwind::try::try_fn::h11273853850686318048

37: 0x10d9bfcc8 - rust_try_inner

38: 0x10d9bfcb5 - rust_try

39: 0x10d91ec95 - rt::unwind::try::inner_try::h480e3107f6a4b5b9nkw

40: 0x10a2d03e8 - boxed::F.FnBox::call_box::h888215220722514405

41: 0x10d933a9d - sys:🧵:Thread:: new::thread_start::hdb3d925f69c5da4aHIv

42: 0x7fff81f3b267 - _pthread_body

43: 0x7fff81f3b1e4 - _pthread_start

Could not compile stocks.

Caused by:

Process didn't exit successfully: rustc src/main.rs --crate-name stocks --crate-type bin -g --out-dir /Users/Magnus/MagnusUlf/Rust/stocks/target/debug --emit=dep-info,link -L dependency=/Users/Magnus/MagnusUlf/Rust/stocks/target/debug -L dependency=/Users/Magnus/MagnusUlf/Rust/stocks/target/debug/deps --extern rustc_serialize=/Users/Magnus/MagnusUlf/Rust/stocks/target/debug/deps/librustc_serialize-c1e8163a38ed3d54.rlib (exit code: 101)

Issue 2:
This is currently an error:

#[repr(C)]
enum Foo {
Foo
}

which is odd because it looks like a c-like enum. However it also looks like a univariant enum. We should specify which behaviour is correct.

More generally, should this be considered a c-like enum, or should it be a univariant enum. This affects several other aspects of the compiler.