This allows to create proper debuginfo line information for items inlined from other crates (e.g. instantiations of generics).
Only the codemap's 'metadata' is stored in a crate's metadata. That is, just filename, line-beginnings, etc. but not the actual source code itself. We are thus missing the opportunity of making Rust the first "open-source-only" programming language out there. Pity.
#[plugin] #[no_link] extern crate bleh;
becomes a crate attribute
#![plugin(bleh)]
The feature gate is still required.
It's almost never correct to link a plugin into the resulting library /
executable, because it will bring all of libsyntax and librustc with it.
However if you really want this behavior, you can get it with a separate
`extern crate` item in addition to the `plugin` attribute.
Fixes#21043.
Fixes#20769.
[breaking-change]
Add special error for this case and help message `please recompile this crate using --crate-type lib`, also list found candidates.
See issue #14416
r? @alexcrichton
Previously if --extern was specified it would not override crates in the
standard distribution, leading to issues like #21771. This commit alters the
behavior such that if --extern is passed then it will always override any other
choice of crates and no previous match will be used (unless it is the same path
as --extern).
Closes#21771
With the addition of separate search paths to the compiler, it was intended that
applications such as Cargo could require a `--extern` flag per `extern crate`
directive in the source. The system can currently be subverted, however, due to
the `existing_match()` logic in the crate loader.
When loading crates we first attempt to match an `extern crate` directive
against all previously loaded crates to avoid reading metadata twice. This "hit
the cache if possible" step was erroneously leaking crates across the search
path boundaries, however. For example:
extern crate b;
extern crate a;
If `b` depends on `a`, then it will load crate `a` when the `extern crate b`
directive is being processed. When the compiler reaches `extern crate a` it will
use the previously loaded version no matter what. If the compiler was not
invoked with `-L crate=path/to/a`, it will still succeed.
This behavior is allowing `extern crate` declarations in Cargo without a
corresponding declaration in the manifest of a dependency, which is considered
a bug.
This commit fixes this problem by keeping track of the origin search path for a
crate. Crates loaded from the dependency search path are not candidates for
crates which are loaded from the crate search path.
As a result of this fix, this is a likely a breaking change for a number of
Cargo packages. If the compiler starts informing that a crate can no longer be
found, it likely means that the dependency was forgotten in your Cargo.toml.
[breaking-change]
This warning has been around in the compiler for quite some time now, but the
real place for a warning like this, if it should exist, is in Cargo, not in the
compiler itself. It's a first-class feature of Cargo that multiple versions of a
crate can be compiled into the same executable, and we shouldn't be warning
about our first-class features.
Instead of copy-pasting the whole macro_rules! item from the original .rs file,
we serialize a separate name, attributes list, and body, the latter as
pretty-printed TTs. The compilation of macro_rules! macros is decoupled
somewhat from the expansion of macros in item position.
This filters out comments, and facilitates selective imports.
This commit adds support for the compiler to distinguish between different forms
of lookup paths in the compiler itself. Issue #19767 has some background on this
topic, as well as some sample bugs which can occur if these lookup paths are not
separated.
This commits extends the existing command line flag `-L` with the same trailing
syntax as the `-l` flag. Each argument to `-L` can now have a trailing `:all`,
`:native`, `:crate`, or `:dependency`. This suffix indicates what form of lookup
path the compiler should add the argument to. The `dependency` lookup path is
used when looking up crate dependencies, the `crate` lookup path is used when
looking for immediate dependencies (`extern crate` statements), and the `native`
lookup path is used for probing for native libraries to insert into rlibs. Paths
with `all` are used for all of these purposes (the default).
The default compiler lookup path (the rustlib libdir) is by default added to all
of these paths. Additionally, the `RUST_PATH` lookup path is added to all of
these paths.
Closes#19767
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]
Hello,
`dylib` [seems][1] to be no longer an option for the `kind` key of the `link` attribute.
UPDATE: It should be the other way around: It [seems][1] `dylib` has been lost as a possible variant of the `kind` key of the `link` attribute. See the comment below.
Regards,
Ivan
[1]: 8f87538786/src/librustc/metadata/creader.rs (L237)
Removes all target-specific knowledge from rustc. Some targets have changed
during this, but none of these should be very visible outside of
cross-compilation. The changes make our targets more consistent.
iX86-unknown-linux-gnu is now only available as i686-unknown-linux-gnu. We
used to accept any value of X greater than 1. i686 was released in 1995, and
should encompass the bare minimum of what Rust supports on x86 CPUs.
The only two windows targets are now i686-pc-windows-gnu and
x86_64-pc-windows-gnu.
The iOS target has been renamed from arm-apple-ios to arm-apple-darwin.
A complete list of the targets we accept now:
arm-apple-darwin
arm-linux-androideabi
arm-unknown-linux-gnueabi
arm-unknown-linux-gnueabihf
i686-apple-darwin
i686-pc-windows-gnu
i686-unknown-freebsd
i686-unknown-linux-gnu
mips-unknown-linux-gnu
mipsel-unknown-linux-gnu
x86_64-apple-darwin
x86_64-unknown-freebsd
x86_64-unknown-linux-gnu
x86_64-pc-windows-gnu
Closes#16093
[breaking-change]
