2015-02-05 20:28:17 +00:00
|
|
|
// Copyright 2012-2015 The Rust Project Developers. See the COPYRIGHT
|
2012-12-04 00:48:01 +00:00
|
|
|
// 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.
|
|
|
|
|
2012-07-04 21:53:12 +00:00
|
|
|
//! Validates all used crates and extern libraries and loads their metadata
|
2011-03-15 23:30:43 +00:00
|
|
|
|
2015-11-24 22:00:26 +00:00
|
|
|
use cstore::{self, CStore, CrateSource, MetadataBlob};
|
2016-10-20 04:31:14 +00:00
|
|
|
use locator::{self, CratePaths};
|
2016-09-16 14:25:54 +00:00
|
|
|
use schema::CrateRoot;
|
2015-11-24 22:00:26 +00:00
|
|
|
|
2016-08-31 11:00:29 +00:00
|
|
|
use rustc::hir::def_id::{CrateNum, DefIndex};
|
2016-03-29 05:50:44 +00:00
|
|
|
use rustc::hir::svh::Svh;
|
2016-10-28 06:52:45 +00:00
|
|
|
use rustc::middle::cstore::DepKind;
|
2015-11-24 22:00:26 +00:00
|
|
|
use rustc::session::{config, Session};
|
2016-09-28 02:26:08 +00:00
|
|
|
use rustc_back::PanicStrategy;
|
2015-11-24 22:00:26 +00:00
|
|
|
use rustc::session::search_paths::PathKind;
|
2016-09-16 02:52:09 +00:00
|
|
|
use rustc::middle;
|
2016-03-16 09:50:38 +00:00
|
|
|
use rustc::middle::cstore::{CrateStore, validate_crate_name, ExternCrate};
|
2016-11-08 03:02:55 +00:00
|
|
|
use rustc::util::nodemap::{FxHashMap, FxHashSet};
|
rustc: Implement #[link(cfg(..))] and crt-static
This commit is an implementation of [RFC 1721] which adds a new target feature
to the compiler, `crt-static`, which can be used to select how the C runtime for
a target is linked. Most targets dynamically linke the C runtime by default with
the notable exception of some of the musl targets.
[RFC 1721]: https://github.com/rust-lang/rfcs/blob/master/text/1721-crt-static.md
This commit first adds the new target-feature, `crt-static`. If enabled, then
the `cfg(target_feature = "crt-static")` will be available. Targets like musl
will have this enabled by default. This feature can be controlled through the
standard target-feature interface, `-C target-feature=+crt-static` or
`-C target-feature=-crt-static`.
Next this adds an gated and unstable `#[link(cfg(..))]` feature to enable the
`crt-static` semantics we want with libc. The exact behavior of this attribute
is a little squishy, but it's intended to be a forever-unstable
implementation detail of the liblibc crate.
Specifically the `#[link(cfg(..))]` annotation means that the `#[link]`
directive is only active in a compilation unit if that `cfg` value is satisfied.
For example when compiling an rlib, these directives are just encoded and
ignored for dylibs, and all staticlibs are continued to be put into the rlib as
usual. When placing that rlib into a staticlib, executable, or dylib, however,
the `cfg` is evaluated *as if it were defined in the final artifact* and the
library is decided to be linked or not.
Essentially, what'll happen is:
* On MSVC with `-C target-feature=-crt-static`, the `msvcrt.lib` library will be
linked to.
* On MSVC with `-C target-feature=+crt-static`, the `libcmt.lib` library will be
linked to.
* On musl with `-C target-feature=-crt-static`, the object files in liblibc.rlib
are removed and `-lc` is passed instead.
* On musl with `-C target-feature=+crt-static`, the object files in liblibc.rlib
are used and `-lc` is not passed.
This commit does **not** include an update to the liblibc module to implement
these changes. I plan to do that just after the 1.14.0 beta release is cut to
ensure we get ample time to test this feature.
cc #37406
2016-10-31 23:40:13 +00:00
|
|
|
use rustc::middle::cstore::NativeLibrary;
|
2016-10-19 19:35:32 +00:00
|
|
|
use rustc::hir::map::Definitions;
|
2012-12-23 22:41:37 +00:00
|
|
|
|
2015-06-25 17:07:01 +00:00
|
|
|
use std::cell::{RefCell, Cell};
|
2016-09-15 08:04:00 +00:00
|
|
|
use std::ops::Deref;
|
2015-04-16 06:21:13 +00:00
|
|
|
use std::path::PathBuf;
|
2014-03-27 17:28:38 +00:00
|
|
|
use std::rc::Rc;
|
2016-10-27 09:18:45 +00:00
|
|
|
use std::{cmp, fs};
|
2015-04-16 06:21:13 +00:00
|
|
|
|
2013-07-20 01:42:11 +00:00
|
|
|
use syntax::ast;
|
2016-02-05 12:13:36 +00:00
|
|
|
use syntax::abi::Abi;
|
2016-08-23 03:54:53 +00:00
|
|
|
use syntax::attr;
|
2016-10-17 07:46:25 +00:00
|
|
|
use syntax::ext::base::SyntaxExtension;
|
rustc: Implement #[link(cfg(..))] and crt-static
This commit is an implementation of [RFC 1721] which adds a new target feature
to the compiler, `crt-static`, which can be used to select how the C runtime for
a target is linked. Most targets dynamically linke the C runtime by default with
the notable exception of some of the musl targets.
[RFC 1721]: https://github.com/rust-lang/rfcs/blob/master/text/1721-crt-static.md
This commit first adds the new target-feature, `crt-static`. If enabled, then
the `cfg(target_feature = "crt-static")` will be available. Targets like musl
will have this enabled by default. This feature can be controlled through the
standard target-feature interface, `-C target-feature=+crt-static` or
`-C target-feature=-crt-static`.
Next this adds an gated and unstable `#[link(cfg(..))]` feature to enable the
`crt-static` semantics we want with libc. The exact behavior of this attribute
is a little squishy, but it's intended to be a forever-unstable
implementation detail of the liblibc crate.
Specifically the `#[link(cfg(..))]` annotation means that the `#[link]`
directive is only active in a compilation unit if that `cfg` value is satisfied.
For example when compiling an rlib, these directives are just encoded and
ignored for dylibs, and all staticlibs are continued to be put into the rlib as
usual. When placing that rlib into a staticlib, executable, or dylib, however,
the `cfg` is evaluated *as if it were defined in the final artifact* and the
library is decided to be linked or not.
Essentially, what'll happen is:
* On MSVC with `-C target-feature=-crt-static`, the `msvcrt.lib` library will be
linked to.
* On MSVC with `-C target-feature=+crt-static`, the `libcmt.lib` library will be
linked to.
* On musl with `-C target-feature=-crt-static`, the object files in liblibc.rlib
are removed and `-lc` is passed instead.
* On musl with `-C target-feature=+crt-static`, the object files in liblibc.rlib
are used and `-lc` is not passed.
This commit does **not** include an update to the liblibc module to implement
these changes. I plan to do that just after the 1.14.0 beta release is cut to
ensure we get ample time to test this feature.
cc #37406
2016-10-31 23:40:13 +00:00
|
|
|
use syntax::feature_gate::{self, GateIssue};
|
2016-11-16 10:52:37 +00:00
|
|
|
use syntax::symbol::Symbol;
|
2016-10-28 06:52:45 +00:00
|
|
|
use syntax_pos::{Span, DUMMY_SP};
|
2014-12-21 06:36:50 +00:00
|
|
|
use log;
|
2011-03-15 23:30:43 +00:00
|
|
|
|
2016-10-20 04:21:25 +00:00
|
|
|
pub struct Library {
|
|
|
|
pub dylib: Option<(PathBuf, PathKind)>,
|
|
|
|
pub rlib: Option<(PathBuf, PathKind)>,
|
2016-11-10 02:57:30 +00:00
|
|
|
pub rmeta: Option<(PathBuf, PathKind)>,
|
2016-10-20 04:21:25 +00:00
|
|
|
pub metadata: MetadataBlob,
|
|
|
|
}
|
|
|
|
|
2016-09-16 02:52:09 +00:00
|
|
|
pub struct CrateLoader<'a> {
|
|
|
|
pub sess: &'a Session,
|
2015-11-21 19:39:05 +00:00
|
|
|
cstore: &'a CStore,
|
2016-08-31 11:00:29 +00:00
|
|
|
next_crate_num: CrateNum,
|
2016-11-08 03:02:55 +00:00
|
|
|
foreign_item_map: FxHashMap<String, Vec<ast::NodeId>>,
|
2016-11-16 10:52:37 +00:00
|
|
|
local_crate_name: Symbol,
|
2014-04-07 19:14:33 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
fn dump_crates(cstore: &CStore) {
|
2015-06-25 17:07:01 +00:00
|
|
|
info!("resolved crates:");
|
2016-10-27 05:03:11 +00:00
|
|
|
cstore.iter_crate_data(|_, data| {
|
2015-06-25 17:07:01 +00:00
|
|
|
info!(" name: {}", data.name());
|
|
|
|
info!(" cnum: {}", data.cnum);
|
|
|
|
info!(" hash: {}", data.hash());
|
2016-10-27 09:18:45 +00:00
|
|
|
info!(" reqd: {:?}", data.dep_kind.get());
|
2016-11-10 02:57:30 +00:00
|
|
|
let CrateSource { dylib, rlib, rmeta } = data.source.clone();
|
2016-10-27 05:03:11 +00:00
|
|
|
dylib.map(|dl| info!(" dylib: {}", dl.0.display()));
|
|
|
|
rlib.map(|rl| info!(" rlib: {}", rl.0.display()));
|
2016-11-10 02:57:30 +00:00
|
|
|
rmeta.map(|rl| info!(" rmeta: {}", rl.0.display()));
|
2016-11-10 21:00:33 +00:00
|
|
|
});
|
2012-04-09 22:06:38 +00:00
|
|
|
}
|
|
|
|
|
2016-04-17 22:30:55 +00:00
|
|
|
#[derive(Debug)]
|
2016-09-08 16:05:50 +00:00
|
|
|
struct ExternCrateInfo {
|
2016-11-16 10:52:37 +00:00
|
|
|
ident: Symbol,
|
|
|
|
name: Symbol,
|
2013-12-25 18:10:33 +00:00
|
|
|
id: ast::NodeId,
|
2016-10-28 05:56:06 +00:00
|
|
|
dep_kind: DepKind,
|
2013-12-25 18:10:33 +00:00
|
|
|
}
|
|
|
|
|
librustc: Make `Copy` opt-in.
This change makes the compiler no longer infer whether types (structures
and enumerations) implement the `Copy` trait (and thus are implicitly
copyable). Rather, you must implement `Copy` yourself via `impl Copy for
MyType {}`.
A new warning has been added, `missing_copy_implementations`, to warn
you if a non-generic public type has been added that could have
implemented `Copy` but didn't.
For convenience, you may *temporarily* opt out of this behavior by using
`#![feature(opt_out_copy)]`. Note though that this feature gate will never be
accepted and will be removed by the time that 1.0 is released, so you should
transition your code away from using it.
This breaks code like:
#[deriving(Show)]
struct Point2D {
x: int,
y: int,
}
fn main() {
let mypoint = Point2D {
x: 1,
y: 1,
};
let otherpoint = mypoint;
println!("{}{}", mypoint, otherpoint);
}
Change this code to:
#[deriving(Show)]
struct Point2D {
x: int,
y: int,
}
impl Copy for Point2D {}
fn main() {
let mypoint = Point2D {
x: 1,
y: 1,
};
let otherpoint = mypoint;
println!("{}{}", mypoint, otherpoint);
}
This is the backwards-incompatible part of #13231.
Part of RFC #3.
[breaking-change]
2014-12-06 01:01:33 +00:00
|
|
|
fn register_native_lib(sess: &Session,
|
2015-11-21 19:39:05 +00:00
|
|
|
cstore: &CStore,
|
librustc: Make `Copy` opt-in.
This change makes the compiler no longer infer whether types (structures
and enumerations) implement the `Copy` trait (and thus are implicitly
copyable). Rather, you must implement `Copy` yourself via `impl Copy for
MyType {}`.
A new warning has been added, `missing_copy_implementations`, to warn
you if a non-generic public type has been added that could have
implemented `Copy` but didn't.
For convenience, you may *temporarily* opt out of this behavior by using
`#![feature(opt_out_copy)]`. Note though that this feature gate will never be
accepted and will be removed by the time that 1.0 is released, so you should
transition your code away from using it.
This breaks code like:
#[deriving(Show)]
struct Point2D {
x: int,
y: int,
}
fn main() {
let mypoint = Point2D {
x: 1,
y: 1,
};
let otherpoint = mypoint;
println!("{}{}", mypoint, otherpoint);
}
Change this code to:
#[deriving(Show)]
struct Point2D {
x: int,
y: int,
}
impl Copy for Point2D {}
fn main() {
let mypoint = Point2D {
x: 1,
y: 1,
};
let otherpoint = mypoint;
println!("{}{}", mypoint, otherpoint);
}
This is the backwards-incompatible part of #13231.
Part of RFC #3.
[breaking-change]
2014-12-06 01:01:33 +00:00
|
|
|
span: Option<Span>,
|
rustc: Implement #[link(cfg(..))] and crt-static
This commit is an implementation of [RFC 1721] which adds a new target feature
to the compiler, `crt-static`, which can be used to select how the C runtime for
a target is linked. Most targets dynamically linke the C runtime by default with
the notable exception of some of the musl targets.
[RFC 1721]: https://github.com/rust-lang/rfcs/blob/master/text/1721-crt-static.md
This commit first adds the new target-feature, `crt-static`. If enabled, then
the `cfg(target_feature = "crt-static")` will be available. Targets like musl
will have this enabled by default. This feature can be controlled through the
standard target-feature interface, `-C target-feature=+crt-static` or
`-C target-feature=-crt-static`.
Next this adds an gated and unstable `#[link(cfg(..))]` feature to enable the
`crt-static` semantics we want with libc. The exact behavior of this attribute
is a little squishy, but it's intended to be a forever-unstable
implementation detail of the liblibc crate.
Specifically the `#[link(cfg(..))]` annotation means that the `#[link]`
directive is only active in a compilation unit if that `cfg` value is satisfied.
For example when compiling an rlib, these directives are just encoded and
ignored for dylibs, and all staticlibs are continued to be put into the rlib as
usual. When placing that rlib into a staticlib, executable, or dylib, however,
the `cfg` is evaluated *as if it were defined in the final artifact* and the
library is decided to be linked or not.
Essentially, what'll happen is:
* On MSVC with `-C target-feature=-crt-static`, the `msvcrt.lib` library will be
linked to.
* On MSVC with `-C target-feature=+crt-static`, the `libcmt.lib` library will be
linked to.
* On musl with `-C target-feature=-crt-static`, the object files in liblibc.rlib
are removed and `-lc` is passed instead.
* On musl with `-C target-feature=+crt-static`, the object files in liblibc.rlib
are used and `-lc` is not passed.
This commit does **not** include an update to the liblibc module to implement
these changes. I plan to do that just after the 1.14.0 beta release is cut to
ensure we get ample time to test this feature.
cc #37406
2016-10-31 23:40:13 +00:00
|
|
|
lib: NativeLibrary) {
|
2016-11-16 10:52:37 +00:00
|
|
|
if lib.name.as_str().is_empty() {
|
2014-10-21 06:04:16 +00:00
|
|
|
match span {
|
|
|
|
Some(span) => {
|
2016-08-24 12:13:51 +00:00
|
|
|
struct_span_err!(sess, span, E0454,
|
|
|
|
"#[link(name = \"\")] given with empty name")
|
|
|
|
.span_label(span, &format!("empty name given"))
|
|
|
|
.emit();
|
2014-10-21 06:04:16 +00:00
|
|
|
}
|
|
|
|
None => {
|
|
|
|
sess.err("empty library name given via `-l`");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return
|
|
|
|
}
|
2014-07-23 18:56:36 +00:00
|
|
|
let is_osx = sess.target.target.options.is_like_osx;
|
rustc: Implement #[link(cfg(..))] and crt-static
This commit is an implementation of [RFC 1721] which adds a new target feature
to the compiler, `crt-static`, which can be used to select how the C runtime for
a target is linked. Most targets dynamically linke the C runtime by default with
the notable exception of some of the musl targets.
[RFC 1721]: https://github.com/rust-lang/rfcs/blob/master/text/1721-crt-static.md
This commit first adds the new target-feature, `crt-static`. If enabled, then
the `cfg(target_feature = "crt-static")` will be available. Targets like musl
will have this enabled by default. This feature can be controlled through the
standard target-feature interface, `-C target-feature=+crt-static` or
`-C target-feature=-crt-static`.
Next this adds an gated and unstable `#[link(cfg(..))]` feature to enable the
`crt-static` semantics we want with libc. The exact behavior of this attribute
is a little squishy, but it's intended to be a forever-unstable
implementation detail of the liblibc crate.
Specifically the `#[link(cfg(..))]` annotation means that the `#[link]`
directive is only active in a compilation unit if that `cfg` value is satisfied.
For example when compiling an rlib, these directives are just encoded and
ignored for dylibs, and all staticlibs are continued to be put into the rlib as
usual. When placing that rlib into a staticlib, executable, or dylib, however,
the `cfg` is evaluated *as if it were defined in the final artifact* and the
library is decided to be linked or not.
Essentially, what'll happen is:
* On MSVC with `-C target-feature=-crt-static`, the `msvcrt.lib` library will be
linked to.
* On MSVC with `-C target-feature=+crt-static`, the `libcmt.lib` library will be
linked to.
* On musl with `-C target-feature=-crt-static`, the object files in liblibc.rlib
are removed and `-lc` is passed instead.
* On musl with `-C target-feature=+crt-static`, the object files in liblibc.rlib
are used and `-lc` is not passed.
This commit does **not** include an update to the liblibc module to implement
these changes. I plan to do that just after the 1.14.0 beta release is cut to
ensure we get ample time to test this feature.
cc #37406
2016-10-31 23:40:13 +00:00
|
|
|
if lib.kind == cstore::NativeFramework && !is_osx {
|
2014-10-21 06:04:16 +00:00
|
|
|
let msg = "native frameworks are only available on OSX targets";
|
|
|
|
match span {
|
rustc: Implement #[link(cfg(..))] and crt-static
This commit is an implementation of [RFC 1721] which adds a new target feature
to the compiler, `crt-static`, which can be used to select how the C runtime for
a target is linked. Most targets dynamically linke the C runtime by default with
the notable exception of some of the musl targets.
[RFC 1721]: https://github.com/rust-lang/rfcs/blob/master/text/1721-crt-static.md
This commit first adds the new target-feature, `crt-static`. If enabled, then
the `cfg(target_feature = "crt-static")` will be available. Targets like musl
will have this enabled by default. This feature can be controlled through the
standard target-feature interface, `-C target-feature=+crt-static` or
`-C target-feature=-crt-static`.
Next this adds an gated and unstable `#[link(cfg(..))]` feature to enable the
`crt-static` semantics we want with libc. The exact behavior of this attribute
is a little squishy, but it's intended to be a forever-unstable
implementation detail of the liblibc crate.
Specifically the `#[link(cfg(..))]` annotation means that the `#[link]`
directive is only active in a compilation unit if that `cfg` value is satisfied.
For example when compiling an rlib, these directives are just encoded and
ignored for dylibs, and all staticlibs are continued to be put into the rlib as
usual. When placing that rlib into a staticlib, executable, or dylib, however,
the `cfg` is evaluated *as if it were defined in the final artifact* and the
library is decided to be linked or not.
Essentially, what'll happen is:
* On MSVC with `-C target-feature=-crt-static`, the `msvcrt.lib` library will be
linked to.
* On MSVC with `-C target-feature=+crt-static`, the `libcmt.lib` library will be
linked to.
* On musl with `-C target-feature=-crt-static`, the object files in liblibc.rlib
are removed and `-lc` is passed instead.
* On musl with `-C target-feature=+crt-static`, the object files in liblibc.rlib
are used and `-lc` is not passed.
This commit does **not** include an update to the liblibc module to implement
these changes. I plan to do that just after the 1.14.0 beta release is cut to
ensure we get ample time to test this feature.
cc #37406
2016-10-31 23:40:13 +00:00
|
|
|
Some(span) => span_err!(sess, span, E0455, "{}", msg),
|
2014-10-21 06:04:16 +00:00
|
|
|
None => sess.err(msg),
|
|
|
|
}
|
|
|
|
}
|
rustc: Implement #[link(cfg(..))] and crt-static
This commit is an implementation of [RFC 1721] which adds a new target feature
to the compiler, `crt-static`, which can be used to select how the C runtime for
a target is linked. Most targets dynamically linke the C runtime by default with
the notable exception of some of the musl targets.
[RFC 1721]: https://github.com/rust-lang/rfcs/blob/master/text/1721-crt-static.md
This commit first adds the new target-feature, `crt-static`. If enabled, then
the `cfg(target_feature = "crt-static")` will be available. Targets like musl
will have this enabled by default. This feature can be controlled through the
standard target-feature interface, `-C target-feature=+crt-static` or
`-C target-feature=-crt-static`.
Next this adds an gated and unstable `#[link(cfg(..))]` feature to enable the
`crt-static` semantics we want with libc. The exact behavior of this attribute
is a little squishy, but it's intended to be a forever-unstable
implementation detail of the liblibc crate.
Specifically the `#[link(cfg(..))]` annotation means that the `#[link]`
directive is only active in a compilation unit if that `cfg` value is satisfied.
For example when compiling an rlib, these directives are just encoded and
ignored for dylibs, and all staticlibs are continued to be put into the rlib as
usual. When placing that rlib into a staticlib, executable, or dylib, however,
the `cfg` is evaluated *as if it were defined in the final artifact* and the
library is decided to be linked or not.
Essentially, what'll happen is:
* On MSVC with `-C target-feature=-crt-static`, the `msvcrt.lib` library will be
linked to.
* On MSVC with `-C target-feature=+crt-static`, the `libcmt.lib` library will be
linked to.
* On musl with `-C target-feature=-crt-static`, the object files in liblibc.rlib
are removed and `-lc` is passed instead.
* On musl with `-C target-feature=+crt-static`, the object files in liblibc.rlib
are used and `-lc` is not passed.
This commit does **not** include an update to the liblibc module to implement
these changes. I plan to do that just after the 1.14.0 beta release is cut to
ensure we get ample time to test this feature.
cc #37406
2016-10-31 23:40:13 +00:00
|
|
|
if lib.cfg.is_some() && !sess.features.borrow().link_cfg {
|
|
|
|
feature_gate::emit_feature_err(&sess.parse_sess,
|
|
|
|
"link_cfg",
|
|
|
|
span.unwrap(),
|
|
|
|
GateIssue::Language,
|
|
|
|
"is feature gated");
|
|
|
|
}
|
|
|
|
cstore.add_used_library(lib);
|
2014-10-21 06:04:16 +00:00
|
|
|
}
|
|
|
|
|
2015-02-12 02:43:16 +00:00
|
|
|
// Extra info about a crate loaded for plugins or exported macros.
|
|
|
|
struct ExtensionCrate {
|
2015-01-01 03:48:39 +00:00
|
|
|
metadata: PMDSource,
|
2015-02-27 05:00:43 +00:00
|
|
|
dylib: Option<PathBuf>,
|
2015-01-01 03:48:39 +00:00
|
|
|
target_only: bool,
|
|
|
|
}
|
|
|
|
|
|
|
|
enum PMDSource {
|
2016-06-28 20:41:09 +00:00
|
|
|
Registered(Rc<cstore::CrateMetadata>),
|
2016-10-20 04:21:25 +00:00
|
|
|
Owned(Library),
|
2015-01-01 03:48:39 +00:00
|
|
|
}
|
|
|
|
|
2016-09-15 08:04:00 +00:00
|
|
|
impl Deref for PMDSource {
|
|
|
|
type Target = MetadataBlob;
|
|
|
|
|
|
|
|
fn deref(&self) -> &MetadataBlob {
|
2015-01-01 03:48:39 +00:00
|
|
|
match *self {
|
2016-09-16 14:25:54 +00:00
|
|
|
PMDSource::Registered(ref cmd) => &cmd.blob,
|
2016-09-15 08:04:00 +00:00
|
|
|
PMDSource::Owned(ref lib) => &lib.metadata
|
2015-01-01 03:48:39 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-05-20 21:03:47 +00:00
|
|
|
enum LoadResult {
|
2016-08-31 11:00:29 +00:00
|
|
|
Previous(CrateNum),
|
2016-10-20 04:21:25 +00:00
|
|
|
Loaded(Library),
|
2016-05-20 21:03:47 +00:00
|
|
|
}
|
|
|
|
|
2016-10-19 09:34:19 +00:00
|
|
|
impl<'a> CrateLoader<'a> {
|
2016-10-27 06:36:56 +00:00
|
|
|
pub fn new(sess: &'a Session, cstore: &'a CStore, local_crate_name: &str) -> Self {
|
2016-10-19 09:34:19 +00:00
|
|
|
CrateLoader {
|
2014-12-21 07:02:38 +00:00
|
|
|
sess: sess,
|
2015-11-21 19:39:05 +00:00
|
|
|
cstore: cstore,
|
|
|
|
next_crate_num: cstore.next_crate_num(),
|
2016-11-08 03:02:55 +00:00
|
|
|
foreign_item_map: FxHashMap(),
|
2016-11-16 10:52:37 +00:00
|
|
|
local_crate_name: Symbol::intern(local_crate_name),
|
2014-12-21 07:02:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-09-08 16:05:50 +00:00
|
|
|
fn extract_crate_info(&self, i: &ast::Item) -> Option<ExternCrateInfo> {
|
2014-12-21 06:36:50 +00:00
|
|
|
match i.node {
|
2016-02-09 10:36:51 +00:00
|
|
|
ast::ItemKind::ExternCrate(ref path_opt) => {
|
2015-01-07 00:16:35 +00:00
|
|
|
debug!("resolving extern crate stmt. ident: {} path_opt: {:?}",
|
2015-07-28 16:07:20 +00:00
|
|
|
i.ident, path_opt);
|
2014-12-21 06:36:50 +00:00
|
|
|
let name = match *path_opt {
|
2015-03-19 22:39:03 +00:00
|
|
|
Some(name) => {
|
2015-07-28 16:07:20 +00:00
|
|
|
validate_crate_name(Some(self.sess), &name.as_str(),
|
2014-12-21 06:36:50 +00:00
|
|
|
Some(i.span));
|
2016-11-16 10:52:37 +00:00
|
|
|
name
|
2014-12-21 06:36:50 +00:00
|
|
|
}
|
2016-11-16 10:52:37 +00:00
|
|
|
None => i.ident.name,
|
2014-12-21 06:36:50 +00:00
|
|
|
};
|
2016-09-08 16:05:50 +00:00
|
|
|
Some(ExternCrateInfo {
|
2016-11-16 10:52:37 +00:00
|
|
|
ident: i.ident.name,
|
2014-12-21 06:36:50 +00:00
|
|
|
name: name,
|
2014-12-23 19:33:44 +00:00
|
|
|
id: i.id,
|
2016-10-28 05:56:06 +00:00
|
|
|
dep_kind: if attr::contains_name(&i.attrs, "no_link") {
|
2016-11-27 02:57:15 +00:00
|
|
|
DepKind::UnexportedMacrosOnly
|
2016-10-28 05:56:06 +00:00
|
|
|
} else {
|
|
|
|
DepKind::Explicit
|
|
|
|
},
|
2014-12-21 06:36:50 +00:00
|
|
|
})
|
|
|
|
}
|
|
|
|
_ => None
|
2014-07-01 15:37:54 +00:00
|
|
|
}
|
2014-12-21 06:36:50 +00:00
|
|
|
}
|
|
|
|
|
2016-11-16 10:52:37 +00:00
|
|
|
fn existing_match(&self, name: Symbol, hash: Option<&Svh>, kind: PathKind)
|
2016-08-31 11:00:29 +00:00
|
|
|
-> Option<CrateNum> {
|
2014-12-21 06:36:50 +00:00
|
|
|
let mut ret = None;
|
2015-11-21 19:39:05 +00:00
|
|
|
self.cstore.iter_crate_data(|cnum, data| {
|
2015-03-27 00:35:13 +00:00
|
|
|
if data.name != name { return }
|
2014-12-21 06:36:50 +00:00
|
|
|
|
|
|
|
match hash {
|
|
|
|
Some(hash) if *hash == data.hash() => { ret = Some(cnum); return }
|
|
|
|
Some(..) => return,
|
|
|
|
None => {}
|
|
|
|
}
|
|
|
|
|
2015-01-06 16:46:07 +00:00
|
|
|
// When the hash is None we're dealing with a top-level dependency
|
|
|
|
// in which case we may have a specification on the command line for
|
|
|
|
// this library. Even though an upstream library may have loaded
|
|
|
|
// something of the same name, we have to make sure it was loaded
|
|
|
|
// from the exact same location as well.
|
2014-12-21 06:36:50 +00:00
|
|
|
//
|
|
|
|
// We're also sure to compare *paths*, not actual byte slices. The
|
|
|
|
// `source` stores paths which are normalized which may be different
|
|
|
|
// from the strings on the command line.
|
2015-11-25 15:02:59 +00:00
|
|
|
let source = self.cstore.used_crate_source(cnum);
|
2016-11-16 10:52:37 +00:00
|
|
|
if let Some(locs) = self.sess.opts.externs.get(&*name.as_str()) {
|
2015-01-06 16:46:07 +00:00
|
|
|
let found = locs.iter().any(|l| {
|
2015-04-16 06:21:13 +00:00
|
|
|
let l = fs::canonicalize(l).ok();
|
2015-01-06 16:46:07 +00:00
|
|
|
source.dylib.as_ref().map(|p| &p.0) == l.as_ref() ||
|
|
|
|
source.rlib.as_ref().map(|p| &p.0) == l.as_ref()
|
|
|
|
});
|
|
|
|
if found {
|
|
|
|
ret = Some(cnum);
|
2014-12-21 06:36:50 +00:00
|
|
|
}
|
2015-01-30 17:48:23 +00:00
|
|
|
return
|
2015-01-06 16:46:07 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// Alright, so we've gotten this far which means that `data` has the
|
|
|
|
// right name, we don't have a hash, and we don't have a --extern
|
|
|
|
// pointing for ourselves. We're still not quite yet done because we
|
|
|
|
// have to make sure that this crate was found in the crate lookup
|
|
|
|
// path (this is a top-level dependency) as we don't want to
|
|
|
|
// implicitly load anything inside the dependency lookup path.
|
|
|
|
let prev_kind = source.dylib.as_ref().or(source.rlib.as_ref())
|
|
|
|
.unwrap().1;
|
|
|
|
if ret.is_none() && (prev_kind == kind || prev_kind == PathKind::All) {
|
|
|
|
ret = Some(cnum);
|
2014-12-21 06:36:50 +00:00
|
|
|
}
|
|
|
|
});
|
|
|
|
return ret;
|
|
|
|
}
|
2014-04-17 15:52:25 +00:00
|
|
|
|
2016-02-26 21:25:25 +00:00
|
|
|
fn verify_no_symbol_conflicts(&self,
|
|
|
|
span: Span,
|
2016-09-16 14:25:54 +00:00
|
|
|
root: &CrateRoot) {
|
2016-02-26 21:25:25 +00:00
|
|
|
// Check for (potential) conflicts with the local crate
|
2016-09-16 14:25:54 +00:00
|
|
|
if self.local_crate_name == root.name &&
|
2016-11-16 10:52:37 +00:00
|
|
|
self.sess.local_crate_disambiguator() == root.disambiguator {
|
2016-02-26 21:25:25 +00:00
|
|
|
span_fatal!(self.sess, span, E0519,
|
|
|
|
"the current crate is indistinguishable from one of its \
|
|
|
|
dependencies: it has the same crate-name `{}` and was \
|
|
|
|
compiled with the same `-C metadata` arguments. This \
|
|
|
|
will result in symbol conflicts between the two.",
|
2016-09-16 14:25:54 +00:00
|
|
|
root.name)
|
2016-02-26 21:25:25 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// Check for conflicts with any crate loaded so far
|
|
|
|
self.cstore.iter_crate_data(|_, other| {
|
2016-09-16 14:25:54 +00:00
|
|
|
if other.name() == root.name && // same crate-name
|
|
|
|
other.disambiguator() == root.disambiguator && // same crate-disambiguator
|
|
|
|
other.hash() != root.hash { // but different SVH
|
2016-03-22 16:18:30 +00:00
|
|
|
span_fatal!(self.sess, span, E0523,
|
2016-02-26 21:25:25 +00:00
|
|
|
"found two different crates with name `{}` that are \
|
|
|
|
not distinguished by differing `-C metadata`. This \
|
|
|
|
will result in symbol conflicts between the two.",
|
2016-09-16 14:25:54 +00:00
|
|
|
root.name)
|
2016-02-26 21:25:25 +00:00
|
|
|
}
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2014-12-21 06:36:50 +00:00
|
|
|
fn register_crate(&mut self,
|
|
|
|
root: &Option<CratePaths>,
|
2016-11-16 10:52:37 +00:00
|
|
|
ident: Symbol,
|
|
|
|
name: Symbol,
|
2014-12-21 06:36:50 +00:00
|
|
|
span: Span,
|
2016-10-20 04:21:25 +00:00
|
|
|
lib: Library,
|
2016-10-27 09:18:45 +00:00
|
|
|
dep_kind: DepKind)
|
2016-10-27 05:03:11 +00:00
|
|
|
-> (CrateNum, Rc<cstore::CrateMetadata>) {
|
rustc: Implement custom derive (macros 1.1)
This commit is an implementation of [RFC 1681] which adds support to the
compiler for first-class user-define custom `#[derive]` modes with a far more
stable API than plugins have today.
[RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md
The main features added by this commit are:
* A new `rustc-macro` crate-type. This crate type represents one which will
provide custom `derive` implementations and perhaps eventually flower into the
implementation of macros 2.0 as well.
* A new `rustc_macro` crate in the standard distribution. This crate will
provide the runtime interface between macro crates and the compiler. The API
here is particularly conservative right now but has quite a bit of room to
expand into any manner of APIs required by macro authors.
* The ability to load new derive modes through the `#[macro_use]` annotations on
other crates.
All support added here is gated behind the `rustc_macro` feature gate, both for
the library support (the `rustc_macro` crate) as well as the language features.
There are a few minor differences from the implementation outlined in the RFC,
such as the `rustc_macro` crate being available as a dylib and all symbols are
`dlsym`'d directly instead of having a shim compiled. These should only affect
the implementation, however, not the public interface.
This commit also ended up touching a lot of code related to `#[derive]`, making
a few notable changes:
* Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't
sure how to keep this behavior and *not* expose it to custom derive.
* Derive attributes no longer have access to unstable features by default, they
have to opt in on a granular level.
* The `derive(Copy,Clone)` optimization is now done through another "obscure
attribute" which is just intended to ferry along in the compiler that such an
optimization is possible. The `derive(PartialEq,Eq)` optimization was also
updated to do something similar.
---
One part of this PR which needs to be improved before stabilizing are the errors
and exact interfaces here. The error messages are relatively poor quality and
there are surprising spects of this such as `#[derive(PartialEq, Eq, MyTrait)]`
not working by default. The custom attributes added by the compiler end up
becoming unstable again when going through a custom impl.
Hopefully though this is enough to start allowing experimentation on crates.io!
syntax-[breaking-change]
2016-08-23 00:07:11 +00:00
|
|
|
info!("register crate `extern crate {} as {}`", name, ident);
|
2016-09-16 14:25:54 +00:00
|
|
|
let crate_root = lib.metadata.get_root();
|
|
|
|
self.verify_no_symbol_conflicts(span, &crate_root);
|
2015-09-28 04:31:45 +00:00
|
|
|
|
2014-12-21 06:36:50 +00:00
|
|
|
// Claim this crate number and cache it
|
|
|
|
let cnum = self.next_crate_num;
|
2016-08-31 11:00:29 +00:00
|
|
|
self.next_crate_num = CrateNum::from_u32(cnum.as_u32() + 1);
|
2014-12-21 06:36:50 +00:00
|
|
|
|
|
|
|
// Stash paths for top-most crate locally if necessary.
|
|
|
|
let crate_paths = if root.is_none() {
|
|
|
|
Some(CratePaths {
|
|
|
|
ident: ident.to_string(),
|
2015-01-06 16:46:07 +00:00
|
|
|
dylib: lib.dylib.clone().map(|p| p.0),
|
|
|
|
rlib: lib.rlib.clone().map(|p| p.0),
|
2016-11-10 02:57:30 +00:00
|
|
|
rmeta: lib.rmeta.clone().map(|p| p.0),
|
2014-12-21 06:36:50 +00:00
|
|
|
})
|
|
|
|
} else {
|
|
|
|
None
|
|
|
|
};
|
|
|
|
// Maintain a reference to the top most crate.
|
|
|
|
let root = if root.is_some() { root } else { &crate_paths };
|
2014-04-17 15:52:25 +00:00
|
|
|
|
2016-11-10 02:57:30 +00:00
|
|
|
let Library { dylib, rlib, rmeta, metadata } = lib;
|
2014-04-17 15:52:25 +00:00
|
|
|
|
2016-10-28 05:56:06 +00:00
|
|
|
let cnum_map = self.resolve_crate_deps(root, &crate_root, &metadata, cnum, span, dep_kind);
|
2014-04-17 15:52:25 +00:00
|
|
|
|
2016-06-28 20:41:09 +00:00
|
|
|
let cmeta = Rc::new(cstore::CrateMetadata {
|
2016-11-16 10:52:37 +00:00
|
|
|
name: name,
|
2016-03-16 09:50:38 +00:00
|
|
|
extern_crate: Cell::new(None),
|
2016-09-16 14:25:54 +00:00
|
|
|
key_map: metadata.load_key_map(crate_root.index),
|
2016-11-05 20:30:40 +00:00
|
|
|
proc_macros: crate_root.macro_derive_registrar.map(|_| {
|
|
|
|
self.load_derive_macros(&crate_root, dylib.clone().map(|p| p.0), span)
|
|
|
|
}),
|
2016-09-16 14:25:54 +00:00
|
|
|
root: crate_root,
|
|
|
|
blob: metadata,
|
2015-06-25 17:07:01 +00:00
|
|
|
cnum_map: RefCell::new(cnum_map),
|
2014-12-21 06:36:50 +00:00
|
|
|
cnum: cnum,
|
2015-05-22 13:15:21 +00:00
|
|
|
codemap_import_info: RefCell::new(vec![]),
|
2016-10-27 09:18:45 +00:00
|
|
|
dep_kind: Cell::new(dep_kind),
|
2016-10-27 05:03:11 +00:00
|
|
|
source: cstore::CrateSource {
|
|
|
|
dylib: dylib,
|
|
|
|
rlib: rlib,
|
2016-11-10 02:57:30 +00:00
|
|
|
rmeta: rmeta,
|
2016-10-27 05:03:11 +00:00
|
|
|
},
|
2014-12-21 06:36:50 +00:00
|
|
|
});
|
2014-04-17 15:52:25 +00:00
|
|
|
|
2015-11-21 19:39:05 +00:00
|
|
|
self.cstore.set_crate_data(cnum, cmeta.clone());
|
2016-10-27 05:03:11 +00:00
|
|
|
(cnum, cmeta)
|
2014-12-21 06:36:50 +00:00
|
|
|
}
|
2014-04-17 15:52:25 +00:00
|
|
|
|
2014-12-21 06:36:50 +00:00
|
|
|
fn resolve_crate(&mut self,
|
|
|
|
root: &Option<CratePaths>,
|
2016-11-16 10:52:37 +00:00
|
|
|
ident: Symbol,
|
|
|
|
name: Symbol,
|
2014-12-21 06:36:50 +00:00
|
|
|
hash: Option<&Svh>,
|
|
|
|
span: Span,
|
2016-11-18 00:03:10 +00:00
|
|
|
path_kind: PathKind,
|
2016-11-05 20:30:40 +00:00
|
|
|
mut dep_kind: DepKind)
|
2016-10-27 05:03:11 +00:00
|
|
|
-> (CrateNum, Rc<cstore::CrateMetadata>) {
|
rustc: Implement custom derive (macros 1.1)
This commit is an implementation of [RFC 1681] which adds support to the
compiler for first-class user-define custom `#[derive]` modes with a far more
stable API than plugins have today.
[RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md
The main features added by this commit are:
* A new `rustc-macro` crate-type. This crate type represents one which will
provide custom `derive` implementations and perhaps eventually flower into the
implementation of macros 2.0 as well.
* A new `rustc_macro` crate in the standard distribution. This crate will
provide the runtime interface between macro crates and the compiler. The API
here is particularly conservative right now but has quite a bit of room to
expand into any manner of APIs required by macro authors.
* The ability to load new derive modes through the `#[macro_use]` annotations on
other crates.
All support added here is gated behind the `rustc_macro` feature gate, both for
the library support (the `rustc_macro` crate) as well as the language features.
There are a few minor differences from the implementation outlined in the RFC,
such as the `rustc_macro` crate being available as a dylib and all symbols are
`dlsym`'d directly instead of having a shim compiled. These should only affect
the implementation, however, not the public interface.
This commit also ended up touching a lot of code related to `#[derive]`, making
a few notable changes:
* Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't
sure how to keep this behavior and *not* expose it to custom derive.
* Derive attributes no longer have access to unstable features by default, they
have to opt in on a granular level.
* The `derive(Copy,Clone)` optimization is now done through another "obscure
attribute" which is just intended to ferry along in the compiler that such an
optimization is possible. The `derive(PartialEq,Eq)` optimization was also
updated to do something similar.
---
One part of this PR which needs to be improved before stabilizing are the errors
and exact interfaces here. The error messages are relatively poor quality and
there are surprising spects of this such as `#[derive(PartialEq, Eq, MyTrait)]`
not working by default. The custom attributes added by the compiler end up
becoming unstable again when going through a custom impl.
Hopefully though this is enough to start allowing experimentation on crates.io!
syntax-[breaking-change]
2016-08-23 00:07:11 +00:00
|
|
|
info!("resolving crate `extern crate {} as {}`", name, ident);
|
2016-11-18 00:03:10 +00:00
|
|
|
let result = if let Some(cnum) = self.existing_match(name, hash, path_kind) {
|
2016-11-05 20:30:40 +00:00
|
|
|
LoadResult::Previous(cnum)
|
|
|
|
} else {
|
|
|
|
info!("falling back to a load");
|
|
|
|
let mut locate_ctxt = locator::Context {
|
|
|
|
sess: self.sess,
|
|
|
|
span: span,
|
|
|
|
ident: ident,
|
|
|
|
crate_name: name,
|
|
|
|
hash: hash.map(|a| &*a),
|
2016-11-18 00:03:10 +00:00
|
|
|
filesearch: self.sess.target_filesearch(path_kind),
|
2016-11-05 20:30:40 +00:00
|
|
|
target: &self.sess.target.target,
|
|
|
|
triple: &self.sess.opts.target_triple,
|
|
|
|
root: root,
|
|
|
|
rejected_via_hash: vec![],
|
|
|
|
rejected_via_triple: vec![],
|
|
|
|
rejected_via_kind: vec![],
|
|
|
|
rejected_via_version: vec![],
|
2016-11-24 22:12:36 +00:00
|
|
|
rejected_via_filename: vec![],
|
2016-11-05 20:30:40 +00:00
|
|
|
should_match_name: true,
|
|
|
|
is_proc_macro: Some(false),
|
|
|
|
};
|
|
|
|
|
|
|
|
self.load(&mut locate_ctxt).or_else(|| {
|
2016-11-27 02:57:15 +00:00
|
|
|
dep_kind = DepKind::UnexportedMacrosOnly;
|
2016-11-05 20:30:40 +00:00
|
|
|
|
|
|
|
let mut proc_macro_locator = locator::Context {
|
|
|
|
target: &self.sess.host,
|
|
|
|
triple: config::host_triple(),
|
2016-11-18 00:03:10 +00:00
|
|
|
filesearch: self.sess.host_filesearch(path_kind),
|
2016-10-29 21:54:04 +00:00
|
|
|
rejected_via_hash: vec![],
|
|
|
|
rejected_via_triple: vec![],
|
|
|
|
rejected_via_kind: vec![],
|
|
|
|
rejected_via_version: vec![],
|
2016-11-24 22:12:36 +00:00
|
|
|
rejected_via_filename: vec![],
|
2016-11-05 20:30:40 +00:00
|
|
|
is_proc_macro: Some(true),
|
|
|
|
..locate_ctxt
|
2014-12-21 06:36:50 +00:00
|
|
|
};
|
2016-11-05 20:30:40 +00:00
|
|
|
|
|
|
|
self.load(&mut proc_macro_locator)
|
|
|
|
}).unwrap_or_else(|| locate_ctxt.report_errs())
|
2015-10-21 04:05:39 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
match result {
|
2016-05-20 21:03:47 +00:00
|
|
|
LoadResult::Previous(cnum) => {
|
2015-11-21 19:39:05 +00:00
|
|
|
let data = self.cstore.get_crate_data(cnum);
|
2016-11-20 13:28:31 +00:00
|
|
|
if data.root.macro_derive_registrar.is_some() {
|
2016-11-27 02:57:15 +00:00
|
|
|
dep_kind = DepKind::UnexportedMacrosOnly;
|
2016-11-20 13:28:31 +00:00
|
|
|
}
|
2016-10-27 09:18:45 +00:00
|
|
|
data.dep_kind.set(cmp::max(data.dep_kind.get(), dep_kind));
|
2016-10-27 05:03:11 +00:00
|
|
|
(cnum, data)
|
2014-12-21 06:36:50 +00:00
|
|
|
}
|
2016-05-20 21:03:47 +00:00
|
|
|
LoadResult::Loaded(library) => {
|
2016-10-27 09:18:45 +00:00
|
|
|
self.register_crate(root, ident, name, span, library, dep_kind)
|
2015-10-21 04:05:39 +00:00
|
|
|
}
|
2014-02-25 02:13:51 +00:00
|
|
|
}
|
2012-04-06 01:31:03 +00:00
|
|
|
}
|
2011-05-27 00:16:54 +00:00
|
|
|
|
2016-10-20 04:31:14 +00:00
|
|
|
fn load(&mut self, locate_ctxt: &mut locator::Context) -> Option<LoadResult> {
|
|
|
|
let library = match locate_ctxt.maybe_load_library_crate() {
|
2016-05-20 21:03:47 +00:00
|
|
|
Some(lib) => lib,
|
|
|
|
None => return None,
|
|
|
|
};
|
|
|
|
|
|
|
|
// In the case that we're loading a crate, but not matching
|
|
|
|
// against a hash, we could load a crate which has the same hash
|
|
|
|
// as an already loaded crate. If this is the case prevent
|
|
|
|
// duplicates by just using the first crate.
|
|
|
|
//
|
|
|
|
// Note that we only do this for target triple crates, though, as we
|
|
|
|
// don't want to match a host crate against an equivalent target one
|
|
|
|
// already loaded.
|
2016-09-16 14:25:54 +00:00
|
|
|
let root = library.metadata.get_root();
|
2016-10-20 04:31:14 +00:00
|
|
|
if locate_ctxt.triple == self.sess.opts.target_triple {
|
2016-05-20 21:03:47 +00:00
|
|
|
let mut result = LoadResult::Loaded(library);
|
|
|
|
self.cstore.iter_crate_data(|cnum, data| {
|
2016-09-16 14:25:54 +00:00
|
|
|
if data.name() == root.name && root.hash == data.hash() {
|
2016-10-20 04:31:14 +00:00
|
|
|
assert!(locate_ctxt.hash.is_none());
|
rustc: Implement custom derive (macros 1.1)
This commit is an implementation of [RFC 1681] which adds support to the
compiler for first-class user-define custom `#[derive]` modes with a far more
stable API than plugins have today.
[RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md
The main features added by this commit are:
* A new `rustc-macro` crate-type. This crate type represents one which will
provide custom `derive` implementations and perhaps eventually flower into the
implementation of macros 2.0 as well.
* A new `rustc_macro` crate in the standard distribution. This crate will
provide the runtime interface between macro crates and the compiler. The API
here is particularly conservative right now but has quite a bit of room to
expand into any manner of APIs required by macro authors.
* The ability to load new derive modes through the `#[macro_use]` annotations on
other crates.
All support added here is gated behind the `rustc_macro` feature gate, both for
the library support (the `rustc_macro` crate) as well as the language features.
There are a few minor differences from the implementation outlined in the RFC,
such as the `rustc_macro` crate being available as a dylib and all symbols are
`dlsym`'d directly instead of having a shim compiled. These should only affect
the implementation, however, not the public interface.
This commit also ended up touching a lot of code related to `#[derive]`, making
a few notable changes:
* Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't
sure how to keep this behavior and *not* expose it to custom derive.
* Derive attributes no longer have access to unstable features by default, they
have to opt in on a granular level.
* The `derive(Copy,Clone)` optimization is now done through another "obscure
attribute" which is just intended to ferry along in the compiler that such an
optimization is possible. The `derive(PartialEq,Eq)` optimization was also
updated to do something similar.
---
One part of this PR which needs to be improved before stabilizing are the errors
and exact interfaces here. The error messages are relatively poor quality and
there are surprising spects of this such as `#[derive(PartialEq, Eq, MyTrait)]`
not working by default. The custom attributes added by the compiler end up
becoming unstable again when going through a custom impl.
Hopefully though this is enough to start allowing experimentation on crates.io!
syntax-[breaking-change]
2016-08-23 00:07:11 +00:00
|
|
|
info!("load success, going to previous cnum: {}", cnum);
|
2016-05-20 21:03:47 +00:00
|
|
|
result = LoadResult::Previous(cnum);
|
|
|
|
}
|
|
|
|
});
|
|
|
|
Some(result)
|
|
|
|
} else {
|
|
|
|
Some(LoadResult::Loaded(library))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-03-16 09:50:38 +00:00
|
|
|
fn update_extern_crate(&mut self,
|
2016-08-31 11:00:29 +00:00
|
|
|
cnum: CrateNum,
|
2016-06-28 20:41:09 +00:00
|
|
|
mut extern_crate: ExternCrate,
|
2016-11-08 03:02:55 +00:00
|
|
|
visited: &mut FxHashSet<(CrateNum, bool)>)
|
2016-03-16 09:50:38 +00:00
|
|
|
{
|
2016-06-28 20:41:09 +00:00
|
|
|
if !visited.insert((cnum, extern_crate.direct)) { return }
|
|
|
|
|
2016-03-16 09:50:38 +00:00
|
|
|
let cmeta = self.cstore.get_crate_data(cnum);
|
|
|
|
let old_extern_crate = cmeta.extern_crate.get();
|
|
|
|
|
|
|
|
// Prefer:
|
|
|
|
// - something over nothing (tuple.0);
|
|
|
|
// - direct extern crate to indirect (tuple.1);
|
|
|
|
// - shorter paths to longer (tuple.2).
|
|
|
|
let new_rank = (true, extern_crate.direct, !extern_crate.path_len);
|
|
|
|
let old_rank = match old_extern_crate {
|
|
|
|
None => (false, false, !0),
|
|
|
|
Some(ref c) => (true, c.direct, !c.path_len),
|
|
|
|
};
|
|
|
|
|
|
|
|
if old_rank >= new_rank {
|
|
|
|
return; // no change needed
|
|
|
|
}
|
|
|
|
|
|
|
|
cmeta.extern_crate.set(Some(extern_crate));
|
|
|
|
// Propagate the extern crate info to dependencies.
|
|
|
|
extern_crate.direct = false;
|
2016-06-28 20:41:09 +00:00
|
|
|
for &dep_cnum in cmeta.cnum_map.borrow().iter() {
|
|
|
|
self.update_extern_crate(dep_cnum, extern_crate, visited);
|
2016-03-16 09:50:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-12-21 06:36:50 +00:00
|
|
|
// Go through the crate metadata and load any crates that it references
|
|
|
|
fn resolve_crate_deps(&mut self,
|
|
|
|
root: &Option<CratePaths>,
|
2016-09-16 14:25:54 +00:00
|
|
|
crate_root: &CrateRoot,
|
2016-09-15 08:04:00 +00:00
|
|
|
metadata: &MetadataBlob,
|
2016-08-31 11:00:29 +00:00
|
|
|
krate: CrateNum,
|
2016-10-28 05:56:06 +00:00
|
|
|
span: Span,
|
|
|
|
dep_kind: DepKind)
|
2016-06-28 20:41:09 +00:00
|
|
|
-> cstore::CrateNumMap {
|
2014-12-21 06:36:50 +00:00
|
|
|
debug!("resolving deps of external crate");
|
2016-11-05 20:30:40 +00:00
|
|
|
if crate_root.macro_derive_registrar.is_some() {
|
|
|
|
return cstore::CrateNumMap::new();
|
|
|
|
}
|
|
|
|
|
2016-11-27 02:57:15 +00:00
|
|
|
// The map from crate numbers in the crate we're resolving to local crate numbers.
|
|
|
|
// We map 0 and all other holes in the map to our parent crate. The "additional"
|
|
|
|
// self-dependencies should be harmless.
|
|
|
|
::std::iter::once(krate).chain(crate_root.crate_deps.decode(metadata).map(|dep| {
|
2014-12-21 06:36:50 +00:00
|
|
|
debug!("resolving dep crate {} hash: `{}`", dep.name, dep.hash);
|
2016-11-27 02:57:15 +00:00
|
|
|
if dep.kind == DepKind::UnexportedMacrosOnly {
|
|
|
|
return krate;
|
|
|
|
}
|
2016-10-28 05:56:06 +00:00
|
|
|
let dep_kind = match dep_kind {
|
|
|
|
DepKind::MacrosOnly => DepKind::MacrosOnly,
|
|
|
|
_ => dep.kind,
|
|
|
|
};
|
|
|
|
let (local_cnum, ..) = self.resolve_crate(
|
2016-11-16 10:52:37 +00:00
|
|
|
root, dep.name, dep.name, Some(&dep.hash), span, PathKind::Dependency, dep_kind,
|
2016-10-28 05:56:06 +00:00
|
|
|
);
|
2016-11-27 02:57:15 +00:00
|
|
|
local_cnum
|
|
|
|
})).collect()
|
2014-12-21 06:36:50 +00:00
|
|
|
}
|
2013-12-25 18:10:33 +00:00
|
|
|
|
2016-09-08 16:05:50 +00:00
|
|
|
fn read_extension_crate(&mut self, span: Span, info: &ExternCrateInfo) -> ExtensionCrate {
|
2016-10-28 05:56:06 +00:00
|
|
|
info!("read extension crate {} `extern crate {} as {}` dep_kind={:?}",
|
|
|
|
info.id, info.name, info.ident, info.dep_kind);
|
2015-02-20 19:08:14 +00:00
|
|
|
let target_triple = &self.sess.opts.target_triple[..];
|
2014-11-16 01:30:33 +00:00
|
|
|
let is_cross = target_triple != config::host_triple();
|
2015-01-01 03:48:39 +00:00
|
|
|
let mut target_only = false;
|
2016-10-20 04:31:14 +00:00
|
|
|
let mut locate_ctxt = locator::Context {
|
2014-12-21 07:02:38 +00:00
|
|
|
sess: self.sess,
|
2014-12-09 16:03:05 +00:00
|
|
|
span: span,
|
2016-11-16 10:52:37 +00:00
|
|
|
ident: info.ident,
|
|
|
|
crate_name: info.name,
|
2014-04-17 15:52:25 +00:00
|
|
|
hash: None,
|
2014-12-21 07:02:38 +00:00
|
|
|
filesearch: self.sess.host_filesearch(PathKind::Crate),
|
2015-01-09 01:14:10 +00:00
|
|
|
target: &self.sess.host,
|
2014-11-16 01:30:33 +00:00
|
|
|
triple: config::host_triple(),
|
2014-04-17 15:52:25 +00:00
|
|
|
root: &None,
|
2016-10-29 21:54:04 +00:00
|
|
|
rejected_via_hash: vec![],
|
|
|
|
rejected_via_triple: vec![],
|
|
|
|
rejected_via_kind: vec![],
|
|
|
|
rejected_via_version: vec![],
|
2016-11-24 22:12:36 +00:00
|
|
|
rejected_via_filename: vec![],
|
2014-07-01 15:37:54 +00:00
|
|
|
should_match_name: true,
|
2016-11-05 20:30:40 +00:00
|
|
|
is_proc_macro: None,
|
2014-04-17 15:52:25 +00:00
|
|
|
};
|
2016-10-20 04:31:14 +00:00
|
|
|
let library = self.load(&mut locate_ctxt).or_else(|| {
|
2016-05-20 21:03:47 +00:00
|
|
|
if !is_cross {
|
|
|
|
return None
|
2014-04-17 15:52:25 +00:00
|
|
|
}
|
2016-05-20 21:03:47 +00:00
|
|
|
// Try loading from target crates. This will abort later if we
|
|
|
|
// try to load a plugin registrar function,
|
|
|
|
target_only = true;
|
|
|
|
|
2016-10-20 04:31:14 +00:00
|
|
|
locate_ctxt.target = &self.sess.target.target;
|
|
|
|
locate_ctxt.triple = target_triple;
|
|
|
|
locate_ctxt.filesearch = self.sess.target_filesearch(PathKind::Crate);
|
2016-05-20 21:03:47 +00:00
|
|
|
|
2016-10-20 04:31:14 +00:00
|
|
|
self.load(&mut locate_ctxt)
|
2016-05-20 21:03:47 +00:00
|
|
|
});
|
|
|
|
let library = match library {
|
|
|
|
Some(l) => l,
|
2016-10-20 04:31:14 +00:00
|
|
|
None => locate_ctxt.report_errs(),
|
2014-04-17 15:52:25 +00:00
|
|
|
};
|
2014-12-31 03:10:46 +00:00
|
|
|
|
2016-05-20 21:03:47 +00:00
|
|
|
let (dylib, metadata) = match library {
|
|
|
|
LoadResult::Previous(cnum) => {
|
|
|
|
let data = self.cstore.get_crate_data(cnum);
|
2016-10-27 05:03:11 +00:00
|
|
|
(data.source.dylib.clone(), PMDSource::Registered(data))
|
2016-05-20 21:03:47 +00:00
|
|
|
}
|
|
|
|
LoadResult::Loaded(library) => {
|
|
|
|
let dylib = library.dylib.clone();
|
rustc: Implement custom derive (macros 1.1)
This commit is an implementation of [RFC 1681] which adds support to the
compiler for first-class user-define custom `#[derive]` modes with a far more
stable API than plugins have today.
[RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md
The main features added by this commit are:
* A new `rustc-macro` crate-type. This crate type represents one which will
provide custom `derive` implementations and perhaps eventually flower into the
implementation of macros 2.0 as well.
* A new `rustc_macro` crate in the standard distribution. This crate will
provide the runtime interface between macro crates and the compiler. The API
here is particularly conservative right now but has quite a bit of room to
expand into any manner of APIs required by macro authors.
* The ability to load new derive modes through the `#[macro_use]` annotations on
other crates.
All support added here is gated behind the `rustc_macro` feature gate, both for
the library support (the `rustc_macro` crate) as well as the language features.
There are a few minor differences from the implementation outlined in the RFC,
such as the `rustc_macro` crate being available as a dylib and all symbols are
`dlsym`'d directly instead of having a shim compiled. These should only affect
the implementation, however, not the public interface.
This commit also ended up touching a lot of code related to `#[derive]`, making
a few notable changes:
* Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't
sure how to keep this behavior and *not* expose it to custom derive.
* Derive attributes no longer have access to unstable features by default, they
have to opt in on a granular level.
* The `derive(Copy,Clone)` optimization is now done through another "obscure
attribute" which is just intended to ferry along in the compiler that such an
optimization is possible. The `derive(PartialEq,Eq)` optimization was also
updated to do something similar.
---
One part of this PR which needs to be improved before stabilizing are the errors
and exact interfaces here. The error messages are relatively poor quality and
there are surprising spects of this such as `#[derive(PartialEq, Eq, MyTrait)]`
not working by default. The custom attributes added by the compiler end up
becoming unstable again when going through a custom impl.
Hopefully though this is enough to start allowing experimentation on crates.io!
syntax-[breaking-change]
2016-08-23 00:07:11 +00:00
|
|
|
let metadata = PMDSource::Owned(library);
|
2016-05-20 21:03:47 +00:00
|
|
|
(dylib, metadata)
|
|
|
|
}
|
2015-01-01 03:48:39 +00:00
|
|
|
};
|
|
|
|
|
2015-02-12 02:43:16 +00:00
|
|
|
ExtensionCrate {
|
2015-01-01 03:48:39 +00:00
|
|
|
metadata: metadata,
|
2015-01-06 16:46:07 +00:00
|
|
|
dylib: dylib.map(|p| p.0),
|
2015-01-01 03:48:39 +00:00
|
|
|
target_only: target_only,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-10-17 07:46:25 +00:00
|
|
|
/// Load custom derive macros.
|
|
|
|
///
|
|
|
|
/// Note that this is intentionally similar to how we load plugins today,
|
|
|
|
/// but also intentionally separate. Plugins are likely always going to be
|
|
|
|
/// implemented as dynamic libraries, but we have a possible future where
|
|
|
|
/// custom derive (and other macro-1.1 style features) are implemented via
|
|
|
|
/// executables and custom IPC.
|
2016-11-05 20:30:40 +00:00
|
|
|
fn load_derive_macros(&mut self, root: &CrateRoot, dylib: Option<PathBuf>, span: Span)
|
|
|
|
-> Vec<(ast::Name, Rc<SyntaxExtension>)> {
|
2016-10-17 07:46:25 +00:00
|
|
|
use std::{env, mem};
|
|
|
|
use proc_macro::TokenStream;
|
|
|
|
use proc_macro::__internal::Registry;
|
|
|
|
use rustc_back::dynamic_lib::DynamicLibrary;
|
|
|
|
use syntax_ext::deriving::custom::CustomDerive;
|
|
|
|
|
2016-11-05 20:30:40 +00:00
|
|
|
let path = match dylib {
|
2016-10-28 06:52:45 +00:00
|
|
|
Some(dylib) => dylib,
|
2016-11-05 20:30:40 +00:00
|
|
|
None => span_bug!(span, "proc-macro crate not dylib"),
|
2016-10-28 06:52:45 +00:00
|
|
|
};
|
2016-10-17 07:46:25 +00:00
|
|
|
// Make sure the path contains a / or the linker will search for it.
|
|
|
|
let path = env::current_dir().unwrap().join(path);
|
|
|
|
let lib = match DynamicLibrary::open(Some(&path)) {
|
|
|
|
Ok(lib) => lib,
|
2016-11-05 20:30:40 +00:00
|
|
|
Err(err) => self.sess.span_fatal(span, &err),
|
2016-10-17 07:46:25 +00:00
|
|
|
};
|
|
|
|
|
2016-11-05 20:30:40 +00:00
|
|
|
let sym = self.sess.generate_derive_registrar_symbol(&root.hash,
|
|
|
|
root.macro_derive_registrar.unwrap());
|
2016-10-17 07:46:25 +00:00
|
|
|
let registrar = unsafe {
|
|
|
|
let sym = match lib.symbol(&sym) {
|
|
|
|
Ok(f) => f,
|
2016-11-05 20:30:40 +00:00
|
|
|
Err(err) => self.sess.span_fatal(span, &err),
|
2016-10-17 07:46:25 +00:00
|
|
|
};
|
|
|
|
mem::transmute::<*mut u8, fn(&mut Registry)>(sym)
|
|
|
|
};
|
|
|
|
|
2016-11-05 20:30:40 +00:00
|
|
|
struct MyRegistrar(Vec<(ast::Name, Rc<SyntaxExtension>)>);
|
2016-10-17 07:46:25 +00:00
|
|
|
|
|
|
|
impl Registry for MyRegistrar {
|
|
|
|
fn register_custom_derive(&mut self,
|
|
|
|
trait_name: &str,
|
2016-11-08 11:15:02 +00:00
|
|
|
expand: fn(TokenStream) -> TokenStream,
|
|
|
|
attributes: &[&'static str]) {
|
2016-11-16 08:21:52 +00:00
|
|
|
let attrs = attributes.iter().cloned().map(Symbol::intern).collect();
|
2016-11-08 11:15:02 +00:00
|
|
|
let derive = SyntaxExtension::CustomDerive(
|
|
|
|
Box::new(CustomDerive::new(expand, attrs))
|
|
|
|
);
|
2016-11-16 08:21:52 +00:00
|
|
|
self.0.push((Symbol::intern(trait_name), Rc::new(derive)));
|
2016-10-17 07:46:25 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
let mut my_registrar = MyRegistrar(Vec::new());
|
|
|
|
registrar(&mut my_registrar);
|
|
|
|
|
|
|
|
// Intentionally leak the dynamic library. We can't ever unload it
|
|
|
|
// since the library can make things that will live arbitrarily long.
|
|
|
|
mem::forget(lib);
|
2016-11-05 20:30:40 +00:00
|
|
|
my_registrar.0
|
2016-10-17 07:46:25 +00:00
|
|
|
}
|
|
|
|
|
2016-05-10 20:21:18 +00:00
|
|
|
/// Look for a plugin registrar. Returns library path, crate
|
|
|
|
/// SVH and DefIndex of the registrar function.
|
2015-02-27 05:00:43 +00:00
|
|
|
pub fn find_plugin_registrar(&mut self, span: Span, name: &str)
|
2016-05-10 20:21:18 +00:00
|
|
|
-> Option<(PathBuf, Svh, DefIndex)> {
|
2016-09-08 16:05:50 +00:00
|
|
|
let ekrate = self.read_extension_crate(span, &ExternCrateInfo {
|
2016-11-16 10:52:37 +00:00
|
|
|
name: Symbol::intern(name),
|
|
|
|
ident: Symbol::intern(name),
|
2015-02-12 02:43:16 +00:00
|
|
|
id: ast::DUMMY_NODE_ID,
|
2016-11-27 02:57:15 +00:00
|
|
|
dep_kind: DepKind::UnexportedMacrosOnly,
|
2015-02-12 02:43:16 +00:00
|
|
|
});
|
|
|
|
|
|
|
|
if ekrate.target_only {
|
2015-01-01 03:48:39 +00:00
|
|
|
// Need to abort before syntax expansion.
|
2015-02-12 02:43:16 +00:00
|
|
|
let message = format!("plugin `{}` is not available for triple `{}` \
|
2015-01-01 03:48:39 +00:00
|
|
|
(only found {})",
|
2015-02-12 02:43:16 +00:00
|
|
|
name,
|
2015-01-01 03:48:39 +00:00
|
|
|
config::host_triple(),
|
|
|
|
self.sess.opts.target_triple);
|
2016-01-20 09:07:33 +00:00
|
|
|
span_fatal!(self.sess, span, E0456, "{}", &message[..]);
|
2014-07-10 02:13:28 +00:00
|
|
|
}
|
2015-01-01 03:48:39 +00:00
|
|
|
|
2016-09-16 14:25:54 +00:00
|
|
|
let root = ekrate.metadata.get_root();
|
|
|
|
match (ekrate.dylib.as_ref(), root.plugin_registrar_fn) {
|
2016-05-10 20:21:18 +00:00
|
|
|
(Some(dylib), Some(reg)) => {
|
2016-09-16 14:25:54 +00:00
|
|
|
Some((dylib.to_path_buf(), root.hash, reg))
|
2016-05-10 20:21:18 +00:00
|
|
|
}
|
2015-01-01 03:48:39 +00:00
|
|
|
(None, Some(_)) => {
|
2015-09-11 14:17:15 +00:00
|
|
|
span_err!(self.sess, span, E0457,
|
|
|
|
"plugin `{}` only found in rlib format, but must be available \
|
|
|
|
in dylib format",
|
|
|
|
name);
|
2015-01-01 03:48:39 +00:00
|
|
|
// No need to abort because the loading code will just ignore this
|
|
|
|
// empty dylib.
|
|
|
|
None
|
|
|
|
}
|
|
|
|
_ => None,
|
2013-12-25 18:10:33 +00:00
|
|
|
}
|
|
|
|
}
|
2015-07-30 21:20:36 +00:00
|
|
|
|
|
|
|
fn register_statically_included_foreign_items(&mut self) {
|
2015-11-21 19:39:05 +00:00
|
|
|
let libs = self.cstore.get_used_libraries();
|
rustc: Implement #[link(cfg(..))] and crt-static
This commit is an implementation of [RFC 1721] which adds a new target feature
to the compiler, `crt-static`, which can be used to select how the C runtime for
a target is linked. Most targets dynamically linke the C runtime by default with
the notable exception of some of the musl targets.
[RFC 1721]: https://github.com/rust-lang/rfcs/blob/master/text/1721-crt-static.md
This commit first adds the new target-feature, `crt-static`. If enabled, then
the `cfg(target_feature = "crt-static")` will be available. Targets like musl
will have this enabled by default. This feature can be controlled through the
standard target-feature interface, `-C target-feature=+crt-static` or
`-C target-feature=-crt-static`.
Next this adds an gated and unstable `#[link(cfg(..))]` feature to enable the
`crt-static` semantics we want with libc. The exact behavior of this attribute
is a little squishy, but it's intended to be a forever-unstable
implementation detail of the liblibc crate.
Specifically the `#[link(cfg(..))]` annotation means that the `#[link]`
directive is only active in a compilation unit if that `cfg` value is satisfied.
For example when compiling an rlib, these directives are just encoded and
ignored for dylibs, and all staticlibs are continued to be put into the rlib as
usual. When placing that rlib into a staticlib, executable, or dylib, however,
the `cfg` is evaluated *as if it were defined in the final artifact* and the
library is decided to be linked or not.
Essentially, what'll happen is:
* On MSVC with `-C target-feature=-crt-static`, the `msvcrt.lib` library will be
linked to.
* On MSVC with `-C target-feature=+crt-static`, the `libcmt.lib` library will be
linked to.
* On musl with `-C target-feature=-crt-static`, the object files in liblibc.rlib
are removed and `-lc` is passed instead.
* On musl with `-C target-feature=+crt-static`, the object files in liblibc.rlib
are used and `-lc` is not passed.
This commit does **not** include an update to the liblibc module to implement
these changes. I plan to do that just after the 1.14.0 beta release is cut to
ensure we get ample time to test this feature.
cc #37406
2016-10-31 23:40:13 +00:00
|
|
|
for (foreign_lib, list) in self.foreign_item_map.iter() {
|
|
|
|
let is_static = libs.borrow().iter().any(|lib| {
|
2016-11-16 10:52:37 +00:00
|
|
|
lib.name == &**foreign_lib && lib.kind == cstore::NativeStatic
|
2015-07-30 21:20:36 +00:00
|
|
|
});
|
|
|
|
if is_static {
|
|
|
|
for id in list {
|
2015-11-21 19:39:05 +00:00
|
|
|
self.cstore.add_statically_included_foreign_item(*id);
|
2015-07-30 21:20:36 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2015-06-25 17:07:01 +00:00
|
|
|
|
rustc: Implement custom panic runtimes
This commit is an implementation of [RFC 1513] which allows applications to
alter the behavior of panics at compile time. A new compiler flag, `-C panic`,
is added and accepts the values `unwind` or `panic`, with the default being
`unwind`. This model affects how code is generated for the local crate, skipping
generation of landing pads with `-C panic=abort`.
[RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md
Panic implementations are then provided by crates tagged with
`#![panic_runtime]` and lazily required by crates with
`#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic
runtime must match the final product, and if the panic strategy is not `abort`
then the entire DAG must have the same panic strategy.
With the `-C panic=abort` strategy, users can expect a stable method to disable
generation of landing pads, improving optimization in niche scenarios,
decreasing compile time, and decreasing output binary size. With the `-C
panic=unwind` strategy users can expect the existing ability to isolate failure
in Rust code from the outside world.
Organizationally, this commit dismantles the `sys_common::unwind` module in
favor of some bits moving part of it to `libpanic_unwind` and the rest into the
`panicking` module in libstd. The custom panic runtime support is pretty similar
to the custom allocator support with the only major difference being how the
panic runtime is injected (takes the `-C panic` flag into account).
2016-04-08 23:18:40 +00:00
|
|
|
fn inject_panic_runtime(&mut self, krate: &ast::Crate) {
|
|
|
|
// If we're only compiling an rlib, then there's no need to select a
|
|
|
|
// panic runtime, so we just skip this section entirely.
|
|
|
|
let any_non_rlib = self.sess.crate_types.borrow().iter().any(|ct| {
|
|
|
|
*ct != config::CrateTypeRlib
|
|
|
|
});
|
|
|
|
if !any_non_rlib {
|
|
|
|
info!("panic runtime injection skipped, only generating rlib");
|
|
|
|
return
|
|
|
|
}
|
|
|
|
|
|
|
|
// If we need a panic runtime, we try to find an existing one here. At
|
|
|
|
// the same time we perform some general validation of the DAG we've got
|
|
|
|
// going such as ensuring everything has a compatible panic strategy.
|
|
|
|
//
|
|
|
|
// The logic for finding the panic runtime here is pretty much the same
|
|
|
|
// as the allocator case with the only addition that the panic strategy
|
|
|
|
// compilation mode also comes into play.
|
2016-09-28 02:26:08 +00:00
|
|
|
let desired_strategy = self.sess.panic_strategy();
|
rustc: Implement custom panic runtimes
This commit is an implementation of [RFC 1513] which allows applications to
alter the behavior of panics at compile time. A new compiler flag, `-C panic`,
is added and accepts the values `unwind` or `panic`, with the default being
`unwind`. This model affects how code is generated for the local crate, skipping
generation of landing pads with `-C panic=abort`.
[RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md
Panic implementations are then provided by crates tagged with
`#![panic_runtime]` and lazily required by crates with
`#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic
runtime must match the final product, and if the panic strategy is not `abort`
then the entire DAG must have the same panic strategy.
With the `-C panic=abort` strategy, users can expect a stable method to disable
generation of landing pads, improving optimization in niche scenarios,
decreasing compile time, and decreasing output binary size. With the `-C
panic=unwind` strategy users can expect the existing ability to isolate failure
in Rust code from the outside world.
Organizationally, this commit dismantles the `sys_common::unwind` module in
favor of some bits moving part of it to `libpanic_unwind` and the rest into the
`panicking` module in libstd. The custom panic runtime support is pretty similar
to the custom allocator support with the only major difference being how the
panic runtime is injected (takes the `-C panic` flag into account).
2016-04-08 23:18:40 +00:00
|
|
|
let mut runtime_found = false;
|
|
|
|
let mut needs_panic_runtime = attr::contains_name(&krate.attrs,
|
|
|
|
"needs_panic_runtime");
|
|
|
|
self.cstore.iter_crate_data(|cnum, data| {
|
|
|
|
needs_panic_runtime = needs_panic_runtime || data.needs_panic_runtime();
|
|
|
|
if data.is_panic_runtime() {
|
|
|
|
// Inject a dependency from all #![needs_panic_runtime] to this
|
|
|
|
// #![panic_runtime] crate.
|
|
|
|
self.inject_dependency_if(cnum, "a panic runtime",
|
|
|
|
&|data| data.needs_panic_runtime());
|
2016-10-27 09:18:45 +00:00
|
|
|
runtime_found = runtime_found || data.dep_kind.get() == DepKind::Explicit;
|
rustc: Implement custom panic runtimes
This commit is an implementation of [RFC 1513] which allows applications to
alter the behavior of panics at compile time. A new compiler flag, `-C panic`,
is added and accepts the values `unwind` or `panic`, with the default being
`unwind`. This model affects how code is generated for the local crate, skipping
generation of landing pads with `-C panic=abort`.
[RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md
Panic implementations are then provided by crates tagged with
`#![panic_runtime]` and lazily required by crates with
`#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic
runtime must match the final product, and if the panic strategy is not `abort`
then the entire DAG must have the same panic strategy.
With the `-C panic=abort` strategy, users can expect a stable method to disable
generation of landing pads, improving optimization in niche scenarios,
decreasing compile time, and decreasing output binary size. With the `-C
panic=unwind` strategy users can expect the existing ability to isolate failure
in Rust code from the outside world.
Organizationally, this commit dismantles the `sys_common::unwind` module in
favor of some bits moving part of it to `libpanic_unwind` and the rest into the
`panicking` module in libstd. The custom panic runtime support is pretty similar
to the custom allocator support with the only major difference being how the
panic runtime is injected (takes the `-C panic` flag into account).
2016-04-08 23:18:40 +00:00
|
|
|
}
|
|
|
|
});
|
|
|
|
|
|
|
|
// If an explicitly linked and matching panic runtime was found, or if
|
|
|
|
// we just don't need one at all, then we're done here and there's
|
|
|
|
// nothing else to do.
|
|
|
|
if !needs_panic_runtime || runtime_found {
|
|
|
|
return
|
|
|
|
}
|
|
|
|
|
|
|
|
// By this point we know that we (a) need a panic runtime and (b) no
|
|
|
|
// panic runtime was explicitly linked. Here we just load an appropriate
|
|
|
|
// default runtime for our panic strategy and then inject the
|
|
|
|
// dependencies.
|
|
|
|
//
|
|
|
|
// We may resolve to an already loaded crate (as the crate may not have
|
|
|
|
// been explicitly linked prior to this) and we may re-inject
|
|
|
|
// dependencies again, but both of those situations are fine.
|
|
|
|
//
|
|
|
|
// Also note that we have yet to perform validation of the crate graph
|
|
|
|
// in terms of everyone has a compatible panic runtime format, that's
|
|
|
|
// performed later as part of the `dependency_format` module.
|
|
|
|
let name = match desired_strategy {
|
2016-11-16 10:52:37 +00:00
|
|
|
PanicStrategy::Unwind => Symbol::intern("panic_unwind"),
|
|
|
|
PanicStrategy::Abort => Symbol::intern("panic_abort"),
|
rustc: Implement custom panic runtimes
This commit is an implementation of [RFC 1513] which allows applications to
alter the behavior of panics at compile time. A new compiler flag, `-C panic`,
is added and accepts the values `unwind` or `panic`, with the default being
`unwind`. This model affects how code is generated for the local crate, skipping
generation of landing pads with `-C panic=abort`.
[RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md
Panic implementations are then provided by crates tagged with
`#![panic_runtime]` and lazily required by crates with
`#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic
runtime must match the final product, and if the panic strategy is not `abort`
then the entire DAG must have the same panic strategy.
With the `-C panic=abort` strategy, users can expect a stable method to disable
generation of landing pads, improving optimization in niche scenarios,
decreasing compile time, and decreasing output binary size. With the `-C
panic=unwind` strategy users can expect the existing ability to isolate failure
in Rust code from the outside world.
Organizationally, this commit dismantles the `sys_common::unwind` module in
favor of some bits moving part of it to `libpanic_unwind` and the rest into the
`panicking` module in libstd. The custom panic runtime support is pretty similar
to the custom allocator support with the only major difference being how the
panic runtime is injected (takes the `-C panic` flag into account).
2016-04-08 23:18:40 +00:00
|
|
|
};
|
|
|
|
info!("panic runtime not found -- loading {}", name);
|
|
|
|
|
2016-10-27 09:18:45 +00:00
|
|
|
let dep_kind = DepKind::Implicit;
|
2016-10-27 05:03:11 +00:00
|
|
|
let (cnum, data) =
|
2016-10-27 09:18:45 +00:00
|
|
|
self.resolve_crate(&None, name, name, None, DUMMY_SP, PathKind::Crate, dep_kind);
|
rustc: Implement custom panic runtimes
This commit is an implementation of [RFC 1513] which allows applications to
alter the behavior of panics at compile time. A new compiler flag, `-C panic`,
is added and accepts the values `unwind` or `panic`, with the default being
`unwind`. This model affects how code is generated for the local crate, skipping
generation of landing pads with `-C panic=abort`.
[RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md
Panic implementations are then provided by crates tagged with
`#![panic_runtime]` and lazily required by crates with
`#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic
runtime must match the final product, and if the panic strategy is not `abort`
then the entire DAG must have the same panic strategy.
With the `-C panic=abort` strategy, users can expect a stable method to disable
generation of landing pads, improving optimization in niche scenarios,
decreasing compile time, and decreasing output binary size. With the `-C
panic=unwind` strategy users can expect the existing ability to isolate failure
in Rust code from the outside world.
Organizationally, this commit dismantles the `sys_common::unwind` module in
favor of some bits moving part of it to `libpanic_unwind` and the rest into the
`panicking` module in libstd. The custom panic runtime support is pretty similar
to the custom allocator support with the only major difference being how the
panic runtime is injected (takes the `-C panic` flag into account).
2016-04-08 23:18:40 +00:00
|
|
|
|
|
|
|
// Sanity check the loaded crate to ensure it is indeed a panic runtime
|
|
|
|
// and the panic strategy is indeed what we thought it was.
|
|
|
|
if !data.is_panic_runtime() {
|
|
|
|
self.sess.err(&format!("the crate `{}` is not a panic runtime",
|
|
|
|
name));
|
|
|
|
}
|
|
|
|
if data.panic_strategy() != desired_strategy {
|
|
|
|
self.sess.err(&format!("the crate `{}` does not have the panic \
|
|
|
|
strategy `{}`",
|
|
|
|
name, desired_strategy.desc()));
|
|
|
|
}
|
|
|
|
|
|
|
|
self.sess.injected_panic_runtime.set(Some(cnum));
|
|
|
|
self.inject_dependency_if(cnum, "a panic runtime",
|
|
|
|
&|data| data.needs_panic_runtime());
|
|
|
|
}
|
|
|
|
|
2015-06-25 17:07:01 +00:00
|
|
|
fn inject_allocator_crate(&mut self) {
|
|
|
|
// Make sure that we actually need an allocator, if none of our
|
|
|
|
// dependencies need one then we definitely don't!
|
|
|
|
//
|
|
|
|
// Also, if one of our dependencies has an explicit allocator, then we
|
|
|
|
// also bail out as we don't need to implicitly inject one.
|
|
|
|
let mut needs_allocator = false;
|
|
|
|
let mut found_required_allocator = false;
|
2015-11-21 19:39:05 +00:00
|
|
|
self.cstore.iter_crate_data(|cnum, data| {
|
2015-06-25 17:07:01 +00:00
|
|
|
needs_allocator = needs_allocator || data.needs_allocator();
|
|
|
|
if data.is_allocator() {
|
rustc: Implement custom panic runtimes
This commit is an implementation of [RFC 1513] which allows applications to
alter the behavior of panics at compile time. A new compiler flag, `-C panic`,
is added and accepts the values `unwind` or `panic`, with the default being
`unwind`. This model affects how code is generated for the local crate, skipping
generation of landing pads with `-C panic=abort`.
[RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md
Panic implementations are then provided by crates tagged with
`#![panic_runtime]` and lazily required by crates with
`#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic
runtime must match the final product, and if the panic strategy is not `abort`
then the entire DAG must have the same panic strategy.
With the `-C panic=abort` strategy, users can expect a stable method to disable
generation of landing pads, improving optimization in niche scenarios,
decreasing compile time, and decreasing output binary size. With the `-C
panic=unwind` strategy users can expect the existing ability to isolate failure
in Rust code from the outside world.
Organizationally, this commit dismantles the `sys_common::unwind` module in
favor of some bits moving part of it to `libpanic_unwind` and the rest into the
`panicking` module in libstd. The custom panic runtime support is pretty similar
to the custom allocator support with the only major difference being how the
panic runtime is injected (takes the `-C panic` flag into account).
2016-04-08 23:18:40 +00:00
|
|
|
info!("{} required by rlib and is an allocator", data.name());
|
|
|
|
self.inject_dependency_if(cnum, "an allocator",
|
|
|
|
&|data| data.needs_allocator());
|
2015-06-25 17:07:01 +00:00
|
|
|
found_required_allocator = found_required_allocator ||
|
2016-10-27 09:18:45 +00:00
|
|
|
data.dep_kind.get() == DepKind::Explicit;
|
2015-06-25 17:07:01 +00:00
|
|
|
}
|
|
|
|
});
|
|
|
|
if !needs_allocator || found_required_allocator { return }
|
|
|
|
|
|
|
|
// At this point we've determined that we need an allocator and no
|
|
|
|
// previous allocator has been activated. We look through our outputs of
|
|
|
|
// crate types to see what kind of allocator types we may need.
|
|
|
|
//
|
|
|
|
// The main special output type here is that rlibs do **not** need an
|
|
|
|
// allocator linked in (they're just object files), only final products
|
|
|
|
// (exes, dylibs, staticlibs) need allocators.
|
|
|
|
let mut need_lib_alloc = false;
|
|
|
|
let mut need_exe_alloc = false;
|
|
|
|
for ct in self.sess.crate_types.borrow().iter() {
|
|
|
|
match *ct {
|
|
|
|
config::CrateTypeExecutable => need_exe_alloc = true,
|
|
|
|
config::CrateTypeDylib |
|
2016-10-03 16:49:39 +00:00
|
|
|
config::CrateTypeProcMacro |
|
2016-05-10 21:17:57 +00:00
|
|
|
config::CrateTypeCdylib |
|
2015-06-25 17:07:01 +00:00
|
|
|
config::CrateTypeStaticlib => need_lib_alloc = true,
|
2016-10-25 22:14:02 +00:00
|
|
|
config::CrateTypeRlib |
|
|
|
|
config::CrateTypeMetadata => {}
|
2015-06-25 17:07:01 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
if !need_lib_alloc && !need_exe_alloc { return }
|
|
|
|
|
|
|
|
// The default allocator crate comes from the custom target spec, and we
|
|
|
|
// choose between the standard library allocator or exe allocator. This
|
|
|
|
// distinction exists because the default allocator for binaries (where
|
|
|
|
// the world is Rust) is different than library (where the world is
|
|
|
|
// likely *not* Rust).
|
|
|
|
//
|
|
|
|
// If a library is being produced, but we're also flagged with `-C
|
|
|
|
// prefer-dynamic`, then we interpret this as a *Rust* dynamic library
|
|
|
|
// is being produced so we use the exe allocator instead.
|
|
|
|
//
|
|
|
|
// What this boils down to is:
|
|
|
|
//
|
|
|
|
// * Binaries use jemalloc
|
|
|
|
// * Staticlibs and Rust dylibs use system malloc
|
|
|
|
// * Rust dylibs used as dependencies to rust use jemalloc
|
|
|
|
let name = if need_lib_alloc && !self.sess.opts.cg.prefer_dynamic {
|
2016-11-16 10:52:37 +00:00
|
|
|
Symbol::intern(&self.sess.target.target.options.lib_allocation_crate)
|
2015-06-25 17:07:01 +00:00
|
|
|
} else {
|
2016-11-16 10:52:37 +00:00
|
|
|
Symbol::intern(&self.sess.target.target.options.exe_allocation_crate)
|
2015-06-25 17:07:01 +00:00
|
|
|
};
|
2016-10-27 09:18:45 +00:00
|
|
|
let dep_kind = DepKind::Implicit;
|
2016-10-27 05:03:11 +00:00
|
|
|
let (cnum, data) =
|
2016-10-27 09:18:45 +00:00
|
|
|
self.resolve_crate(&None, name, name, None, DUMMY_SP, PathKind::Crate, dep_kind);
|
2015-06-25 17:07:01 +00:00
|
|
|
|
rustc: Implement custom panic runtimes
This commit is an implementation of [RFC 1513] which allows applications to
alter the behavior of panics at compile time. A new compiler flag, `-C panic`,
is added and accepts the values `unwind` or `panic`, with the default being
`unwind`. This model affects how code is generated for the local crate, skipping
generation of landing pads with `-C panic=abort`.
[RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md
Panic implementations are then provided by crates tagged with
`#![panic_runtime]` and lazily required by crates with
`#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic
runtime must match the final product, and if the panic strategy is not `abort`
then the entire DAG must have the same panic strategy.
With the `-C panic=abort` strategy, users can expect a stable method to disable
generation of landing pads, improving optimization in niche scenarios,
decreasing compile time, and decreasing output binary size. With the `-C
panic=unwind` strategy users can expect the existing ability to isolate failure
in Rust code from the outside world.
Organizationally, this commit dismantles the `sys_common::unwind` module in
favor of some bits moving part of it to `libpanic_unwind` and the rest into the
`panicking` module in libstd. The custom panic runtime support is pretty similar
to the custom allocator support with the only major difference being how the
panic runtime is injected (takes the `-C panic` flag into account).
2016-04-08 23:18:40 +00:00
|
|
|
// Sanity check the crate we loaded to ensure that it is indeed an
|
|
|
|
// allocator.
|
2015-06-25 17:07:01 +00:00
|
|
|
if !data.is_allocator() {
|
|
|
|
self.sess.err(&format!("the allocator crate `{}` is not tagged \
|
|
|
|
with #![allocator]", data.name()));
|
|
|
|
}
|
|
|
|
|
|
|
|
self.sess.injected_allocator.set(Some(cnum));
|
rustc: Implement custom panic runtimes
This commit is an implementation of [RFC 1513] which allows applications to
alter the behavior of panics at compile time. A new compiler flag, `-C panic`,
is added and accepts the values `unwind` or `panic`, with the default being
`unwind`. This model affects how code is generated for the local crate, skipping
generation of landing pads with `-C panic=abort`.
[RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md
Panic implementations are then provided by crates tagged with
`#![panic_runtime]` and lazily required by crates with
`#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic
runtime must match the final product, and if the panic strategy is not `abort`
then the entire DAG must have the same panic strategy.
With the `-C panic=abort` strategy, users can expect a stable method to disable
generation of landing pads, improving optimization in niche scenarios,
decreasing compile time, and decreasing output binary size. With the `-C
panic=unwind` strategy users can expect the existing ability to isolate failure
in Rust code from the outside world.
Organizationally, this commit dismantles the `sys_common::unwind` module in
favor of some bits moving part of it to `libpanic_unwind` and the rest into the
`panicking` module in libstd. The custom panic runtime support is pretty similar
to the custom allocator support with the only major difference being how the
panic runtime is injected (takes the `-C panic` flag into account).
2016-04-08 23:18:40 +00:00
|
|
|
self.inject_dependency_if(cnum, "an allocator",
|
|
|
|
&|data| data.needs_allocator());
|
2015-06-25 17:07:01 +00:00
|
|
|
}
|
|
|
|
|
rustc: Implement custom panic runtimes
This commit is an implementation of [RFC 1513] which allows applications to
alter the behavior of panics at compile time. A new compiler flag, `-C panic`,
is added and accepts the values `unwind` or `panic`, with the default being
`unwind`. This model affects how code is generated for the local crate, skipping
generation of landing pads with `-C panic=abort`.
[RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md
Panic implementations are then provided by crates tagged with
`#![panic_runtime]` and lazily required by crates with
`#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic
runtime must match the final product, and if the panic strategy is not `abort`
then the entire DAG must have the same panic strategy.
With the `-C panic=abort` strategy, users can expect a stable method to disable
generation of landing pads, improving optimization in niche scenarios,
decreasing compile time, and decreasing output binary size. With the `-C
panic=unwind` strategy users can expect the existing ability to isolate failure
in Rust code from the outside world.
Organizationally, this commit dismantles the `sys_common::unwind` module in
favor of some bits moving part of it to `libpanic_unwind` and the rest into the
`panicking` module in libstd. The custom panic runtime support is pretty similar
to the custom allocator support with the only major difference being how the
panic runtime is injected (takes the `-C panic` flag into account).
2016-04-08 23:18:40 +00:00
|
|
|
fn inject_dependency_if(&self,
|
2016-08-31 11:00:29 +00:00
|
|
|
krate: CrateNum,
|
rustc: Implement custom panic runtimes
This commit is an implementation of [RFC 1513] which allows applications to
alter the behavior of panics at compile time. A new compiler flag, `-C panic`,
is added and accepts the values `unwind` or `panic`, with the default being
`unwind`. This model affects how code is generated for the local crate, skipping
generation of landing pads with `-C panic=abort`.
[RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md
Panic implementations are then provided by crates tagged with
`#![panic_runtime]` and lazily required by crates with
`#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic
runtime must match the final product, and if the panic strategy is not `abort`
then the entire DAG must have the same panic strategy.
With the `-C panic=abort` strategy, users can expect a stable method to disable
generation of landing pads, improving optimization in niche scenarios,
decreasing compile time, and decreasing output binary size. With the `-C
panic=unwind` strategy users can expect the existing ability to isolate failure
in Rust code from the outside world.
Organizationally, this commit dismantles the `sys_common::unwind` module in
favor of some bits moving part of it to `libpanic_unwind` and the rest into the
`panicking` module in libstd. The custom panic runtime support is pretty similar
to the custom allocator support with the only major difference being how the
panic runtime is injected (takes the `-C panic` flag into account).
2016-04-08 23:18:40 +00:00
|
|
|
what: &str,
|
2016-06-28 20:41:09 +00:00
|
|
|
needs_dep: &Fn(&cstore::CrateMetadata) -> bool) {
|
rustc: Implement custom panic runtimes
This commit is an implementation of [RFC 1513] which allows applications to
alter the behavior of panics at compile time. A new compiler flag, `-C panic`,
is added and accepts the values `unwind` or `panic`, with the default being
`unwind`. This model affects how code is generated for the local crate, skipping
generation of landing pads with `-C panic=abort`.
[RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md
Panic implementations are then provided by crates tagged with
`#![panic_runtime]` and lazily required by crates with
`#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic
runtime must match the final product, and if the panic strategy is not `abort`
then the entire DAG must have the same panic strategy.
With the `-C panic=abort` strategy, users can expect a stable method to disable
generation of landing pads, improving optimization in niche scenarios,
decreasing compile time, and decreasing output binary size. With the `-C
panic=unwind` strategy users can expect the existing ability to isolate failure
in Rust code from the outside world.
Organizationally, this commit dismantles the `sys_common::unwind` module in
favor of some bits moving part of it to `libpanic_unwind` and the rest into the
`panicking` module in libstd. The custom panic runtime support is pretty similar
to the custom allocator support with the only major difference being how the
panic runtime is injected (takes the `-C panic` flag into account).
2016-04-08 23:18:40 +00:00
|
|
|
// don't perform this validation if the session has errors, as one of
|
|
|
|
// those errors may indicate a circular dependency which could cause
|
|
|
|
// this to stack overflow.
|
|
|
|
if self.sess.has_errors() {
|
|
|
|
return
|
|
|
|
}
|
|
|
|
|
2015-06-25 17:07:01 +00:00
|
|
|
// Before we inject any dependencies, make sure we don't inject a
|
rustc: Implement custom panic runtimes
This commit is an implementation of [RFC 1513] which allows applications to
alter the behavior of panics at compile time. A new compiler flag, `-C panic`,
is added and accepts the values `unwind` or `panic`, with the default being
`unwind`. This model affects how code is generated for the local crate, skipping
generation of landing pads with `-C panic=abort`.
[RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md
Panic implementations are then provided by crates tagged with
`#![panic_runtime]` and lazily required by crates with
`#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic
runtime must match the final product, and if the panic strategy is not `abort`
then the entire DAG must have the same panic strategy.
With the `-C panic=abort` strategy, users can expect a stable method to disable
generation of landing pads, improving optimization in niche scenarios,
decreasing compile time, and decreasing output binary size. With the `-C
panic=unwind` strategy users can expect the existing ability to isolate failure
in Rust code from the outside world.
Organizationally, this commit dismantles the `sys_common::unwind` module in
favor of some bits moving part of it to `libpanic_unwind` and the rest into the
`panicking` module in libstd. The custom panic runtime support is pretty similar
to the custom allocator support with the only major difference being how the
panic runtime is injected (takes the `-C panic` flag into account).
2016-04-08 23:18:40 +00:00
|
|
|
// circular dependency by validating that this crate doesn't
|
|
|
|
// transitively depend on any crates satisfying `needs_dep`.
|
2016-06-28 20:41:09 +00:00
|
|
|
for dep in self.cstore.crate_dependencies_in_rpo(krate) {
|
|
|
|
let data = self.cstore.get_crate_data(dep);
|
|
|
|
if needs_dep(&data) {
|
|
|
|
self.sess.err(&format!("the crate `{}` cannot depend \
|
|
|
|
on a crate that needs {}, but \
|
|
|
|
it depends on `{}`",
|
|
|
|
self.cstore.get_crate_data(krate).name(),
|
|
|
|
what,
|
|
|
|
data.name()));
|
|
|
|
}
|
|
|
|
}
|
rustc: Implement custom panic runtimes
This commit is an implementation of [RFC 1513] which allows applications to
alter the behavior of panics at compile time. A new compiler flag, `-C panic`,
is added and accepts the values `unwind` or `panic`, with the default being
`unwind`. This model affects how code is generated for the local crate, skipping
generation of landing pads with `-C panic=abort`.
[RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md
Panic implementations are then provided by crates tagged with
`#![panic_runtime]` and lazily required by crates with
`#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic
runtime must match the final product, and if the panic strategy is not `abort`
then the entire DAG must have the same panic strategy.
With the `-C panic=abort` strategy, users can expect a stable method to disable
generation of landing pads, improving optimization in niche scenarios,
decreasing compile time, and decreasing output binary size. With the `-C
panic=unwind` strategy users can expect the existing ability to isolate failure
in Rust code from the outside world.
Organizationally, this commit dismantles the `sys_common::unwind` module in
favor of some bits moving part of it to `libpanic_unwind` and the rest into the
`panicking` module in libstd. The custom panic runtime support is pretty similar
to the custom allocator support with the only major difference being how the
panic runtime is injected (takes the `-C panic` flag into account).
2016-04-08 23:18:40 +00:00
|
|
|
|
|
|
|
// All crates satisfying `needs_dep` do not explicitly depend on the
|
|
|
|
// crate provided for this compile, but in order for this compilation to
|
|
|
|
// be successfully linked we need to inject a dependency (to order the
|
|
|
|
// crates on the command line correctly).
|
2015-11-21 19:39:05 +00:00
|
|
|
self.cstore.iter_crate_data(|cnum, data| {
|
rustc: Implement custom panic runtimes
This commit is an implementation of [RFC 1513] which allows applications to
alter the behavior of panics at compile time. A new compiler flag, `-C panic`,
is added and accepts the values `unwind` or `panic`, with the default being
`unwind`. This model affects how code is generated for the local crate, skipping
generation of landing pads with `-C panic=abort`.
[RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md
Panic implementations are then provided by crates tagged with
`#![panic_runtime]` and lazily required by crates with
`#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic
runtime must match the final product, and if the panic strategy is not `abort`
then the entire DAG must have the same panic strategy.
With the `-C panic=abort` strategy, users can expect a stable method to disable
generation of landing pads, improving optimization in niche scenarios,
decreasing compile time, and decreasing output binary size. With the `-C
panic=unwind` strategy users can expect the existing ability to isolate failure
in Rust code from the outside world.
Organizationally, this commit dismantles the `sys_common::unwind` module in
favor of some bits moving part of it to `libpanic_unwind` and the rest into the
`panicking` module in libstd. The custom panic runtime support is pretty similar
to the custom allocator support with the only major difference being how the
panic runtime is injected (takes the `-C panic` flag into account).
2016-04-08 23:18:40 +00:00
|
|
|
if !needs_dep(data) {
|
2015-06-25 17:07:01 +00:00
|
|
|
return
|
|
|
|
}
|
|
|
|
|
rustc: Implement custom panic runtimes
This commit is an implementation of [RFC 1513] which allows applications to
alter the behavior of panics at compile time. A new compiler flag, `-C panic`,
is added and accepts the values `unwind` or `panic`, with the default being
`unwind`. This model affects how code is generated for the local crate, skipping
generation of landing pads with `-C panic=abort`.
[RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md
Panic implementations are then provided by crates tagged with
`#![panic_runtime]` and lazily required by crates with
`#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic
runtime must match the final product, and if the panic strategy is not `abort`
then the entire DAG must have the same panic strategy.
With the `-C panic=abort` strategy, users can expect a stable method to disable
generation of landing pads, improving optimization in niche scenarios,
decreasing compile time, and decreasing output binary size. With the `-C
panic=unwind` strategy users can expect the existing ability to isolate failure
in Rust code from the outside world.
Organizationally, this commit dismantles the `sys_common::unwind` module in
favor of some bits moving part of it to `libpanic_unwind` and the rest into the
`panicking` module in libstd. The custom panic runtime support is pretty similar
to the custom allocator support with the only major difference being how the
panic runtime is injected (takes the `-C panic` flag into account).
2016-04-08 23:18:40 +00:00
|
|
|
info!("injecting a dep from {} to {}", cnum, krate);
|
2016-06-28 20:41:09 +00:00
|
|
|
data.cnum_map.borrow_mut().push(krate);
|
2015-06-25 17:07:01 +00:00
|
|
|
});
|
|
|
|
}
|
2013-12-25 18:10:33 +00:00
|
|
|
}
|
2015-02-11 17:29:49 +00:00
|
|
|
|
2016-09-16 02:52:09 +00:00
|
|
|
impl<'a> CrateLoader<'a> {
|
2016-10-19 09:34:19 +00:00
|
|
|
pub fn preprocess(&mut self, krate: &ast::Crate) {
|
2016-09-16 02:52:09 +00:00
|
|
|
for attr in krate.attrs.iter().filter(|m| m.name() == "link_args") {
|
2016-11-16 10:52:37 +00:00
|
|
|
if let Some(linkarg) = attr.value_str() {
|
|
|
|
self.cstore.add_used_link_args(&linkarg.as_str());
|
2015-07-30 19:59:42 +00:00
|
|
|
}
|
|
|
|
}
|
2015-07-30 21:20:36 +00:00
|
|
|
}
|
2015-07-30 19:59:42 +00:00
|
|
|
|
2016-04-14 02:51:21 +00:00
|
|
|
fn process_foreign_mod(&mut self, i: &ast::Item, fm: &ast::ForeignMod) {
|
2016-02-05 12:13:36 +00:00
|
|
|
if fm.abi == Abi::Rust || fm.abi == Abi::RustIntrinsic || fm.abi == Abi::PlatformIntrinsic {
|
2015-07-30 21:20:36 +00:00
|
|
|
return;
|
|
|
|
}
|
2015-07-30 19:59:42 +00:00
|
|
|
|
2015-07-30 21:20:36 +00:00
|
|
|
// First, add all of the custom #[link_args] attributes
|
|
|
|
for m in i.attrs.iter().filter(|a| a.check_name("link_args")) {
|
|
|
|
if let Some(linkarg) = m.value_str() {
|
2016-11-16 10:52:37 +00:00
|
|
|
self.cstore.add_used_link_args(&linkarg.as_str());
|
2015-07-30 19:59:42 +00:00
|
|
|
}
|
2015-07-30 21:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// Next, process all of the #[link(..)]-style arguments
|
|
|
|
for m in i.attrs.iter().filter(|a| a.check_name("link")) {
|
|
|
|
let items = match m.meta_item_list() {
|
|
|
|
Some(item) => item,
|
|
|
|
None => continue,
|
|
|
|
};
|
|
|
|
let kind = items.iter().find(|k| {
|
|
|
|
k.check_name("kind")
|
2016-11-16 10:52:37 +00:00
|
|
|
}).and_then(|a| a.value_str()).map(Symbol::as_str);
|
2015-07-30 21:20:36 +00:00
|
|
|
let kind = match kind.as_ref().map(|s| &s[..]) {
|
|
|
|
Some("static") => cstore::NativeStatic,
|
|
|
|
Some("dylib") => cstore::NativeUnknown,
|
|
|
|
Some("framework") => cstore::NativeFramework,
|
|
|
|
Some(k) => {
|
2016-08-28 13:55:43 +00:00
|
|
|
struct_span_err!(self.sess, m.span, E0458,
|
|
|
|
"unknown kind: `{}`", k)
|
|
|
|
.span_label(m.span, &format!("unknown kind")).emit();
|
2015-07-30 21:20:36 +00:00
|
|
|
cstore::NativeUnknown
|
|
|
|
}
|
|
|
|
None => cstore::NativeUnknown
|
|
|
|
};
|
|
|
|
let n = items.iter().find(|n| {
|
|
|
|
n.check_name("name")
|
|
|
|
}).and_then(|a| a.value_str());
|
|
|
|
let n = match n {
|
|
|
|
Some(n) => n,
|
|
|
|
None => {
|
2016-08-28 12:55:39 +00:00
|
|
|
struct_span_err!(self.sess, m.span, E0459,
|
|
|
|
"#[link(...)] specified without `name = \"foo\"`")
|
|
|
|
.span_label(m.span, &format!("missing `name` argument")).emit();
|
2016-11-16 10:52:37 +00:00
|
|
|
Symbol::intern("foo")
|
2015-07-30 21:20:36 +00:00
|
|
|
}
|
|
|
|
};
|
rustc: Implement #[link(cfg(..))] and crt-static
This commit is an implementation of [RFC 1721] which adds a new target feature
to the compiler, `crt-static`, which can be used to select how the C runtime for
a target is linked. Most targets dynamically linke the C runtime by default with
the notable exception of some of the musl targets.
[RFC 1721]: https://github.com/rust-lang/rfcs/blob/master/text/1721-crt-static.md
This commit first adds the new target-feature, `crt-static`. If enabled, then
the `cfg(target_feature = "crt-static")` will be available. Targets like musl
will have this enabled by default. This feature can be controlled through the
standard target-feature interface, `-C target-feature=+crt-static` or
`-C target-feature=-crt-static`.
Next this adds an gated and unstable `#[link(cfg(..))]` feature to enable the
`crt-static` semantics we want with libc. The exact behavior of this attribute
is a little squishy, but it's intended to be a forever-unstable
implementation detail of the liblibc crate.
Specifically the `#[link(cfg(..))]` annotation means that the `#[link]`
directive is only active in a compilation unit if that `cfg` value is satisfied.
For example when compiling an rlib, these directives are just encoded and
ignored for dylibs, and all staticlibs are continued to be put into the rlib as
usual. When placing that rlib into a staticlib, executable, or dylib, however,
the `cfg` is evaluated *as if it were defined in the final artifact* and the
library is decided to be linked or not.
Essentially, what'll happen is:
* On MSVC with `-C target-feature=-crt-static`, the `msvcrt.lib` library will be
linked to.
* On MSVC with `-C target-feature=+crt-static`, the `libcmt.lib` library will be
linked to.
* On musl with `-C target-feature=-crt-static`, the object files in liblibc.rlib
are removed and `-lc` is passed instead.
* On musl with `-C target-feature=+crt-static`, the object files in liblibc.rlib
are used and `-lc` is not passed.
This commit does **not** include an update to the liblibc module to implement
these changes. I plan to do that just after the 1.14.0 beta release is cut to
ensure we get ample time to test this feature.
cc #37406
2016-10-31 23:40:13 +00:00
|
|
|
let cfg = items.iter().find(|k| {
|
|
|
|
k.check_name("cfg")
|
|
|
|
}).and_then(|a| a.meta_item_list());
|
|
|
|
let cfg = cfg.map(|list| {
|
|
|
|
list[0].meta_item().unwrap().clone()
|
|
|
|
});
|
|
|
|
let lib = NativeLibrary {
|
2016-11-16 10:52:37 +00:00
|
|
|
name: n,
|
rustc: Implement #[link(cfg(..))] and crt-static
This commit is an implementation of [RFC 1721] which adds a new target feature
to the compiler, `crt-static`, which can be used to select how the C runtime for
a target is linked. Most targets dynamically linke the C runtime by default with
the notable exception of some of the musl targets.
[RFC 1721]: https://github.com/rust-lang/rfcs/blob/master/text/1721-crt-static.md
This commit first adds the new target-feature, `crt-static`. If enabled, then
the `cfg(target_feature = "crt-static")` will be available. Targets like musl
will have this enabled by default. This feature can be controlled through the
standard target-feature interface, `-C target-feature=+crt-static` or
`-C target-feature=-crt-static`.
Next this adds an gated and unstable `#[link(cfg(..))]` feature to enable the
`crt-static` semantics we want with libc. The exact behavior of this attribute
is a little squishy, but it's intended to be a forever-unstable
implementation detail of the liblibc crate.
Specifically the `#[link(cfg(..))]` annotation means that the `#[link]`
directive is only active in a compilation unit if that `cfg` value is satisfied.
For example when compiling an rlib, these directives are just encoded and
ignored for dylibs, and all staticlibs are continued to be put into the rlib as
usual. When placing that rlib into a staticlib, executable, or dylib, however,
the `cfg` is evaluated *as if it were defined in the final artifact* and the
library is decided to be linked or not.
Essentially, what'll happen is:
* On MSVC with `-C target-feature=-crt-static`, the `msvcrt.lib` library will be
linked to.
* On MSVC with `-C target-feature=+crt-static`, the `libcmt.lib` library will be
linked to.
* On musl with `-C target-feature=-crt-static`, the object files in liblibc.rlib
are removed and `-lc` is passed instead.
* On musl with `-C target-feature=+crt-static`, the object files in liblibc.rlib
are used and `-lc` is not passed.
This commit does **not** include an update to the liblibc module to implement
these changes. I plan to do that just after the 1.14.0 beta release is cut to
ensure we get ample time to test this feature.
cc #37406
2016-10-31 23:40:13 +00:00
|
|
|
kind: kind,
|
|
|
|
cfg: cfg,
|
|
|
|
};
|
|
|
|
register_native_lib(self.sess, self.cstore, Some(m.span), lib);
|
2015-07-30 21:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// Finally, process the #[linked_from = "..."] attribute
|
|
|
|
for m in i.attrs.iter().filter(|a| a.check_name("linked_from")) {
|
|
|
|
let lib_name = match m.value_str() {
|
|
|
|
Some(name) => name,
|
|
|
|
None => continue,
|
|
|
|
};
|
2016-10-19 09:34:19 +00:00
|
|
|
let list = self.foreign_item_map.entry(lib_name.to_string())
|
2015-07-30 21:20:36 +00:00
|
|
|
.or_insert(Vec::new());
|
|
|
|
list.extend(fm.items.iter().map(|it| it.id));
|
2015-07-30 19:59:42 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-09-16 02:52:09 +00:00
|
|
|
impl<'a> middle::cstore::CrateLoader for CrateLoader<'a> {
|
|
|
|
fn postprocess(&mut self, krate: &ast::Crate) {
|
2016-10-19 09:34:19 +00:00
|
|
|
self.inject_allocator_crate();
|
|
|
|
self.inject_panic_runtime(krate);
|
2016-09-16 02:52:09 +00:00
|
|
|
|
|
|
|
if log_enabled!(log::INFO) {
|
|
|
|
dump_crates(&self.cstore);
|
|
|
|
}
|
|
|
|
|
|
|
|
for &(ref name, kind) in &self.sess.opts.libs {
|
rustc: Implement #[link(cfg(..))] and crt-static
This commit is an implementation of [RFC 1721] which adds a new target feature
to the compiler, `crt-static`, which can be used to select how the C runtime for
a target is linked. Most targets dynamically linke the C runtime by default with
the notable exception of some of the musl targets.
[RFC 1721]: https://github.com/rust-lang/rfcs/blob/master/text/1721-crt-static.md
This commit first adds the new target-feature, `crt-static`. If enabled, then
the `cfg(target_feature = "crt-static")` will be available. Targets like musl
will have this enabled by default. This feature can be controlled through the
standard target-feature interface, `-C target-feature=+crt-static` or
`-C target-feature=-crt-static`.
Next this adds an gated and unstable `#[link(cfg(..))]` feature to enable the
`crt-static` semantics we want with libc. The exact behavior of this attribute
is a little squishy, but it's intended to be a forever-unstable
implementation detail of the liblibc crate.
Specifically the `#[link(cfg(..))]` annotation means that the `#[link]`
directive is only active in a compilation unit if that `cfg` value is satisfied.
For example when compiling an rlib, these directives are just encoded and
ignored for dylibs, and all staticlibs are continued to be put into the rlib as
usual. When placing that rlib into a staticlib, executable, or dylib, however,
the `cfg` is evaluated *as if it were defined in the final artifact* and the
library is decided to be linked or not.
Essentially, what'll happen is:
* On MSVC with `-C target-feature=-crt-static`, the `msvcrt.lib` library will be
linked to.
* On MSVC with `-C target-feature=+crt-static`, the `libcmt.lib` library will be
linked to.
* On musl with `-C target-feature=-crt-static`, the object files in liblibc.rlib
are removed and `-lc` is passed instead.
* On musl with `-C target-feature=+crt-static`, the object files in liblibc.rlib
are used and `-lc` is not passed.
This commit does **not** include an update to the liblibc module to implement
these changes. I plan to do that just after the 1.14.0 beta release is cut to
ensure we get ample time to test this feature.
cc #37406
2016-10-31 23:40:13 +00:00
|
|
|
let lib = NativeLibrary {
|
2016-11-16 10:52:37 +00:00
|
|
|
name: Symbol::intern(name),
|
rustc: Implement #[link(cfg(..))] and crt-static
This commit is an implementation of [RFC 1721] which adds a new target feature
to the compiler, `crt-static`, which can be used to select how the C runtime for
a target is linked. Most targets dynamically linke the C runtime by default with
the notable exception of some of the musl targets.
[RFC 1721]: https://github.com/rust-lang/rfcs/blob/master/text/1721-crt-static.md
This commit first adds the new target-feature, `crt-static`. If enabled, then
the `cfg(target_feature = "crt-static")` will be available. Targets like musl
will have this enabled by default. This feature can be controlled through the
standard target-feature interface, `-C target-feature=+crt-static` or
`-C target-feature=-crt-static`.
Next this adds an gated and unstable `#[link(cfg(..))]` feature to enable the
`crt-static` semantics we want with libc. The exact behavior of this attribute
is a little squishy, but it's intended to be a forever-unstable
implementation detail of the liblibc crate.
Specifically the `#[link(cfg(..))]` annotation means that the `#[link]`
directive is only active in a compilation unit if that `cfg` value is satisfied.
For example when compiling an rlib, these directives are just encoded and
ignored for dylibs, and all staticlibs are continued to be put into the rlib as
usual. When placing that rlib into a staticlib, executable, or dylib, however,
the `cfg` is evaluated *as if it were defined in the final artifact* and the
library is decided to be linked or not.
Essentially, what'll happen is:
* On MSVC with `-C target-feature=-crt-static`, the `msvcrt.lib` library will be
linked to.
* On MSVC with `-C target-feature=+crt-static`, the `libcmt.lib` library will be
linked to.
* On musl with `-C target-feature=-crt-static`, the object files in liblibc.rlib
are removed and `-lc` is passed instead.
* On musl with `-C target-feature=+crt-static`, the object files in liblibc.rlib
are used and `-lc` is not passed.
This commit does **not** include an update to the liblibc module to implement
these changes. I plan to do that just after the 1.14.0 beta release is cut to
ensure we get ample time to test this feature.
cc #37406
2016-10-31 23:40:13 +00:00
|
|
|
kind: kind,
|
|
|
|
cfg: None,
|
|
|
|
};
|
|
|
|
register_native_lib(self.sess, self.cstore, None, lib);
|
2016-09-16 02:52:09 +00:00
|
|
|
}
|
2016-10-19 09:34:19 +00:00
|
|
|
self.register_statically_included_foreign_items();
|
2016-09-16 02:52:09 +00:00
|
|
|
}
|
|
|
|
|
2016-11-05 20:30:40 +00:00
|
|
|
fn process_item(&mut self, item: &ast::Item, definitions: &Definitions) {
|
2016-09-16 02:52:09 +00:00
|
|
|
match item.node {
|
|
|
|
ast::ItemKind::ExternCrate(_) => {}
|
2016-11-05 20:30:40 +00:00
|
|
|
ast::ItemKind::ForeignMod(ref fm) => return self.process_foreign_mod(item, fm),
|
|
|
|
_ => return,
|
2016-09-16 02:52:09 +00:00
|
|
|
}
|
|
|
|
|
2016-10-20 00:52:58 +00:00
|
|
|
let info = self.extract_crate_info(item).unwrap();
|
|
|
|
let (cnum, ..) = self.resolve_crate(
|
2016-11-16 10:52:37 +00:00
|
|
|
&None, info.ident, info.name, None, item.span, PathKind::Crate, info.dep_kind,
|
2016-10-20 00:52:58 +00:00
|
|
|
);
|
2016-09-16 02:52:09 +00:00
|
|
|
|
2016-10-20 00:52:58 +00:00
|
|
|
let def_id = definitions.opt_local_def_id(item.id).unwrap();
|
|
|
|
let len = definitions.def_path(def_id.index).data.len();
|
2016-09-16 02:52:09 +00:00
|
|
|
|
2016-10-20 00:52:58 +00:00
|
|
|
let extern_crate =
|
|
|
|
ExternCrate { def_id: def_id, span: item.span, direct: true, path_len: len };
|
2016-11-08 03:02:55 +00:00
|
|
|
self.update_extern_crate(cnum, extern_crate, &mut FxHashSet());
|
2016-10-20 00:52:58 +00:00
|
|
|
self.cstore.add_extern_mod_stmt_cnum(info.id, cnum);
|
2016-09-16 02:52:09 +00:00
|
|
|
}
|
2016-05-10 13:52:33 +00:00
|
|
|
}
|