Compilation fail on current rustc nightly (1.9.0)

[gyscos]

Libsyntax at least has changed, and many compilation errors result from that.

Some changes are small (things like syntax::ast::PatLit being renamed to syntax::ast::PatKind::Lit, others are slightly larger (like some syntax::ast::ItemKind::Impl.5 moving from Vec<P<ImplItem>> to Vec<ImplItem>).

[thenewwazoo]

Additionally, this commit removes sign from the AST, which I'm not sure how to handle in ioreg/src/builder/utils.rs:30 (and more places besides).

[thenewwazoo]

I've made an exceedingly naive attempt at resolving all the issues I can manage. Remaining in ioreg:

src/builder/utils.rs:140:5: 140:18 error: unresolved enum variant, struct or const `ImplItem` [E0419]
src/builder/setter.rs:205:7: 205:15 error: no method named `to_tokens` found for type `collections::vec::Vec<syntax::ptr::P<syntax::ast::ImplItem>>` in the current scope
src/builder/getter.rs:204:7: 204:15 error: no method named `to_tokens` found for type `collections::vec::Vec<syntax::ptr::P<syntax::ast::ImplItem>>` in the current scope
src/builder/register.rs:74:19: 74:42 error: the trait `core::iter::FromIterator<syntax::ptr::P<syntax::codemap::Spanned<syntax::ast::Variant_>>>` is not implemented for the type `collections::vec::Vec<syntax::codemap::Spanned<syntax::ast::Variant_>>` [E0277]
src/builder/accessors.rs:99:7: 99:13 error: no method named `to_tokens` found for type `collections::vec::Vec<syntax::ptr::P<syntax::ast::ImplItem>>` in the current scope

along with the aforementioned sign issues.

[gyscos]

Yeah, those come from the removal of the P indirection.

[richo]

I created a PR that fixes many of these bugs. I'm currently working on where enum variants are specified to be u32 (I presume this is because they're reprd to the width of the registers) but sadly many primitive ops are defined on usize

[gyscos]

After updating to the new libsyntax::ast enums, compiling examples still give the following two kinds of errors, both related to the ioregs macro (many errors of each kind):

EDIT: I think the one is caused by #[inline] on impl { } blocks rather than individual functions. See: https://doc.rust-lang.org/error-index.html#E0518 (Appears in ioreg/src/builder/getter.rs:199 and ioreg/src/builder/setter.rs:201) It seems the methods there already are individually tagged with #[inline], so it's probably safe to simply remove it from the impl block?

/home/gyscos/fetched/zinc/src/hal/lpc17xx/pwm.rs:172:3: 291:6 error: attribute should be applied to function [E0518]
/home/gyscos/fetched/zinc/src/hal/lpc17xx/pwm.rs:172   ioregs!(PWM1@0x40018000 = {
/home/gyscos/fetched/zinc/src/hal/lpc17xx/pwm.rs:173     /// Interrupt Register. The IR can be written to clear
/home/gyscos/fetched/zinc/src/hal/lpc17xx/pwm.rs:174     /// interrupts. The IR can be read to identify which of eight
/home/gyscos/fetched/zinc/src/hal/lpc17xx/pwm.rs:175     /// possible interrupt sources are pending.
/home/gyscos/fetched/zinc/src/hal/lpc17xx/pwm.rs:176     0x00 => reg32 ir {
/home/gyscos/fetched/zinc/src/hal/lpc17xx/pwm.rs:177       0  => irq_mr0,  //= Interrupt flag for PWM match channel 0.

EDIT: And this one seems to be coming from ioreg/src/builder/getter.rs:141 where we create a Us instead of a U32...

/home/gyscos/fetched/zinc/src/hal/lpc17xx/pwm.rs:193:10: 193:11 error: mismatched types:
 expected `u32`,
    found `usize` [E0308]
/home/gyscos/fetched/zinc/src/hal/lpc17xx/pwm.rs:193          0 => DISABLED,
                                                              ^
/home/gyscos/fetched/zinc/src/hal/lpc17xx/pwm.rs:172:3: 291:6 note: in this expansion of ioregs! (defined in /home/gyscos/fetched/zinc/src/lib.rs)
/home/gyscos/fetched/zinc/src/hal/lpc17xx/pwm.rs:193:10: 193:11 help: run `rustc --explain E0308` to see a detailed explanation

[gyscos]

Zinc now (mostly) compiles with a modern compiler.