rust/src/libsyntax/feature_gate.rs

518 lines
18 KiB
Rust
Raw Normal View History

// Copyright 2013 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.
//! Feature gating
//!
//! This modules implements the gating necessary for preventing certain compiler
//! features from being used by default. This module will crawl a pre-expanded
//! AST to ensure that there are no features which are used that are not
//! enabled.
//!
//! Features are enabled in programs via the crate-level attributes of
//! `#![feature(...)]` with a comma-separated list of features.
use self::Status::*;
2014-09-10 19:55:42 -05:00
use abi::RustIntrinsic;
use ast::NodeId;
use ast;
use attr;
use attr::AttrMetaMethods;
use codemap::{CodeMap, Span};
2014-09-10 19:55:42 -05:00
use diagnostic::SpanHandler;
use visit;
use visit::Visitor;
use parse::token;
2014-09-07 12:09:06 -05:00
use std::slice;
use std::ascii::AsciiExt;
// if you change this list without updating src/doc/reference.md, @cmr will be sad
static KNOWN_FEATURES: &'static [(&'static str, Status)] = &[
("globs", Active),
("macro_rules", Active),
("struct_variant", Accepted),
2013-10-21 04:16:58 -05:00
("asm", Active),
("managed_boxes", Removed),
("non_ascii_idents", Active),
2013-11-26 13:21:22 -06:00
("thread_local", Active),
Add generation of static libraries to rustc This commit implements the support necessary for generating both intermediate and result static rust libraries. This is an implementation of my thoughts in https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html. When compiling a library, we still retain the "lib" option, although now there are "rlib", "staticlib", and "dylib" as options for crate_type (and these are stackable). The idea of "lib" is to generate the "compiler default" instead of having too choose (although all are interchangeable). For now I have left the "complier default" to be a dynamic library for size reasons. Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a dynamic object. I chose this for size reasons, but also because you're probably not going to be embedding the rustc compiler anywhere any time soon. Other than the options outlined above, there are a few defaults/preferences that are now opinionated in the compiler: * If both a .dylib and .rlib are found for a rust library, the compiler will prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option * If generating a "lib", the compiler will generate a dynamic library. This is overridable by explicitly saying what flavor you'd like (rlib, staticlib, dylib). * If no options are passed to the command line, and no crate_type is found in the destination crate, then an executable is generated With this change, you can successfully build a rust program with 0 dynamic dependencies on rust libraries. There is still a dynamic dependency on librustrt, but I plan on removing that in a subsequent commit. This change includes no tests just yet. Our current testing infrastructure/harnesses aren't very amenable to doing flavorful things with linking, so I'm planning on adding a new mode of testing which I believe belongs as a separate commit. Closes #552
2013-11-15 16:03:29 -06:00
("link_args", Active),
2013-12-25 12:10:33 -06:00
("phase", Active),
("plugin_registrar", Active),
("log_syntax", Active),
("trace_macros", Active),
("concat_idents", Active),
("unsafe_destructor", Active),
("intrinsics", Active),
("lang_items", Active),
2014-01-22 19:25:22 -06:00
("simd", Active),
("default_type_params", Active),
("quote", Active),
("link_llvm_intrinsics", Active),
("linkage", Active),
("struct_inherit", Removed),
("quad_precision_float", Removed),
("rustc_diagnostic_macros", Active),
("unboxed_closures", Active),
("import_shadowing", Active),
("advanced_slice_patterns", Active),
("tuple_indexing", Accepted),
("associated_types", Active),
("visible_private_types", Active),
("slicing_syntax", Active),
("if_let", Accepted),
("while_let", Accepted),
2014-08-26 22:00:41 -05:00
// A temporary feature gate used to enable parser extensions needed
// to bootstrap fix for #5723.
("issue_5723_bootstrap", Accepted),
Fix orphan checking (cc #19470). (This is not a complete fix of #19470 because of the backwards compatibility feature gate.) This is a [breaking-change]. The new rules require that, for an impl of a trait defined in some other crate, two conditions must hold: 1. Some type must be local. 2. Every type parameter must appear "under" some local type. Here are some examples that are legal: ```rust struct MyStruct<T> { ... } // Here `T` appears "under' `MyStruct`. impl<T> Clone for MyStruct<T> { } // Here `T` appears "under' `MyStruct` as well. Note that it also appears // elsewhere. impl<T> Iterator<T> for MyStruct<T> { } ``` Here is an illegal example: ```rust // Here `U` does not appear "under" `MyStruct` or any other local type. // We call `U` "uncovered". impl<T,U> Iterator<U> for MyStruct<T> { } ``` There are a couple of ways to rewrite this last example so that it is legal: 1. In some cases, the uncovered type parameter (here, `U`) should be converted into an associated type. This is however a non-local change that requires access to the original trait. Also, associated types are not fully baked. 2. Add `U` as a type parameter of `MyStruct`: ```rust struct MyStruct<T,U> { ... } impl<T,U> Iterator<U> for MyStruct<T,U> { } ``` 3. Create a newtype wrapper for `U` ```rust impl<T,U> Iterator<Wrapper<U>> for MyStruct<T,U> { } ``` Because associated types are not fully baked, which in the case of the `Hash` trait makes adhering to this rule impossible, you can temporarily disable this rule in your crate by using `#![feature(old_orphan_check)]`. Note that the `old_orphan_check` feature will be removed before 1.0 is released.
2014-12-26 02:30:51 -06:00
// A way to temporarily opt out of opt in copy. This will *never* be accepted.
("opt_out_copy", Deprecated),
// A way to temporarily opt out of the new orphan rules. This will *never* be accepted.
("old_orphan_check", Deprecated),
// These are used to test this portion of the compiler, they don't actually
// mean anything
("test_accepted_feature", Accepted),
("test_removed_feature", Removed),
];
enum Status {
/// Represents an active feature that is currently being implemented or
/// currently being considered for addition/removal.
Active,
Fix orphan checking (cc #19470). (This is not a complete fix of #19470 because of the backwards compatibility feature gate.) This is a [breaking-change]. The new rules require that, for an impl of a trait defined in some other crate, two conditions must hold: 1. Some type must be local. 2. Every type parameter must appear "under" some local type. Here are some examples that are legal: ```rust struct MyStruct<T> { ... } // Here `T` appears "under' `MyStruct`. impl<T> Clone for MyStruct<T> { } // Here `T` appears "under' `MyStruct` as well. Note that it also appears // elsewhere. impl<T> Iterator<T> for MyStruct<T> { } ``` Here is an illegal example: ```rust // Here `U` does not appear "under" `MyStruct` or any other local type. // We call `U` "uncovered". impl<T,U> Iterator<U> for MyStruct<T> { } ``` There are a couple of ways to rewrite this last example so that it is legal: 1. In some cases, the uncovered type parameter (here, `U`) should be converted into an associated type. This is however a non-local change that requires access to the original trait. Also, associated types are not fully baked. 2. Add `U` as a type parameter of `MyStruct`: ```rust struct MyStruct<T,U> { ... } impl<T,U> Iterator<U> for MyStruct<T,U> { } ``` 3. Create a newtype wrapper for `U` ```rust impl<T,U> Iterator<Wrapper<U>> for MyStruct<T,U> { } ``` Because associated types are not fully baked, which in the case of the `Hash` trait makes adhering to this rule impossible, you can temporarily disable this rule in your crate by using `#![feature(old_orphan_check)]`. Note that the `old_orphan_check` feature will be removed before 1.0 is released.
2014-12-26 02:30:51 -06:00
/// Represents a feature gate that is temporarily enabling deprecated behavior.
/// This gate will never be accepted.
Deprecated,
/// Represents a feature which has since been removed (it was once Active)
Removed,
/// This language feature has since been Accepted (it was once Active)
Accepted,
}
/// A set of features to be used by later passes.
2014-12-14 22:32:24 -06:00
#[deriving(Copy)]
pub struct Features {
2014-09-10 19:55:42 -05:00
pub default_type_params: bool,
pub unboxed_closures: bool,
2014-09-10 19:55:42 -05:00
pub rustc_diagnostic_macros: bool,
pub import_shadowing: bool,
pub visible_private_types: bool,
pub quote: bool,
pub opt_out_copy: bool,
Fix orphan checking (cc #19470). (This is not a complete fix of #19470 because of the backwards compatibility feature gate.) This is a [breaking-change]. The new rules require that, for an impl of a trait defined in some other crate, two conditions must hold: 1. Some type must be local. 2. Every type parameter must appear "under" some local type. Here are some examples that are legal: ```rust struct MyStruct<T> { ... } // Here `T` appears "under' `MyStruct`. impl<T> Clone for MyStruct<T> { } // Here `T` appears "under' `MyStruct` as well. Note that it also appears // elsewhere. impl<T> Iterator<T> for MyStruct<T> { } ``` Here is an illegal example: ```rust // Here `U` does not appear "under" `MyStruct` or any other local type. // We call `U` "uncovered". impl<T,U> Iterator<U> for MyStruct<T> { } ``` There are a couple of ways to rewrite this last example so that it is legal: 1. In some cases, the uncovered type parameter (here, `U`) should be converted into an associated type. This is however a non-local change that requires access to the original trait. Also, associated types are not fully baked. 2. Add `U` as a type parameter of `MyStruct`: ```rust struct MyStruct<T,U> { ... } impl<T,U> Iterator<U> for MyStruct<T,U> { } ``` 3. Create a newtype wrapper for `U` ```rust impl<T,U> Iterator<Wrapper<U>> for MyStruct<T,U> { } ``` Because associated types are not fully baked, which in the case of the `Hash` trait makes adhering to this rule impossible, you can temporarily disable this rule in your crate by using `#![feature(old_orphan_check)]`. Note that the `old_orphan_check` feature will be removed before 1.0 is released.
2014-12-26 02:30:51 -06:00
pub old_orphan_check: bool,
}
impl Features {
pub fn new() -> Features {
Features {
2014-09-10 19:55:42 -05:00
default_type_params: false,
unboxed_closures: false,
2014-09-10 19:55:42 -05:00
rustc_diagnostic_macros: false,
import_shadowing: false,
visible_private_types: false,
quote: false,
opt_out_copy: false,
Fix orphan checking (cc #19470). (This is not a complete fix of #19470 because of the backwards compatibility feature gate.) This is a [breaking-change]. The new rules require that, for an impl of a trait defined in some other crate, two conditions must hold: 1. Some type must be local. 2. Every type parameter must appear "under" some local type. Here are some examples that are legal: ```rust struct MyStruct<T> { ... } // Here `T` appears "under' `MyStruct`. impl<T> Clone for MyStruct<T> { } // Here `T` appears "under' `MyStruct` as well. Note that it also appears // elsewhere. impl<T> Iterator<T> for MyStruct<T> { } ``` Here is an illegal example: ```rust // Here `U` does not appear "under" `MyStruct` or any other local type. // We call `U` "uncovered". impl<T,U> Iterator<U> for MyStruct<T> { } ``` There are a couple of ways to rewrite this last example so that it is legal: 1. In some cases, the uncovered type parameter (here, `U`) should be converted into an associated type. This is however a non-local change that requires access to the original trait. Also, associated types are not fully baked. 2. Add `U` as a type parameter of `MyStruct`: ```rust struct MyStruct<T,U> { ... } impl<T,U> Iterator<U> for MyStruct<T,U> { } ``` 3. Create a newtype wrapper for `U` ```rust impl<T,U> Iterator<Wrapper<U>> for MyStruct<T,U> { } ``` Because associated types are not fully baked, which in the case of the `Hash` trait makes adhering to this rule impossible, you can temporarily disable this rule in your crate by using `#![feature(old_orphan_check)]`. Note that the `old_orphan_check` feature will be removed before 1.0 is released.
2014-12-26 02:30:51 -06:00
old_orphan_check: false,
}
}
}
2014-03-05 08:36:01 -06:00
struct Context<'a> {
features: Vec<&'static str>,
2014-09-10 19:55:42 -05:00
span_handler: &'a SpanHandler,
cm: &'a CodeMap,
}
2014-03-05 08:36:01 -06:00
impl<'a> Context<'a> {
fn gate_feature(&self, feature: &str, span: Span, explain: &str) {
if !self.has_feature(feature) {
2014-09-10 19:55:42 -05:00
self.span_handler.span_err(span, explain);
self.span_handler.span_help(span, format!("add #![feature({})] to the \
2014-09-10 19:55:42 -05:00
crate attributes to enable",
2014-12-10 21:46:38 -06:00
feature)[]);
}
}
fn has_feature(&self, feature: &str) -> bool {
self.features.iter().any(|&n| n == feature)
}
}
struct MacroVisitor<'a> {
context: &'a Context<'a>
}
impl<'a, 'v> Visitor<'v> for MacroVisitor<'a> {
fn visit_view_item(&mut self, i: &ast::ViewItem) {
match i.node {
ast::ViewItemExternCrate(..) => {
for attr in i.attrs.iter() {
if attr.name().get() == "phase"{
self.context.gate_feature("phase", attr.span,
"compile time crate loading is \
experimental and possibly buggy");
}
}
},
_ => { }
}
visit::walk_view_item(self, i)
}
fn visit_mac(&mut self, macro: &ast::Mac) {
let ast::MacInvocTT(ref path, _, _) = macro.node;
let id = path.segments.last().unwrap().identifier;
if id == token::str_to_ident("macro_rules") {
self.context.gate_feature("macro_rules", path.span, "macro definitions are \
not stable enough for use and are subject to change");
}
else if id == token::str_to_ident("asm") {
self.context.gate_feature("asm", path.span, "inline assembly is not \
stable enough for use and is subject to change");
}
else if id == token::str_to_ident("log_syntax") {
self.context.gate_feature("log_syntax", path.span, "`log_syntax!` is not \
stable enough for use and is subject to change");
}
else if id == token::str_to_ident("trace_macros") {
self.context.gate_feature("trace_macros", path.span, "`trace_macros` is not \
stable enough for use and is subject to change");
}
else if id == token::str_to_ident("concat_idents") {
self.context.gate_feature("concat_idents", path.span, "`concat_idents` is not \
stable enough for use and is subject to change");
}
}
}
struct PostExpansionVisitor<'a> {
context: &'a Context<'a>
}
impl<'a> PostExpansionVisitor<'a> {
fn gate_feature(&self, feature: &str, span: Span, explain: &str) {
if !self.context.cm.span_is_internal(span) {
self.context.gate_feature(feature, span, explain)
}
}
}
impl<'a, 'v> Visitor<'v> for PostExpansionVisitor<'a> {
fn visit_name(&mut self, sp: Span, name: ast::Name) {
if !token::get_name(name).get().is_ascii() {
self.gate_feature("non_ascii_idents", sp,
"non-ascii idents are not fully supported.");
}
}
fn visit_view_item(&mut self, i: &ast::ViewItem) {
match i.node {
ast::ViewItemUse(ref path) => {
if let ast::ViewPathGlob(..) = path.node {
self.gate_feature("globs", path.span,
"glob import statements are \
experimental and possibly buggy");
}
}
ast::ViewItemExternCrate(..) => {
2013-12-25 12:10:33 -06:00
for attr in i.attrs.iter() {
2014-01-21 12:08:10 -06:00
if attr.name().get() == "phase"{
2013-12-25 12:10:33 -06:00
self.gate_feature("phase", attr.span,
"compile time crate loading is \
experimental and possibly buggy");
}
}
}
}
visit::walk_view_item(self, i)
}
fn visit_item(&mut self, i: &ast::Item) {
2013-11-26 13:21:22 -06:00
for attr in i.attrs.iter() {
if attr.name() == "thread_local" {
2013-11-26 13:21:22 -06:00
self.gate_feature("thread_local", i.span,
"`#[thread_local]` is an experimental feature, and does not \
currently handle destructors. There is no corresponding \
`#[task_local]` mapping to the task model");
} else if attr.name() == "linkage" {
self.gate_feature("linkage", i.span,
"the `linkage` attribute is experimental \
and not portable across platforms")
2013-11-26 13:21:22 -06:00
}
}
match i.node {
ast::ItemForeignMod(ref foreign_module) => {
2014-12-10 21:46:38 -06:00
if attr::contains_name(i.attrs[], "link_args") {
Add generation of static libraries to rustc This commit implements the support necessary for generating both intermediate and result static rust libraries. This is an implementation of my thoughts in https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html. When compiling a library, we still retain the "lib" option, although now there are "rlib", "staticlib", and "dylib" as options for crate_type (and these are stackable). The idea of "lib" is to generate the "compiler default" instead of having too choose (although all are interchangeable). For now I have left the "complier default" to be a dynamic library for size reasons. Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a dynamic object. I chose this for size reasons, but also because you're probably not going to be embedding the rustc compiler anywhere any time soon. Other than the options outlined above, there are a few defaults/preferences that are now opinionated in the compiler: * If both a .dylib and .rlib are found for a rust library, the compiler will prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option * If generating a "lib", the compiler will generate a dynamic library. This is overridable by explicitly saying what flavor you'd like (rlib, staticlib, dylib). * If no options are passed to the command line, and no crate_type is found in the destination crate, then an executable is generated With this change, you can successfully build a rust program with 0 dynamic dependencies on rust libraries. There is still a dynamic dependency on librustrt, but I plan on removing that in a subsequent commit. This change includes no tests just yet. Our current testing infrastructure/harnesses aren't very amenable to doing flavorful things with linking, so I'm planning on adding a new mode of testing which I believe belongs as a separate commit. Closes #552
2013-11-15 16:03:29 -06:00
self.gate_feature("link_args", i.span,
"the `link_args` attribute is not portable \
across platforms, it is recommended to \
use `#[link(name = \"foo\")]` instead")
}
if foreign_module.abi == RustIntrinsic {
self.gate_feature("intrinsics",
i.span,
"intrinsics are subject to change")
}
Add generation of static libraries to rustc This commit implements the support necessary for generating both intermediate and result static rust libraries. This is an implementation of my thoughts in https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html. When compiling a library, we still retain the "lib" option, although now there are "rlib", "staticlib", and "dylib" as options for crate_type (and these are stackable). The idea of "lib" is to generate the "compiler default" instead of having too choose (although all are interchangeable). For now I have left the "complier default" to be a dynamic library for size reasons. Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a dynamic object. I chose this for size reasons, but also because you're probably not going to be embedding the rustc compiler anywhere any time soon. Other than the options outlined above, there are a few defaults/preferences that are now opinionated in the compiler: * If both a .dylib and .rlib are found for a rust library, the compiler will prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option * If generating a "lib", the compiler will generate a dynamic library. This is overridable by explicitly saying what flavor you'd like (rlib, staticlib, dylib). * If no options are passed to the command line, and no crate_type is found in the destination crate, then an executable is generated With this change, you can successfully build a rust program with 0 dynamic dependencies on rust libraries. There is still a dynamic dependency on librustrt, but I plan on removing that in a subsequent commit. This change includes no tests just yet. Our current testing infrastructure/harnesses aren't very amenable to doing flavorful things with linking, so I'm planning on adding a new mode of testing which I believe belongs as a separate commit. Closes #552
2013-11-15 16:03:29 -06:00
}
2013-12-25 12:10:33 -06:00
ast::ItemFn(..) => {
2014-12-10 21:46:38 -06:00
if attr::contains_name(i.attrs[], "plugin_registrar") {
self.gate_feature("plugin_registrar", i.span,
"compiler plugins are experimental and possibly buggy");
2013-12-25 12:10:33 -06:00
}
}
ast::ItemStruct(..) => {
2014-12-10 21:46:38 -06:00
if attr::contains_name(i.attrs[], "simd") {
2014-01-22 19:25:22 -06:00
self.gate_feature("simd", i.span,
"SIMD types are experimental and possibly buggy");
}
2014-01-22 19:25:22 -06:00
}
ast::ItemImpl(_, _, _, _, ref items) => {
if attr::contains_name(i.attrs[],
"unsafe_destructor") {
self.gate_feature("unsafe_destructor",
i.span,
"`#[unsafe_destructor]` allows too \
many unsafe patterns and may be \
removed in the future");
}
for item in items.iter() {
match *item {
ast::MethodImplItem(_) => {}
ast::TypeImplItem(ref typedef) => {
self.gate_feature("associated_types",
typedef.span,
"associated types are \
experimental")
}
}
}
}
_ => {}
}
visit::walk_item(self, i);
}
fn visit_trait_item(&mut self, trait_item: &ast::TraitItem) {
match *trait_item {
ast::RequiredMethod(_) | ast::ProvidedMethod(_) => {}
ast::TypeTraitItem(ref ti) => {
self.gate_feature("associated_types",
ti.ty_param.span,
"associated types are experimental")
}
}
}
fn visit_foreign_item(&mut self, i: &ast::ForeignItem) {
2014-12-10 21:46:38 -06:00
if attr::contains_name(i.attrs[], "linkage") {
self.gate_feature("linkage", i.span,
"the `linkage` attribute is experimental \
and not portable across platforms")
}
let links_to_llvm = match attr::first_attr_value_str_by_name(i.attrs[], "link_name") {
Some(val) => val.get().starts_with("llvm."),
_ => false
};
if links_to_llvm {
self.gate_feature("link_llvm_intrinsics", i.span,
"linking to LLVM intrinsics is experimental");
}
visit::walk_foreign_item(self, i)
}
fn visit_ty(&mut self, t: &ast::Ty) {
if let ast::TyClosure(ref closure) = t.node {
// this used to be blocked by a feature gate, but it should just
// be plain impossible right now
assert!(closure.onceness != ast::Once);
}
visit::walk_ty(self, t);
}
fn visit_expr(&mut self, e: &ast::Expr) {
match e.node {
ast::ExprRange(..) => {
self.gate_feature("slicing_syntax",
e.span,
"range syntax is experimental");
}
_ => {}
}
visit::walk_expr(self, e);
}
fn visit_generics(&mut self, generics: &ast::Generics) {
for type_parameter in generics.ty_params.iter() {
match type_parameter.default {
2014-09-07 12:09:06 -05:00
Some(ref ty) => {
self.gate_feature("default_type_params", ty.span,
"default type parameters are \
experimental and possibly buggy");
}
None => {}
}
}
visit::walk_generics(self, generics);
}
fn visit_attribute(&mut self, attr: &ast::Attribute) {
2014-09-07 12:09:06 -05:00
if attr::contains_name(slice::ref_slice(attr), "lang") {
self.gate_feature("lang_items",
attr.span,
"language items are subject to change");
}
}
fn visit_pat(&mut self, pattern: &ast::Pat) {
match pattern.node {
ast::PatVec(_, Some(_), ref last) if !last.is_empty() => {
self.gate_feature("advanced_slice_patterns",
pattern.span,
"multiple-element slice matches anywhere \
but at the end of a slice (e.g. \
`[0, ..xs, 0]` are experimental")
}
_ => {}
}
visit::walk_pat(self, pattern)
}
fn visit_fn(&mut self,
fn_kind: visit::FnKind<'v>,
fn_decl: &'v ast::FnDecl,
block: &'v ast::Block,
span: Span,
_node_id: NodeId) {
match fn_kind {
visit::FkItemFn(_, _, _, abi) if abi == RustIntrinsic => {
self.gate_feature("intrinsics",
span,
"intrinsics are subject to change")
}
_ => {}
}
visit::walk_fn(self, fn_kind, fn_decl, block, span);
}
}
fn check_crate_inner<F>(cm: &CodeMap, span_handler: &SpanHandler, krate: &ast::Crate,
check: F)
-> (Features, Vec<Span>)
where F: FnOnce(&mut Context, &ast::Crate)
{
let mut cx = Context {
features: Vec::new(),
2014-09-10 19:55:42 -05:00
span_handler: span_handler,
cm: cm,
};
2014-09-10 19:55:42 -05:00
let mut unknown_features = Vec::new();
for attr in krate.attrs.iter() {
if !attr.check_name("feature") {
continue
}
match attr.meta_item_list() {
None => {
2014-09-10 19:55:42 -05:00
span_handler.span_err(attr.span, "malformed feature attribute, \
expected #![feature(...)]");
}
Some(list) => {
2014-09-07 12:09:06 -05:00
for mi in list.iter() {
let name = match mi.node {
ast::MetaWord(ref word) => (*word).clone(),
_ => {
2014-09-10 19:55:42 -05:00
span_handler.span_err(mi.span,
"malformed feature, expected just \
one word");
continue
}
};
match KNOWN_FEATURES.iter()
.find(|& &(n, _)| name == n) {
Fix orphan checking (cc #19470). (This is not a complete fix of #19470 because of the backwards compatibility feature gate.) This is a [breaking-change]. The new rules require that, for an impl of a trait defined in some other crate, two conditions must hold: 1. Some type must be local. 2. Every type parameter must appear "under" some local type. Here are some examples that are legal: ```rust struct MyStruct<T> { ... } // Here `T` appears "under' `MyStruct`. impl<T> Clone for MyStruct<T> { } // Here `T` appears "under' `MyStruct` as well. Note that it also appears // elsewhere. impl<T> Iterator<T> for MyStruct<T> { } ``` Here is an illegal example: ```rust // Here `U` does not appear "under" `MyStruct` or any other local type. // We call `U` "uncovered". impl<T,U> Iterator<U> for MyStruct<T> { } ``` There are a couple of ways to rewrite this last example so that it is legal: 1. In some cases, the uncovered type parameter (here, `U`) should be converted into an associated type. This is however a non-local change that requires access to the original trait. Also, associated types are not fully baked. 2. Add `U` as a type parameter of `MyStruct`: ```rust struct MyStruct<T,U> { ... } impl<T,U> Iterator<U> for MyStruct<T,U> { } ``` 3. Create a newtype wrapper for `U` ```rust impl<T,U> Iterator<Wrapper<U>> for MyStruct<T,U> { } ``` Because associated types are not fully baked, which in the case of the `Hash` trait makes adhering to this rule impossible, you can temporarily disable this rule in your crate by using `#![feature(old_orphan_check)]`. Note that the `old_orphan_check` feature will be removed before 1.0 is released.
2014-12-26 02:30:51 -06:00
Some(&(name, Active)) => {
cx.features.push(name);
}
Some(&(name, Deprecated)) => {
cx.features.push(name);
span_handler.span_warn(
mi.span,
"feature is deprecated and will only be available \
for a limited time, please rewrite code that relies on it");
}
Some(&(_, Removed)) => {
2014-09-10 19:55:42 -05:00
span_handler.span_err(mi.span, "feature has been removed");
}
Some(&(_, Accepted)) => {
2014-09-10 19:55:42 -05:00
span_handler.span_warn(mi.span, "feature has been added to Rust, \
directive not necessary");
}
None => {
2014-09-10 19:55:42 -05:00
unknown_features.push(mi.span);
}
}
}
}
}
}
check(&mut cx, krate);
2014-09-10 19:55:42 -05:00
(Features {
default_type_params: cx.has_feature("default_type_params"),
unboxed_closures: cx.has_feature("unboxed_closures"),
2014-09-10 19:55:42 -05:00
rustc_diagnostic_macros: cx.has_feature("rustc_diagnostic_macros"),
import_shadowing: cx.has_feature("import_shadowing"),
visible_private_types: cx.has_feature("visible_private_types"),
quote: cx.has_feature("quote"),
opt_out_copy: cx.has_feature("opt_out_copy"),
Fix orphan checking (cc #19470). (This is not a complete fix of #19470 because of the backwards compatibility feature gate.) This is a [breaking-change]. The new rules require that, for an impl of a trait defined in some other crate, two conditions must hold: 1. Some type must be local. 2. Every type parameter must appear "under" some local type. Here are some examples that are legal: ```rust struct MyStruct<T> { ... } // Here `T` appears "under' `MyStruct`. impl<T> Clone for MyStruct<T> { } // Here `T` appears "under' `MyStruct` as well. Note that it also appears // elsewhere. impl<T> Iterator<T> for MyStruct<T> { } ``` Here is an illegal example: ```rust // Here `U` does not appear "under" `MyStruct` or any other local type. // We call `U` "uncovered". impl<T,U> Iterator<U> for MyStruct<T> { } ``` There are a couple of ways to rewrite this last example so that it is legal: 1. In some cases, the uncovered type parameter (here, `U`) should be converted into an associated type. This is however a non-local change that requires access to the original trait. Also, associated types are not fully baked. 2. Add `U` as a type parameter of `MyStruct`: ```rust struct MyStruct<T,U> { ... } impl<T,U> Iterator<U> for MyStruct<T,U> { } ``` 3. Create a newtype wrapper for `U` ```rust impl<T,U> Iterator<Wrapper<U>> for MyStruct<T,U> { } ``` Because associated types are not fully baked, which in the case of the `Hash` trait makes adhering to this rule impossible, you can temporarily disable this rule in your crate by using `#![feature(old_orphan_check)]`. Note that the `old_orphan_check` feature will be removed before 1.0 is released.
2014-12-26 02:30:51 -06:00
old_orphan_check: cx.has_feature("old_orphan_check"),
2014-09-10 19:55:42 -05:00
},
unknown_features)
}
pub fn check_crate_macros(cm: &CodeMap, span_handler: &SpanHandler, krate: &ast::Crate)
-> (Features, Vec<Span>) {
check_crate_inner(cm, span_handler, krate,
|ctx, krate| visit::walk_crate(&mut MacroVisitor { context: ctx }, krate))
}
pub fn check_crate(cm: &CodeMap, span_handler: &SpanHandler, krate: &ast::Crate)
-> (Features, Vec<Span>) {
check_crate_inner(cm, span_handler, krate,
|ctx, krate| visit::walk_crate(&mut PostExpansionVisitor { context: ctx },
krate))
}