Rename and gensym the runtime on import, so that users
can't refer to the `native` crate.
This is unlikely to break code, but users should import the "native" crate directly.
[breaking-change]
cc @alexcrichton
method calls are involved.
This breaks code like:
impl<T:Copy> Foo for T { ... }
fn take_param<T:Foo>(foo: &T) { ... }
fn main() {
let x = box 3i; // note no `Copy` bound
take_param(&x);
}
Change this code to not contain a type error. For example:
impl<T:Copy> Foo for T { ... }
fn take_param<T:Foo>(foo: &T) { ... }
fn main() {
let x = 3i; // satisfies `Copy` bound
take_param(&x);
}
Closes#15860.
[breaking-change]
r? @alexcrichton
method calls are involved.
This breaks code like:
impl<T:Copy> Foo for T { ... }
fn take_param<T:Foo>(foo: &T) { ... }
fn main() {
let x = box 3i; // note no `Copy` bound
take_param(&x);
}
Change this code to not contain a type error. For example:
impl<T:Copy> Foo for T { ... }
fn take_param<T:Foo>(foo: &T) { ... }
fn main() {
let x = 3i; // satisfies `Copy` bound
take_param(&x);
}
Closes#15860.
[breaking-change]
librustc: Stop desugaring `for` expressions and translate them directly.
This makes edge cases in which the `Iterator` trait was not in scope
and/or `Option` or its variants were not in scope work properly.
This breaks code that looks like:
struct MyStruct { ... }
impl MyStruct {
fn next(&mut self) -> Option<int> { ... }
}
for x in MyStruct { ... } { ... }
Change ad-hoc `next` methods like the above to implementations of the
`Iterator` trait. For example:
impl Iterator<int> for MyStruct {
fn next(&mut self) -> Option<int> { ... }
}
Closes#15392.
[breaking-change]
This makes edge cases in which the `Iterator` trait was not in scope
and/or `Option` or its variants were not in scope work properly.
This breaks code that looks like:
struct MyStruct { ... }
impl MyStruct {
fn next(&mut self) -> Option<int> { ... }
}
for x in MyStruct { ... } { ... }
Change ad-hoc `next` methods like the above to implementations of the
`Iterator` trait. For example:
impl Iterator<int> for MyStruct {
fn next(&mut self) -> Option<int> { ... }
}
Closes#15392.
[breaking-change]
This is done entirely in the libraries for functions up to 16 arguments.
A macro is used so that more arguments can be easily added if we need.
Note that I had to adjust the overloaded call algorithm to not try
calling the overloaded call operator if the callee is a built-in
function type, to prevent loops.
Closes#15448.
This implements RFC 39. Omitted lifetimes in return values will now be
inferred to more useful defaults, and an error is reported if a lifetime
in a return type is omitted and one of the two lifetime elision rules
does not specify what it should be.
This primarily breaks two uncommon code patterns. The first is this:
unsafe fn get_foo_out_of_thin_air() -> &Foo {
...
}
This should be changed to:
unsafe fn get_foo_out_of_thin_air() -> &'static Foo {
...
}
The second pattern that needs to be changed is this:
enum MaybeBorrowed<'a> {
Borrowed(&'a str),
Owned(String),
}
fn foo() -> MaybeBorrowed {
Owned(format!("hello world"))
}
Change code like this to:
enum MaybeBorrowed<'a> {
Borrowed(&'a str),
Owned(String),
}
fn foo() -> MaybeBorrowed<'static> {
Owned(format!("hello world"))
}
Closes#15552.
[breaking-change]
r? @nick29581
This is accomplished by rewriting static expressions into equivalent patterns.
This way, patterns referencing static variables can both participate
in exhaustiveness analysis as well as be compiled down into the appropriate
branch of the decision trees that match expressions are codegened to.
Fixes#6533.
Fixes#13626.
Fixes#13731.
Fixes#14576.
Fixes#15393.
This implements RFC 39. Omitted lifetimes in return values will now be
inferred to more useful defaults, and an error is reported if a lifetime
in a return type is omitted and one of the two lifetime elision rules
does not specify what it should be.
This primarily breaks two uncommon code patterns. The first is this:
unsafe fn get_foo_out_of_thin_air() -> &Foo {
...
}
This should be changed to:
unsafe fn get_foo_out_of_thin_air() -> &'static Foo {
...
}
The second pattern that needs to be changed is this:
enum MaybeBorrowed<'a> {
Borrowed(&'a str),
Owned(String),
}
fn foo() -> MaybeBorrowed {
Owned(format!("hello world"))
}
Change code like this to:
enum MaybeBorrowed<'a> {
Borrowed(&'a str),
Owned(String),
}
fn foo() -> MaybeBorrowed<'static> {
Owned(format!("hello world"))
}
Closes#15552.
[breaking-change]
The first is to require that `#[crate_name]` and `--crate-name` always match (if both are specified). The second is to fix parallel compilation in cargo by mixing in `-C extra-filename` into the temporary outputs of the compiler.
When invoking the compiler in parallel, the intermediate output of the object
files and bytecode can stomp over one another if two crates with the same name
are being compiled.
The output file is already being disambiguated with `-C extra-filename`, so this
commit alters the naming of the temporary files to also mix in the extra
filename to ensure that file names don't clash.
This is accomplished by rewriting static expressions into equivalent patterns.
This way, patterns referencing static variables can both participate
in exhaustiveness analysis as well as be compiled down into the appropriate
branch of the decision trees that match expressions are codegened to.
Fixes#6533.
Fixes#13626.
Fixes#13731.
Fixes#14576.
Fixes#15393.
Part of the original discussions around the `--crate-name` flag brought up that
mass confusion can arise when the flag specifies a different name than is
contained in the crate.
The current primary use case of the `--crate-name` flag is through cargo and
not requiring a `#[crate_name]` attribute, but if the `#[crate_name]` attribute
is specified it will likely go awry when the two names deviate from one another.
This commit requires that if both are provided they both match to prevent this
confusion.
Importing from types was disallowed in #6462. Flag was set for paths whether it is a module or a type. Type flag was set when impl was seen. The problem is, for cross-crate situations, when reexport is involved, it is possible that impl is seen too late because metadata is loaded lazily.
Fix#15664.
