Source
r/rust•
shadowmint

1.0 feature gates

Is there a master list somewhere, of what feature gates will disappear by/in 1.0?

I know it's only a few days away from the first stable alpha, but in the 'getting ready for 1.0', I've been slowly trying to roll back the feature gates I use in my various crates and I'm still seeing errors when I remove them, notably for unsafe_destructor and macro_rules?

Similarly, is there a cargo flag for 'lint for use of unstable api'? I see rustc has --warn unstable, but I'm just been trawling through cargo issues about passing flags to rustc and I can't see any obvious way of doing it?

Posted Jan 6, 2015, 3:03 AM UTC

1416
steveklabnik1rust•

IIRC, the gates left to remove are globs, macro_rules, aaaand... I'm forgetting one. But they'll all be in the right place by Friday.

The lint hasn't landed yet, IIRC.

6
dbaupprust•

#20568 removes the gates on associated_types, default_type_parameters and globs.

6
shadowmintOP•

Well, I've got to say I'm looking forwards to that lint.

For example http://static.rust-lang.org/doc/master/libc/stability.html seems to suggest that once the lint hits, absolutely nothing is going to work any more. :P

It kind of feels like its not even worth bothering to try to sort stuff out for now. As far as I can tell, every single package is going to broken once it does.

1
steveklabnik1rust•

absolutely nothing is going to work any more.

There is a significant amount of things that are going to be #[stable] soon that aren't currently. For that crate in particular, see https://github.com/rust-lang/rust/pull/20606

1
dbaupprust•

Is there a master list somewhere, of what feature gates will disappear by/in 1.0?

There is a list under the "feature stabilization" heading of #19260.

unsafe_destructor

This isn't fixed yet, but #20539 makes good progress.

Similarly, is there a cargo flag for 'lint for use of unstable api'? I see rustc has --warn unstable, but I'm just been trawling through cargo issues about passing flags to rustc and I can't see any obvious way of doing it?

These will start to be activated by default in rustc itself with the alpha and betas. They will be unavoidable hard errors in the 1.0 stable release(making that functionality only available in the nightly branch), but the softer warnings give us a chance to migrate, and also a chance to provide feedback about standard library APIs that people feel are particularly important to be in 1.0 stable.

5
functor•

There's several feature gates that I need that won't be removed by 1.0, so it looks like I'll be stuck on the nightly branch for quite a while :(.

2
steveklabnik1rust•

Care to elaborate? Knowing which things are popular can help know which ones to try to stabilize first, in the future.

5
functor•

Right now the #!feature line for an app I'm working on looks like this:

#![feature(link_args, globs, phase, unsafe_destructor, macro_rules, default_type_params, associated_types, old_orphan_check)]

It looks like globs, macro_rules, default_type_params, and associated_types should be stabilized for 1.0, and I think parts of unsafe_destructor will be as well. I need old_orphan_check because of a really weird error I was seeing with associated types ("type parameter __S must also appear as a type parameter of some type defined within this crate"). Several other people are seeing similar errors. Hopefully this problem will be fixed before 1.0.

I use phase for the rest_easy crate, which isn't really needed but tells me when rustc is done with everything that could cause compilation to fail. I use link_args to enable a flag that prevents my app from opening a command line on windows, so it only displays the GUI window that I open. (The exact LOC that I use for this is #[cfg(windows)] #[link_args = "-Wl,--subsystem,windows"] extern {})

It looks like the situation isn't as bad as I thought. I'd really like to have link_args or something similar (or else every Windows application with a GUI must also open a useless command line in the background), but all the others will be stabilized by 1.0 or aren't really needed for this app.

5
cmrx64rust•

Holy crap, people actually use rest_easy. I find this humbling and hilarious. It was a 10min hack because I was frustrated :)

10
functor•

It's kind of silly but it's surprisingly useful when compilation takes a long time (especially with optimizations).

3
paulduncanidaho•

heck yea i do!

I've even had a PR open against it for a while now :)

1
mozilla_kmc•

That's an amusing plugin :)

You could do something similar with rustc -Z time-passes | grep ...

1
mrmackyrust-story•

If I had known rest_easy existed: I'd have been using it since last April.

1
sanxiynrust · servo•

When #20032 lands, you will be able to use rest_easy via command line, instead of using phase feature gate.

3
functor•

Will that work with Cargo?

1