2014-12-23 23:44:13 -06:00
|
|
|
// Copyright 2014 The Rust Project Developers. See the COPYRIGHT
|
|
|
|
// file at the top-level directory of this distribution and at
|
|
|
|
// http://rust-lang.org/COPYRIGHT.
|
|
|
|
//
|
|
|
|
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
|
|
|
|
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
|
|
|
|
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
|
|
|
|
// option. This file may not be copied, modified, or distributed
|
|
|
|
// except according to those terms.
|
|
|
|
|
Preliminary feature staging
This partially implements the feature staging described in the
[release channel RFC][rc]. It does not yet fully conform to the RFC as
written, but does accomplish its goals sufficiently for the 1.0 alpha
release.
It has three primary user-visible effects:
* On the nightly channel, use of unstable APIs generates a warning.
* On the beta channel, use of unstable APIs generates a warning.
* On the beta channel, use of feature gates generates a warning.
Code that does not trigger these warnings is considered 'stable',
modulo pre-1.0 bugs.
Disabling the warnings for unstable APIs continues to be done in the
existing (i.e. old) style, via `#[allow(...)]`, not that specified in
the RFC. I deem this marginally acceptable since any code that must do
this is not using the stable dialect of Rust.
Use of feature gates is itself gated with the new 'unstable_features'
lint, on nightly set to 'allow', and on beta 'warn'.
The attribute scheme used here corresponds to an older version of the
RFC, with the `#[staged_api]` crate attribute toggling the staging
behavior of the stability attributes, but the user impact is only
in-tree so I'm not concerned about having to make design changes later
(and I may ultimately prefer the scheme here after all, with the
`#[staged_api]` crate attribute).
Since the Rust codebase itself makes use of unstable features the
compiler and build system to a midly elaborate dance to allow it to
bootstrap while disobeying these lints (which would otherwise be
errors because Rust builds with `-D warnings`).
This patch includes one significant hack that causes a
regression. Because the `format_args!` macro emits calls to unstable
APIs it would trigger the lint. I added a hack to the lint to make it
not trigger, but this in turn causes arguments to `println!` not to be
checked for feature gates. I don't presently understand macro
expansion well enough to fix. This is bug #20661.
Closes #16678
[rc]: https://github.com/rust-lang/rfcs/blob/master/text/0507-release-channels.md
2015-01-06 08:26:08 -06:00
|
|
|
// FIXME #20661: format_args! emits calls to the unstable std::fmt::rt
|
|
|
|
// module, so the compiler has some hacks to make that possible
|
|
|
|
// (in span_is_internal). Unnfortunately those hacks defeat this
|
|
|
|
// particular scenario of checking feature gates in arguments to
|
|
|
|
// println!().
|
|
|
|
|
|
|
|
// ignore-test
|
|
|
|
|
2014-12-23 23:44:13 -06:00
|
|
|
// tests that input to a macro is checked for use of gated features. If this
|
|
|
|
// test succeeds due to the acceptance of a feature, pick a new feature to
|
|
|
|
// test. Not ideal, but oh well :(
|
|
|
|
|
|
|
|
fn main() {
|
2015-03-03 02:42:26 -06:00
|
|
|
let a = &[1, 2, 3];
|
2014-12-23 23:44:13 -06:00
|
|
|
println!("{}", {
|
|
|
|
extern "rust-intrinsic" { //~ ERROR intrinsics are subject to change
|
|
|
|
fn atomic_fence();
|
|
|
|
}
|
|
|
|
atomic_fence();
|
|
|
|
42
|
|
|
|
});
|
|
|
|
}
|