2014-02-10 08:36:31 -06:00
|
|
|
// Copyright 2012-2014 The Rust Project Developers. See the COPYRIGHT
|
2012-12-03 18:48:01 -06: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.
|
|
|
|
|
2014-03-21 20:05:05 -05:00
|
|
|
#![allow(non_camel_case_types)]
|
2014-02-10 08:36:31 -06:00
|
|
|
|
2012-07-04 16:53:12 -05:00
|
|
|
//! Validates all used crates and extern libraries and loads their metadata
|
2011-03-15 18:30:43 -05:00
|
|
|
|
2014-02-24 21:45:20 -06:00
|
|
|
use back::svh::Svh;
|
Add generation of static libraries to rustc
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes #552
2013-11-15 16:03:29 -06:00
|
|
|
use driver::session::Session;
|
2014-05-06 06:38:01 -05:00
|
|
|
use driver::{driver, config};
|
2012-12-23 16:41:37 -06:00
|
|
|
use metadata::cstore;
|
2014-04-25 11:06:49 -05:00
|
|
|
use metadata::cstore::{CStore, CrateSource};
|
2012-12-23 16:41:37 -06:00
|
|
|
use metadata::decoder;
|
|
|
|
use metadata::loader;
|
2014-04-03 10:43:57 -05:00
|
|
|
use metadata::loader::CratePaths;
|
2014-05-24 18:16:10 -05:00
|
|
|
use plugin::load::PluginMetadata;
|
2012-12-23 16:41:37 -06:00
|
|
|
|
2014-03-27 12:28:38 -05:00
|
|
|
use std::rc::Rc;
|
2014-05-29 21:03:06 -05:00
|
|
|
use std::collections::HashMap;
|
2014-10-30 20:25:08 -05:00
|
|
|
use std::collections::hash_map::{Occupied, Vacant};
|
2013-07-19 20:42:11 -05:00
|
|
|
use syntax::ast;
|
2013-11-30 13:39:55 -06:00
|
|
|
use syntax::abi;
|
2012-09-04 13:54:36 -05:00
|
|
|
use syntax::attr;
|
2013-07-19 06:51:37 -05:00
|
|
|
use syntax::attr::AttrMetaMethods;
|
2014-02-09 21:29:21 -06:00
|
|
|
use syntax::codemap::{Span};
|
2013-12-31 08:17:59 -06:00
|
|
|
use syntax::diagnostic::SpanHandler;
|
2014-04-17 10:52:25 -05:00
|
|
|
use syntax::parse::token::InternedString;
|
2013-06-04 14:34:25 -05:00
|
|
|
use syntax::parse::token;
|
2013-08-26 04:01:39 -05:00
|
|
|
use syntax::visit;
|
2014-08-14 16:42:37 -05:00
|
|
|
use util::fs;
|
2011-03-15 18:30:43 -05:00
|
|
|
|
2014-04-07 14:14:33 -05:00
|
|
|
struct Env<'a> {
|
|
|
|
sess: &'a Session,
|
|
|
|
next_crate_num: ast::CrateNum,
|
|
|
|
}
|
|
|
|
|
2012-07-03 18:11:00 -05:00
|
|
|
// Traverses an AST, reading all the information about use'd crates and extern
|
2011-07-07 23:03:09 -05:00
|
|
|
// libraries necessary for later resolving, typechecking, linking, etc.
|
2014-03-05 08:36:01 -06:00
|
|
|
pub fn read_crates(sess: &Session,
|
2014-04-17 10:52:25 -05:00
|
|
|
krate: &ast::Crate) {
|
2013-12-21 18:46:55 -06:00
|
|
|
let mut e = Env {
|
Add generation of static libraries to rustc
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes #552
2013-11-15 16:03:29 -06:00
|
|
|
sess: sess,
|
2014-04-07 14:14:33 -05:00
|
|
|
next_crate_num: sess.cstore.next_crate_num(),
|
2013-02-04 16:02:01 -06:00
|
|
|
};
|
2014-02-05 15:15:24 -06:00
|
|
|
visit_crate(&e, krate);
|
2014-09-12 05:10:30 -05:00
|
|
|
visit::walk_crate(&mut e, krate);
|
2014-04-07 14:14:33 -05:00
|
|
|
dump_crates(&sess.cstore);
|
2014-10-21 01:04:16 -05:00
|
|
|
warn_if_multiple_versions(sess.diagnostic(), &sess.cstore);
|
|
|
|
|
|
|
|
for &(ref name, kind) in sess.opts.libs.iter() {
|
|
|
|
register_native_lib(sess, None, name.clone(), kind);
|
|
|
|
}
|
2013-12-21 18:46:55 -06:00
|
|
|
}
|
|
|
|
|
2014-09-09 17:54:36 -05:00
|
|
|
impl<'a, 'v> visit::Visitor<'v> for Env<'a> {
|
2014-09-12 05:10:30 -05:00
|
|
|
fn visit_view_item(&mut self, a: &ast::ViewItem) {
|
2014-03-05 08:36:01 -06:00
|
|
|
visit_view_item(self, a);
|
2014-09-12 05:10:30 -05:00
|
|
|
visit::walk_view_item(self, a);
|
2013-08-26 04:01:39 -05:00
|
|
|
}
|
2014-09-12 05:10:30 -05:00
|
|
|
fn visit_item(&mut self, a: &ast::Item) {
|
2014-03-05 08:36:01 -06:00
|
|
|
visit_item(self, a);
|
2014-09-12 05:10:30 -05:00
|
|
|
visit::walk_item(self, a);
|
2013-08-26 04:01:39 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-04-07 14:14:33 -05:00
|
|
|
fn dump_crates(cstore: &CStore) {
|
2013-10-21 15:08:31 -05:00
|
|
|
debug!("resolved crates:");
|
2014-04-25 11:06:49 -05:00
|
|
|
cstore.iter_crate_data_origins(|_, data, opt_source| {
|
2014-06-06 15:21:18 -05:00
|
|
|
debug!(" name: {}", data.name());
|
2014-04-07 14:14:33 -05:00
|
|
|
debug!(" cnum: {}", data.cnum);
|
|
|
|
debug!(" hash: {}", data.hash());
|
2014-04-25 11:06:49 -05:00
|
|
|
opt_source.map(|cs| {
|
|
|
|
let CrateSource { dylib, rlib, cnum: _ } = cs;
|
|
|
|
dylib.map(|dl| debug!(" dylib: {}", dl.display()));
|
|
|
|
rlib.map(|rl| debug!(" rlib: {}", rl.display()));
|
|
|
|
});
|
2014-04-07 14:14:33 -05:00
|
|
|
})
|
2012-04-09 17:06:38 -05:00
|
|
|
}
|
|
|
|
|
2014-04-07 14:14:33 -05:00
|
|
|
fn warn_if_multiple_versions(diag: &SpanHandler, cstore: &CStore) {
|
|
|
|
let mut map = HashMap::new();
|
|
|
|
cstore.iter_crate_data(|cnum, data| {
|
2014-09-18 16:05:52 -05:00
|
|
|
match map.entry(data.name()) {
|
|
|
|
Vacant(entry) => { entry.set(vec![cnum]); },
|
|
|
|
Occupied(mut entry) => { entry.get_mut().push(cnum); },
|
|
|
|
}
|
2014-04-07 14:14:33 -05:00
|
|
|
});
|
2012-04-06 01:42:32 -05:00
|
|
|
|
2014-09-14 22:27:36 -05:00
|
|
|
for (name, dupes) in map.into_iter() {
|
2014-04-07 14:14:33 -05:00
|
|
|
if dupes.len() == 1 { continue }
|
|
|
|
diag.handler().warn(
|
2014-06-06 15:21:18 -05:00
|
|
|
format!("using multiple versions of crate `{}`", name).as_slice());
|
2014-09-14 22:27:36 -05:00
|
|
|
for dupe in dupes.into_iter() {
|
2014-04-07 14:14:33 -05:00
|
|
|
let data = cstore.get_crate_data(dupe);
|
|
|
|
diag.span_note(data.span, "used here");
|
2014-06-06 15:21:18 -05:00
|
|
|
loader::note_crate_name(diag, data.name().as_slice());
|
2012-04-06 01:42:32 -05:00
|
|
|
}
|
|
|
|
}
|
2011-07-07 23:03:09 -05:00
|
|
|
}
|
|
|
|
|
2013-07-19 00:38:55 -05:00
|
|
|
fn visit_crate(e: &Env, c: &ast::Crate) {
|
2014-01-08 12:35:15 -06:00
|
|
|
for a in c.attrs.iter().filter(|m| m.name().equiv(&("link_args"))) {
|
2013-07-19 06:51:37 -05:00
|
|
|
match a.value_str() {
|
2014-03-09 08:20:44 -05:00
|
|
|
Some(ref linkarg) => e.sess.cstore.add_used_link_args(linkarg.get()),
|
|
|
|
None => { /* fallthrough */ }
|
2013-02-16 09:21:56 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-04-07 14:16:43 -05:00
|
|
|
fn should_link(i: &ast::ViewItem) -> bool {
|
|
|
|
i.attrs.iter().all(|attr| {
|
2014-01-21 12:08:10 -06:00
|
|
|
attr.name().get() != "phase" ||
|
2013-12-25 12:10:33 -06:00
|
|
|
attr.meta_item_list().map_or(false, |phases| {
|
2014-02-28 17:25:15 -06:00
|
|
|
attr::contains_name(phases.as_slice(), "link")
|
2013-12-25 12:10:33 -06:00
|
|
|
})
|
2014-04-07 14:16:43 -05:00
|
|
|
})
|
|
|
|
}
|
2013-12-25 12:10:33 -06:00
|
|
|
|
2014-04-07 14:16:43 -05:00
|
|
|
fn visit_view_item(e: &mut Env, i: &ast::ViewItem) {
|
|
|
|
if !should_link(i) {
|
2013-12-25 12:10:33 -06:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2014-02-24 20:13:51 -06:00
|
|
|
match extract_crate_info(e, i) {
|
2013-12-25 12:10:33 -06:00
|
|
|
Some(info) => {
|
2014-05-09 20:45:36 -05:00
|
|
|
let (cnum, _, _) = resolve_crate(e,
|
|
|
|
&None,
|
|
|
|
info.ident.as_slice(),
|
2014-06-06 15:21:18 -05:00
|
|
|
info.name.as_slice(),
|
2014-05-09 20:45:36 -05:00
|
|
|
None,
|
2014-04-07 14:16:43 -05:00
|
|
|
i.span);
|
2013-12-25 12:10:33 -06:00
|
|
|
e.sess.cstore.add_extern_mod_stmt_cnum(info.id, cnum);
|
|
|
|
}
|
|
|
|
None => ()
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
struct CrateInfo {
|
2014-05-22 18:57:53 -05:00
|
|
|
ident: String,
|
2014-06-06 15:21:18 -05:00
|
|
|
name: String,
|
2013-12-25 12:10:33 -06:00
|
|
|
id: ast::NodeId,
|
2014-04-07 14:16:43 -05:00
|
|
|
should_link: bool,
|
2013-12-25 12:10:33 -06:00
|
|
|
}
|
|
|
|
|
2014-02-24 20:13:51 -06:00
|
|
|
fn extract_crate_info(e: &Env, i: &ast::ViewItem) -> Option<CrateInfo> {
|
2013-03-20 00:17:42 -05:00
|
|
|
match i.node {
|
2014-03-07 01:57:45 -06:00
|
|
|
ast::ViewItemExternCrate(ident, ref path_opt, id) => {
|
2014-02-13 23:07:09 -06:00
|
|
|
let ident = token::get_ident(ident);
|
2014-09-12 00:49:41 -05:00
|
|
|
debug!("resolving extern crate stmt. ident: {} path_opt: {}",
|
2014-02-13 23:07:09 -06:00
|
|
|
ident, path_opt);
|
2014-06-06 15:21:18 -05:00
|
|
|
let name = match *path_opt {
|
2014-01-15 20:30:40 -06:00
|
|
|
Some((ref path_str, _)) => {
|
2014-06-21 05:39:03 -05:00
|
|
|
let name = path_str.get().to_string();
|
2014-06-06 15:21:18 -05:00
|
|
|
validate_crate_name(Some(e.sess), name.as_slice(),
|
|
|
|
Some(i.span));
|
|
|
|
name
|
2013-12-25 12:10:33 -06:00
|
|
|
}
|
2014-06-21 05:39:03 -05:00
|
|
|
None => ident.get().to_string(),
|
2013-12-25 12:10:33 -06:00
|
|
|
};
|
|
|
|
Some(CrateInfo {
|
2014-05-25 05:17:19 -05:00
|
|
|
ident: ident.get().to_string(),
|
2014-06-06 15:21:18 -05:00
|
|
|
name: name,
|
2014-02-24 20:13:51 -06:00
|
|
|
id: id,
|
2014-04-07 14:16:43 -05:00
|
|
|
should_link: should_link(i),
|
2013-12-25 12:10:33 -06:00
|
|
|
})
|
|
|
|
}
|
|
|
|
_ => None
|
|
|
|
}
|
2011-07-07 23:37:56 -05:00
|
|
|
}
|
|
|
|
|
2014-06-06 15:21:18 -05:00
|
|
|
pub fn validate_crate_name(sess: Option<&Session>, s: &str, sp: Option<Span>) {
|
|
|
|
let err = |s: &str| {
|
|
|
|
match (sp, sess) {
|
2014-10-09 14:17:22 -05:00
|
|
|
(_, None) => panic!("{}", s),
|
2014-06-06 15:21:18 -05:00
|
|
|
(Some(sp), Some(sess)) => sess.span_err(sp, s),
|
|
|
|
(None, Some(sess)) => sess.err(s),
|
|
|
|
}
|
|
|
|
};
|
|
|
|
if s.len() == 0 {
|
|
|
|
err("crate name must not be empty");
|
|
|
|
}
|
|
|
|
for c in s.chars() {
|
|
|
|
if c.is_alphanumeric() { continue }
|
|
|
|
if c == '_' || c == '-' { continue }
|
2014-07-03 09:43:12 -05:00
|
|
|
err(format!("invalid character `{}` in crate name: `{}`", c, s).as_slice());
|
2014-06-06 15:21:18 -05:00
|
|
|
}
|
|
|
|
match sess {
|
|
|
|
Some(sess) => sess.abort_if_errors(),
|
|
|
|
None => {}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-01-09 07:05:33 -06:00
|
|
|
fn visit_item(e: &Env, i: &ast::Item) {
|
2013-03-20 00:17:42 -05:00
|
|
|
match i.node {
|
2014-01-09 07:05:33 -06:00
|
|
|
ast::ItemForeignMod(ref fm) => {
|
2014-04-02 03:19:41 -05:00
|
|
|
if fm.abi == abi::Rust || fm.abi == abi::RustIntrinsic {
|
Add generation of static libraries to rustc
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes #552
2013-11-15 16:03:29 -06:00
|
|
|
return;
|
|
|
|
}
|
2013-10-10 14:57:34 -05:00
|
|
|
|
Add generation of static libraries to rustc
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes #552
2013-11-15 16:03:29 -06:00
|
|
|
// First, add all of the custom link_args attributes
|
|
|
|
let link_args = i.attrs.iter()
|
2014-01-08 12:35:15 -06:00
|
|
|
.filter_map(|at| if at.name().equiv(&("link_args")) {
|
|
|
|
Some(at)
|
|
|
|
} else {
|
|
|
|
None
|
|
|
|
})
|
2014-04-09 05:02:26 -05:00
|
|
|
.collect::<Vec<&ast::Attribute>>();
|
Add generation of static libraries to rustc
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes #552
2013-11-15 16:03:29 -06:00
|
|
|
for m in link_args.iter() {
|
|
|
|
match m.value_str() {
|
2014-03-09 08:20:44 -05:00
|
|
|
Some(linkarg) => e.sess.cstore.add_used_link_args(linkarg.get()),
|
Add generation of static libraries to rustc
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes #552
2013-11-15 16:03:29 -06:00
|
|
|
None => { /* fallthrough */ }
|
|
|
|
}
|
|
|
|
}
|
2012-09-04 18:40:11 -05:00
|
|
|
|
Add generation of static libraries to rustc
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes #552
2013-11-15 16:03:29 -06:00
|
|
|
// Next, process all of the #[link(..)]-style arguments
|
|
|
|
let link_args = i.attrs.iter()
|
2014-01-08 12:35:15 -06:00
|
|
|
.filter_map(|at| if at.name().equiv(&("link")) {
|
|
|
|
Some(at)
|
|
|
|
} else {
|
|
|
|
None
|
|
|
|
})
|
2014-04-09 05:02:26 -05:00
|
|
|
.collect::<Vec<&ast::Attribute>>();
|
Add generation of static libraries to rustc
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes #552
2013-11-15 16:03:29 -06:00
|
|
|
for m in link_args.iter() {
|
|
|
|
match m.meta_item_list() {
|
|
|
|
Some(items) => {
|
2013-11-28 20:03:38 -06:00
|
|
|
let kind = items.iter().find(|k| {
|
2014-01-08 12:35:15 -06:00
|
|
|
k.name().equiv(&("kind"))
|
2013-11-28 20:03:38 -06:00
|
|
|
}).and_then(|a| a.value_str());
|
Add generation of static libraries to rustc
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes #552
2013-11-15 16:03:29 -06:00
|
|
|
let kind = match kind {
|
|
|
|
Some(k) => {
|
2014-01-10 16:02:36 -06:00
|
|
|
if k.equiv(&("static")) {
|
2013-11-30 13:39:55 -06:00
|
|
|
cstore::NativeStatic
|
2014-01-10 16:02:36 -06:00
|
|
|
} else if k.equiv(&("framework")) {
|
2014-11-03 01:10:09 -06:00
|
|
|
cstore::NativeFramework
|
2013-11-30 13:39:55 -06:00
|
|
|
} else {
|
|
|
|
e.sess.span_err(m.span,
|
2014-05-16 12:45:16 -05:00
|
|
|
format!("unknown kind: `{}`",
|
|
|
|
k).as_slice());
|
2013-11-30 13:39:55 -06:00
|
|
|
cstore::NativeUnknown
|
|
|
|
}
|
Add generation of static libraries to rustc
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes #552
2013-11-15 16:03:29 -06:00
|
|
|
}
|
|
|
|
None => cstore::NativeUnknown
|
|
|
|
};
|
2013-11-28 20:03:38 -06:00
|
|
|
let n = items.iter().find(|n| {
|
2014-01-08 12:35:15 -06:00
|
|
|
n.name().equiv(&("name"))
|
2013-11-28 20:03:38 -06:00
|
|
|
}).and_then(|a| a.value_str());
|
Add generation of static libraries to rustc
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes #552
2013-11-15 16:03:29 -06:00
|
|
|
let n = match n {
|
|
|
|
Some(n) => n,
|
|
|
|
None => {
|
2013-11-30 13:39:55 -06:00
|
|
|
e.sess.span_err(m.span,
|
Add generation of static libraries to rustc
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes #552
2013-11-15 16:03:29 -06:00
|
|
|
"#[link(...)] specified without \
|
|
|
|
`name = \"foo\"`");
|
2014-01-10 16:02:36 -06:00
|
|
|
InternedString::new("foo")
|
Add generation of static libraries to rustc
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes #552
2013-11-15 16:03:29 -06:00
|
|
|
}
|
|
|
|
};
|
2014-10-21 01:04:16 -05:00
|
|
|
register_native_lib(e.sess, Some(m.span),
|
|
|
|
n.get().to_string(), kind);
|
Add generation of static libraries to rustc
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes #552
2013-11-15 16:03:29 -06:00
|
|
|
}
|
|
|
|
None => {}
|
2013-02-16 11:48:28 -06:00
|
|
|
}
|
2011-07-27 07:19:39 -05:00
|
|
|
}
|
2011-07-07 23:37:56 -05:00
|
|
|
}
|
Add generation of static libraries to rustc
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes #552
2013-11-15 16:03:29 -06:00
|
|
|
_ => { }
|
2011-07-07 23:37:56 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-10-21 01:04:16 -05:00
|
|
|
fn register_native_lib(sess: &Session, span: Option<Span>, name: String,
|
|
|
|
kind: cstore::NativeLibaryKind) {
|
|
|
|
if name.as_slice().is_empty() {
|
|
|
|
match span {
|
|
|
|
Some(span) => {
|
|
|
|
sess.span_err(span, "#[link(name = \"\")] given with \
|
|
|
|
empty name");
|
|
|
|
}
|
|
|
|
None => {
|
|
|
|
sess.err("empty library name given via `-l`");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return
|
|
|
|
}
|
|
|
|
let is_osx = sess.targ_cfg.os == abi::OsMacos ||
|
|
|
|
sess.targ_cfg.os == abi::OsiOS;
|
|
|
|
if kind == cstore::NativeFramework && !is_osx {
|
|
|
|
let msg = "native frameworks are only available on OSX targets";
|
|
|
|
match span {
|
|
|
|
Some(span) => sess.span_err(span, msg),
|
|
|
|
None => sess.err(msg),
|
|
|
|
}
|
|
|
|
}
|
|
|
|
sess.cstore.add_used_library(name, kind);
|
|
|
|
}
|
|
|
|
|
2014-06-06 15:21:18 -05:00
|
|
|
fn existing_match(e: &Env, name: &str,
|
2014-02-24 21:45:20 -06:00
|
|
|
hash: Option<&Svh>) -> Option<ast::CrateNum> {
|
2014-04-07 14:14:33 -05:00
|
|
|
let mut ret = None;
|
|
|
|
e.sess.cstore.iter_crate_data(|cnum, data| {
|
2014-09-12 00:50:40 -05:00
|
|
|
if data.name.as_slice() != name { return }
|
2014-07-01 10:37:54 -05:00
|
|
|
|
|
|
|
match hash {
|
|
|
|
Some(hash) if *hash == data.hash() => { ret = Some(cnum); return }
|
|
|
|
Some(..) => return,
|
|
|
|
None => {}
|
|
|
|
}
|
|
|
|
|
|
|
|
// 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-07-25 00:39:52 -05: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.
|
2014-07-01 10:37:54 -05:00
|
|
|
let source = e.sess.cstore.get_used_crate_source(cnum).unwrap();
|
2014-10-24 12:25:50 -05:00
|
|
|
match e.sess.opts.externs.find_equiv(name) {
|
2014-07-01 10:37:54 -05:00
|
|
|
Some(locs) => {
|
|
|
|
let found = locs.iter().any(|l| {
|
2014-08-14 16:42:37 -05:00
|
|
|
let l = fs::realpath(&Path::new(l.as_slice())).ok();
|
2014-07-25 00:39:52 -05:00
|
|
|
l == source.dylib || l == source.rlib
|
2014-07-01 10:37:54 -05:00
|
|
|
});
|
|
|
|
if found {
|
|
|
|
ret = Some(cnum);
|
|
|
|
}
|
2014-04-07 14:14:33 -05:00
|
|
|
}
|
2014-07-01 10:37:54 -05:00
|
|
|
None => ret = Some(cnum),
|
2012-06-04 10:03:14 -05:00
|
|
|
}
|
2014-04-07 14:14:33 -05:00
|
|
|
});
|
|
|
|
return ret;
|
2012-04-05 20:31:03 -05:00
|
|
|
}
|
|
|
|
|
2014-04-17 10:52:25 -05:00
|
|
|
fn register_crate<'a>(e: &mut Env,
|
|
|
|
root: &Option<CratePaths>,
|
|
|
|
ident: &str,
|
2014-06-06 15:21:18 -05:00
|
|
|
name: &str,
|
2014-04-17 10:52:25 -05:00
|
|
|
span: Span,
|
|
|
|
lib: loader::Library)
|
|
|
|
-> (ast::CrateNum, Rc<cstore::crate_metadata>,
|
|
|
|
cstore::CrateSource) {
|
|
|
|
// Claim this crate number and cache it
|
|
|
|
let cnum = e.next_crate_num;
|
|
|
|
e.next_crate_num += 1;
|
|
|
|
|
|
|
|
// Stash paths for top-most crate locally if necessary.
|
|
|
|
let crate_paths = if root.is_none() {
|
|
|
|
Some(CratePaths {
|
2014-05-25 05:17:19 -05:00
|
|
|
ident: ident.to_string(),
|
2014-04-17 10:52:25 -05:00
|
|
|
dylib: lib.dylib.clone(),
|
|
|
|
rlib: lib.rlib.clone(),
|
|
|
|
})
|
|
|
|
} else {
|
|
|
|
None
|
|
|
|
};
|
|
|
|
// Maintain a reference to the top most crate.
|
|
|
|
let root = if root.is_some() { root } else { &crate_paths };
|
|
|
|
|
|
|
|
let cnum_map = resolve_crate_deps(e, root, lib.metadata.as_slice(), span);
|
|
|
|
|
|
|
|
let loader::Library{ dylib, rlib, metadata } = lib;
|
|
|
|
|
|
|
|
let cmeta = Rc::new( cstore::crate_metadata {
|
2014-06-06 15:21:18 -05:00
|
|
|
name: name.to_string(),
|
2014-04-17 10:52:25 -05:00
|
|
|
data: metadata,
|
|
|
|
cnum_map: cnum_map,
|
|
|
|
cnum: cnum,
|
|
|
|
span: span,
|
|
|
|
});
|
|
|
|
|
|
|
|
let source = cstore::CrateSource {
|
|
|
|
dylib: dylib,
|
|
|
|
rlib: rlib,
|
|
|
|
cnum: cnum,
|
|
|
|
};
|
|
|
|
|
|
|
|
e.sess.cstore.set_crate_data(cnum, cmeta.clone());
|
|
|
|
e.sess.cstore.add_used_crate_source(source.clone());
|
|
|
|
(cnum, cmeta, source)
|
|
|
|
}
|
|
|
|
|
2014-04-03 10:43:57 -05:00
|
|
|
fn resolve_crate<'a>(e: &mut Env,
|
2014-04-17 10:52:25 -05:00
|
|
|
root: &Option<CratePaths>,
|
|
|
|
ident: &str,
|
2014-06-06 15:21:18 -05:00
|
|
|
name: &str,
|
2014-04-17 10:52:25 -05:00
|
|
|
hash: Option<&Svh>,
|
|
|
|
span: Span)
|
2014-04-17 07:06:25 -05:00
|
|
|
-> (ast::CrateNum, Rc<cstore::crate_metadata>,
|
2014-04-07 14:16:43 -05:00
|
|
|
cstore::CrateSource) {
|
2014-06-06 15:21:18 -05:00
|
|
|
match existing_match(e, name, hash) {
|
2014-02-24 20:13:51 -06:00
|
|
|
None => {
|
2014-02-24 21:45:20 -06:00
|
|
|
let mut load_ctxt = loader::Context {
|
2014-02-24 20:13:51 -06:00
|
|
|
sess: e.sess,
|
2013-12-22 16:55:41 -06:00
|
|
|
span: span,
|
2014-02-24 20:13:51 -06:00
|
|
|
ident: ident,
|
2014-06-06 15:21:18 -05:00
|
|
|
crate_name: name,
|
2014-02-24 21:45:20 -06:00
|
|
|
hash: hash.map(|a| &*a),
|
2014-04-17 10:52:25 -05:00
|
|
|
filesearch: e.sess.target_filesearch(),
|
2014-06-11 02:48:17 -05:00
|
|
|
os: e.sess.targ_cfg.os,
|
2014-04-17 10:52:25 -05:00
|
|
|
triple: e.sess.targ_cfg.target_strs.target_triple.as_slice(),
|
|
|
|
root: root,
|
2014-04-04 20:49:03 -05:00
|
|
|
rejected_via_hash: vec!(),
|
2014-04-17 10:52:25 -05:00
|
|
|
rejected_via_triple: vec!(),
|
2014-07-01 10:37:54 -05:00
|
|
|
should_match_name: true,
|
2014-02-24 20:13:51 -06:00
|
|
|
};
|
2014-04-17 10:52:25 -05:00
|
|
|
let library = load_ctxt.load_library_crate();
|
2014-06-06 15:21:18 -05:00
|
|
|
register_crate(e, root, ident, name, span, library)
|
2014-02-24 20:13:51 -06:00
|
|
|
}
|
2014-04-07 14:16:43 -05:00
|
|
|
Some(cnum) => (cnum,
|
|
|
|
e.sess.cstore.get_crate_data(cnum),
|
|
|
|
e.sess.cstore.get_used_crate_source(cnum).unwrap())
|
2012-04-05 20:31:03 -05:00
|
|
|
}
|
2011-07-08 14:55:38 -05:00
|
|
|
}
|
2011-05-26 19:16:54 -05:00
|
|
|
|
2011-07-08 14:55:38 -05:00
|
|
|
// Go through the crate metadata and load any crates that it references
|
2014-02-09 21:29:21 -06:00
|
|
|
fn resolve_crate_deps(e: &mut Env,
|
2014-04-03 10:43:57 -05:00
|
|
|
root: &Option<CratePaths>,
|
2014-02-09 21:29:21 -06:00
|
|
|
cdata: &[u8], span : Span)
|
|
|
|
-> cstore::cnum_map {
|
2013-10-21 15:08:31 -05:00
|
|
|
debug!("resolving deps of external crate");
|
2011-07-08 14:55:38 -05:00
|
|
|
// The map from crate numbers in the crate we're resolving to local crate
|
|
|
|
// numbers
|
2014-04-22 11:06:43 -05:00
|
|
|
decoder::get_crate_deps(cdata).iter().map(|dep| {
|
2014-06-06 15:21:18 -05:00
|
|
|
debug!("resolving dep crate {} hash: `{}`", dep.name, dep.hash);
|
2014-04-07 14:16:43 -05:00
|
|
|
let (local_cnum, _, _) = resolve_crate(e, root,
|
2014-06-06 15:21:18 -05:00
|
|
|
dep.name.as_slice(),
|
|
|
|
dep.name.as_slice(),
|
2014-04-07 14:16:43 -05:00
|
|
|
Some(&dep.hash),
|
|
|
|
span);
|
2014-04-22 11:06:43 -05:00
|
|
|
(dep.cnum, local_cnum)
|
|
|
|
}).collect()
|
2011-07-08 14:55:38 -05:00
|
|
|
}
|
2013-12-25 12:10:33 -06:00
|
|
|
|
2014-05-24 18:16:10 -05:00
|
|
|
pub struct PluginMetadataReader<'a> {
|
2014-03-28 12:05:27 -05:00
|
|
|
env: Env<'a>,
|
2013-12-25 12:10:33 -06:00
|
|
|
}
|
|
|
|
|
2014-05-24 18:16:10 -05:00
|
|
|
impl<'a> PluginMetadataReader<'a> {
|
|
|
|
pub fn new(sess: &'a Session) -> PluginMetadataReader<'a> {
|
|
|
|
PluginMetadataReader {
|
2013-12-25 12:10:33 -06:00
|
|
|
env: Env {
|
|
|
|
sess: sess,
|
2014-04-07 14:14:33 -05:00
|
|
|
next_crate_num: sess.cstore.next_crate_num(),
|
2013-12-25 12:10:33 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-05-24 18:16:10 -05:00
|
|
|
pub fn read_plugin_metadata(&mut self, krate: &ast::ViewItem) -> PluginMetadata {
|
2014-02-24 20:13:51 -06:00
|
|
|
let info = extract_crate_info(&self.env, krate).unwrap();
|
2014-04-17 10:52:25 -05:00
|
|
|
let target_triple = self.env.sess.targ_cfg.target_strs.target_triple.as_slice();
|
|
|
|
let is_cross = target_triple != driver::host_triple();
|
|
|
|
let mut should_link = info.should_link && !is_cross;
|
2014-05-06 06:38:01 -05:00
|
|
|
let os = config::get_os(driver::host_triple()).unwrap();
|
2014-04-17 10:52:25 -05:00
|
|
|
let mut load_ctxt = loader::Context {
|
|
|
|
sess: self.env.sess,
|
|
|
|
span: krate.span,
|
2014-05-09 20:45:36 -05:00
|
|
|
ident: info.ident.as_slice(),
|
2014-06-06 15:21:18 -05:00
|
|
|
crate_name: info.name.as_slice(),
|
2014-04-17 10:52:25 -05:00
|
|
|
hash: None,
|
|
|
|
filesearch: self.env.sess.host_filesearch(),
|
|
|
|
triple: driver::host_triple(),
|
2014-06-11 02:48:17 -05:00
|
|
|
os: os,
|
2014-04-17 10:52:25 -05:00
|
|
|
root: &None,
|
|
|
|
rejected_via_hash: vec!(),
|
|
|
|
rejected_via_triple: vec!(),
|
2014-07-01 10:37:54 -05:00
|
|
|
should_match_name: true,
|
2014-04-17 10:52:25 -05:00
|
|
|
};
|
|
|
|
let library = match load_ctxt.maybe_load_library_crate() {
|
2014-07-09 21:13:28 -05:00
|
|
|
Some(l) => l,
|
2014-04-17 10:52:25 -05:00
|
|
|
None if is_cross => {
|
|
|
|
// try loading from target crates (only valid if there are
|
|
|
|
// no syntax extensions)
|
|
|
|
load_ctxt.triple = target_triple;
|
2014-06-11 02:48:17 -05:00
|
|
|
load_ctxt.os = self.env.sess.targ_cfg.os;
|
2014-04-17 10:52:25 -05:00
|
|
|
load_ctxt.filesearch = self.env.sess.target_filesearch();
|
|
|
|
let lib = load_ctxt.load_library_crate();
|
2014-05-24 18:16:10 -05:00
|
|
|
if decoder::get_plugin_registrar_fn(lib.metadata.as_slice()).is_some() {
|
|
|
|
let message = format!("crate `{}` contains a plugin_registrar fn but \
|
2014-04-17 10:52:25 -05:00
|
|
|
only a version for triple `{}` could be found (need {})",
|
|
|
|
info.ident, target_triple, driver::host_triple());
|
2014-05-16 12:45:16 -05:00
|
|
|
self.env.sess.span_err(krate.span, message.as_slice());
|
2014-04-17 10:52:25 -05:00
|
|
|
// need to abort now because the syntax expansion
|
|
|
|
// code will shortly attempt to load and execute
|
|
|
|
// code from the found library.
|
|
|
|
self.env.sess.abort_if_errors();
|
|
|
|
}
|
|
|
|
should_link = info.should_link;
|
|
|
|
lib
|
|
|
|
}
|
|
|
|
None => { load_ctxt.report_load_errs(); unreachable!() },
|
|
|
|
};
|
|
|
|
let macros = decoder::get_exported_macros(library.metadata.as_slice());
|
2014-05-24 18:16:10 -05:00
|
|
|
let registrar = decoder::get_plugin_registrar_fn(library.metadata.as_slice()).map(|id| {
|
2014-06-26 01:15:14 -05:00
|
|
|
decoder::get_symbol(library.metadata.as_slice(), id)
|
2014-04-13 13:26:43 -05:00
|
|
|
});
|
2014-07-09 21:13:28 -05:00
|
|
|
if library.dylib.is_none() && registrar.is_some() {
|
|
|
|
let message = format!("plugin crate `{}` only found in rlib format, \
|
|
|
|
but must be available in dylib format",
|
|
|
|
info.ident);
|
|
|
|
self.env.sess.span_err(krate.span, message.as_slice());
|
|
|
|
// No need to abort because the loading code will just ignore this
|
|
|
|
// empty dylib.
|
|
|
|
}
|
2014-05-24 18:16:10 -05:00
|
|
|
let pc = PluginMetadata {
|
2014-04-17 10:52:25 -05:00
|
|
|
lib: library.dylib.clone(),
|
2014-06-26 01:15:14 -05:00
|
|
|
macros: macros,
|
2014-04-07 14:16:43 -05:00
|
|
|
registrar_symbol: registrar,
|
2014-04-17 10:52:25 -05:00
|
|
|
};
|
2014-06-06 15:21:18 -05:00
|
|
|
if should_link && existing_match(&self.env, info.name.as_slice(),
|
|
|
|
None).is_none() {
|
2014-04-17 10:52:25 -05:00
|
|
|
// register crate now to avoid double-reading metadata
|
|
|
|
register_crate(&mut self.env, &None, info.ident.as_slice(),
|
2014-06-06 15:21:18 -05:00
|
|
|
info.name.as_slice(), krate.span, library);
|
2013-12-25 12:10:33 -06:00
|
|
|
}
|
2014-05-24 18:16:10 -05:00
|
|
|
pc
|
2013-12-25 12:10:33 -06:00
|
|
|
}
|
|
|
|
}
|