Travis build fails when using beta channel

[xd009642]

Firstly here is the travis run in question link the error says:

error[E0554]: #![feature] may not be used on the beta release channel
  --> /home/travis/.cargo/registry/src/github.aaakk.us.kg-1ecc6299db9ec823/proc-macro2-0.4.19/src/lib.rs:49:5
   |
49 | /     feature(proc_macro_raw_ident, proc_macro_span)
50 | | )]
   | |_^

I'll look into this myself but if anyone knows what the solution is that would be much appreciated 👍

[alexcrichton]

Do you have procmacro2_semver_exempt specified as a cfg? That unfortunately makes it so this crate requires nightly.

[xd009642]

I do. However, it works on stable which is why I don't understand why beta fails 😕

[alexcrichton]

Ah ok, that's because we're doing automatic detection of what compiler is in use, and opportunistically enabling the proc_macro crate linkage and APIs if the right compiler version is detected (which is beta and afterwards). Once 1.29.0 becomes stable this'll also break the stable build.

The feature story around proc-macro2 is a little bit muddied due to historical implementation shims, but we intend to require that the semver_exempt cfg requires nightly unconditionally.

[xd009642]

Fair enough that makes sense. Looks like I'll be making my project nightly until the relevant things are stabilised.

I'd be willing to help move this to stable if there are any issues that are beginner friendly or other ways I could help 😄

[alexcrichton]

Sure yeah! The stabilizations here need to happen upstream in rust-lang/rust rather than here, so this probably also wants to be tracked upstream there. Unfortunately we haven't been super consistent about opening tracking issues for upstream rust-lang/rust and the proc_macro features, but we can start now!

[xd009642]

Sounds good to me if you point me in the right direction in rust-lang/rust I'll try my best to help. Having a brief search I couldn't see anything in issues but I might not be searching for the right stuff. rust-lang/rust#49219 this looked relevant so wondering how this affects stabilisation once it's merged.

I'm aware this is probably getting offtopic so we can always move this somewhere else. I'm on the official rust-lang discord (I'm assuming #compiler is the relevant channel)

[alexcrichton]

Oh sure yeah, which parts of the unstable API are you interested in? (merging spans? hygiene? filenames? byte positions? etc...)

[xd009642]

Spans are probably the most interest to me. My own personal use makes a lot of use of Span::start() Span::end() (identifying lines of code that shouldn't be including in analysis)

[alexcrichton]

Ok cool, I don't think we have a preexisting dedicated tracking issue for that information but perhaps rust-lang/rust#38546 can be used?

[xd009642]

I reckon there's definitely some overlap between my issue and that one. I'd only be concerned about hijacking djc's issue to work on things that may end up only being tangentially related. But if that's not an issue then sure thing.

[alexcrichton]

Ah ok, want to open a new tracking issue then?

[xd009642]

I was about to and having a look through issues etc and this seems to be an existing tracking issue that covers what I'd like to see stabilised rust-lang/rust#38356 so I'm looking further into that right now

[xd009642]

@alexcrichton dunno if you want to open another issue but I now get this when I attempt to compile my project:

error[E0658]: use of unstable library feature 'proc_macro_def_site' (see issue #54724)                   
   --> /home/xd009642/.cargo/registry/src/github.aaakk.us.kg-1ecc6299db9ec823/proc-macro2-0.4.19/src/unstable.rs:481:27
    |                                                                                                    
481 |             Span::Nightly(proc_macro::Span::def_site())                                            
    |                           ^^^^^^^^^^^^^^^^^^^^^^^^^^                                               
    |                                                                                                    
    = help: add #![feature(proc_macro_def_site)] to the crate attributes to enable                       

[xd009642]

So @alexcrichton I'm going to close this issue, the new tracking issues you opened solve my previously mentioned issue upstream and my new thing is sorted. Of course feel free to reopen if you think this is still useful to have around 👍