| Age | Commit message (Collapse) | Author | Lines |
|---|
|
memory usage significantly and opens opportunities for more parallel compilation.
|
|
This is especially useful for declaring a static with external linkage in an executable. There isn't any way to do that currently since we mark everything in an executable as internal by default.
Also, a quick fix to have the no-compiler-rt target option respected when building staticlibs as well.
|
|
This breaks code that referred to variant names in the same namespace as
their enum. Reexport the variants in the old location or alter code to
refer to the new locations:
```
pub enum Foo {
A,
B
}
fn main() {
let a = A;
}
```
=>
```
pub use self::Foo::{A, B};
pub enum Foo {
A,
B
}
fn main() {
let a = A;
}
```
or
```
pub enum Foo {
A,
B
}
fn main() {
let a = Foo::A;
}
```
[breaking-change]
|
|
|
|
Num, NumCast, Unsigned, Float, Primitive and Int have been removed.
|
|
|
|
Based on Windows bundle feedback we got to date,
- We *do* want to prefer the bundled linker: The external one might be for the wrong architecture (e.g. 32 bit vs 64 bit). On the other hand, binutils don't add many new features these days, so using an older bundled linker is not likely to be a problem.
- We *do* want to prefer bundled libraries: The external ones might not have the symbols we expect (e.g. what's needed for DWARF exceptions vs SjLj). Since `-L rustlib/<triple>/lib` appears first on the linker command line, it's a good place to keep our platform libs that we want to be found first.
Closes #18325, closes #17726.
|
|
cannot be found. The latter is the case for our bundles, because we don't include collect2. Unfortunately, ld does not understand this option and errors out.
On the bright side, -fno-use-linker-plugin still works to suppress gcc's LTO, so we can drop -fno-lto.
|
|
Fixes #18574
|
|
|
|
|
|
|
|
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]
|
|
|
|
This changes create_target_machine to correctly return a Result (Since
the underlying LLVM function can fail and return NULL)
|
|
https://github.com/rust-lang/rfcs/pull/221
The current terminology of "task failure" often causes problems when
writing or speaking about code. You often want to talk about the
possibility of an operation that returns a Result "failing", but cannot
because of the ambiguity with task failure. Instead, you have to speak
of "the failing case" or "when the operation does not succeed" or other
circumlocutions.
Likewise, we use a "Failure" header in rustdoc to describe when
operations may fail the task, but it would often be helpful to separate
out a section describing the "Err-producing" case.
We have been steadily moving away from task failure and toward Result as
an error-handling mechanism, so we should optimize our terminology
accordingly: Result-producing functions should be easy to describe.
To update your code, rename any call to `fail!` to `panic!` instead.
Assuming you have not created your own macro named `panic!`, this
will work on UNIX based systems:
grep -lZR 'fail!' . | xargs -0 -l sed -i -e 's/fail!/panic!/g'
You can of course also do this by hand.
[breaking-change]
|
|
|
|
Spring cleaning is here! In the Fall! This commit removes quite a large amount
of deprecated functionality from the standard libraries. I tried to ensure that
only old deprecated functionality was removed.
This is removing lots and lots of deprecated features, so this is a breaking
change. Please consult the deprecation messages of the deleted code to see how
to migrate code forward if it still needs migration.
[breaking-change]
|
|
Position independent code has fewer requirements in executables, so pass
the appropriate flag to LLVM in order to allow more optimization. At the
moment this means faster thread-local storage.
|
|
Also convert a number of `static mut` to just a plain old `static` and remove
some unsafe blocks.
|
|
|
|
|
|
Closes #17773.
|
|
For example, this renames `GroupRWX` to `GROUP_RWX`, and deprecates the old
name. Code using these statics should be updated accordingly.
|
|
|
|
This reverts commit 40b9f5ded50ac4ce8c9323921ec556ad611af6b7.
|
|
|
|
This breaks code that looks like:
match foo {
1..3 => { ... }
}
Instead, write:
match foo {
1...3 => { ... }
}
Closes #17295.
[breaking-change]
|
|
|
|
The reason that 'ar' can fail with permission denied is that when
link-time optimizations are enabled, rustc copies libraries into a
temporary directory, preserving file permissions, and subsequently
modifies them using 'ar'.
The modification can fail because some package managers may install
libraries in system directories as read-only files, which means the
temporary file also becomes read-only when it is copied.
I have fixed this by giving the temporary file's owner read+write
permissions after the copy.
I have also added a regression test for this issue.
|
|
|
|
Fixes #17552.
|
|
|
|
Allow linking it statically on Win32 with an override.
|
|
|
|
|
|
Change to resolve and update compiler and libs for uses.
[breaking-change]
Enum variants are now in both the value and type namespaces. This means that
if you have a variant with the same name as a type in scope in a module, you
will get a name clash and thus an error. The solution is to either rename the
type or the variant.
|
|
Closes #16514
|
|
|
|
|
|
I would like to map this information back to AST nodes, so that we can print remarks with spans, and so that remarks can be enabled on a per-function basis. Unfortunately, doing this would require a lot more code restructuring — for example, we currently throw away the AST map and lots of other information before LLVM optimizations run. So for the time being, we print the remarks with debug location strings from LLVM. There's a warning if you use `-C remark` without `--debuginfo`.
Fixes #17116.
|
|
Only pass -fno-use-linker-plugin on Windows where it avoids pulling in
dependencies. Passing it to clang on OS X and Linux would make it fail
though.
|
|
type they provide an implementation for.
This breaks code like:
mod foo {
struct Foo { ... }
}
impl foo::Foo {
...
}
Change this code to:
mod foo {
struct Foo { ... }
impl Foo {
...
}
}
Closes #17059.
RFC #155.
[breaking-change]
r? @brson
|
|
This PR fixes debuginfo tests on Windows.
|
|
type they provide an implementation for.
This breaks code like:
mod foo {
struct Foo { ... }
}
impl foo::Foo {
...
}
Change this code to:
mod foo {
struct Foo { ... }
impl Foo {
...
}
}
Additionally, if you used the I/O path extension methods `stat`,
`lstat`, `exists`, `is_file`, or `is_dir`, note that these methods have
been moved to the the `std::io::fs::PathExtensions` trait. This breaks
code like:
fn is_it_there() -> bool {
Path::new("/foo/bar/baz").exists()
}
Change this code to:
use std::io::fs::PathExtensions;
fn is_it_there() -> bool {
Path::new("/foo/bar/baz").exists()
}
Closes #17059.
RFC #155.
[breaking-change]
|
|
Fixes #17116.
|
|
|
|
|
|
By default, 32-bit Windows executables are restricted to 2GiB of address
space even when running on 64-bit Windows when 4GiB is available.
Closes #17043
|
|
This makes the extra library paths given to the gcc linker come in
the same order as the -L options on the rustc command line.
|
