Add -Zmutable-noalias flag
We disabled noalias on mutable references a long time ago when it was clear that llvm was incorrectly handling this in relation to unwinding edges.
Since then, a few things have happened:
* llvm has cleaned up a bunch of the issues (I'm told)
* we've added a nounwind codegen option
As such, I would like to add this -Z flag so that we can evaluate if the codegen bugs still exist, and if this significantly affects the codegen of different projects, with an eye towards permanently re-enabling it (or at least making it a stable option).
Add builder for Solaris and merge it with Fuchsia's builder
The new Solaris builder can be used to build rust-std.
The dilos illumos distribution was chosen, because illumos is free software
as opposed to Oracle Solaris and dilos is the only illumos distribution that
supports x86_64 and sparcv9 at the same level.
enable strict alignment (+strict-align) on ARMv6
As discovered in #44538 ARMv6 devices may or may not support unaligned memory accesses. ARMv6
Linux *seems* to have no problem with unaligned accesses but this is because the kernel is stepping
in to fix each unaligned memory access -- this incurs in a performance penalty.
This commit enforces aligned memory accesses on all our in-tree ARM targets that may be used with
ARMv6 devices. This should improve performance of Rust programs on ARMv6 devices. For the record,
clang also applies this attribute when targeting ARMv6 devices that are not running Darwin or
NetBSD.
closes#44538
r? @alexcrichton
Document that `-C ar=PATH` doesn't do anything
Are there any plans to use an external archiver in the future?
IIRC, it was used before, but its use was replaced with LLVM's built-in archive management machinery. I can't found a relevant PR though. EDIT: Found it - https://github.com/rust-lang/rust/pull/26926!
The `-C` option is stable so it still can't be removed right away even if there are no plans to use it (but maybe it can be deprecated?).
Target specifications have a field for archiver as well, which is unused too (these ones are unstable, so I guess it can be removed).
r? @alexcrichton
Add read_to_end implementation to &[u8]'s Read impl
The default impl for read_to_end does a bunch of bookkeeping
that isn't necessary for slices and is about 4 times slower
on my machine.
The following benchmark takes about 30 ns before this change and about 7 ns after:
```
#[bench]
fn bench_read_std(b: &mut Bencher) {
let data = vec![0u8; 100];
let mut v = Vec::with_capacity(200);
b.iter(|| {
let mut s = data.as_slice();
v.clear();
s.read_to_end(&mut v).unwrap();
});
}
```
This solves the easy part of https://github.com/rust-lang/rust/issues/44819 (I think extending this to `Take<&[u8]> `would require specialization)
Fix typo, per #45057.
This looks like a simple string -- one character -- fix. Given that I'm currently running low on battery, I have not actually compiled and tested this. But I am fully confident this passes muster. If not, I'll be maintainer-educated, yes? ;-)
Modify Rc/Arc language around mutability
There are a few exceptions to the rule that Arc/Rc are immutable. Rather
than dig into the details, add "generally" to hint at this difference,
as it's kind of a distraction at this point in the docs.
Additionally, Arc's docs were slightly different here generally, so add
in both the existing language and the exception.
Fixes#44105
groundwork for rustc_clean/dirty improvements
This is a WIP PR that needs mentoring from @michaelwoerister.
There are several TODOs but no outstanding questions (except for the main one -- **is this the right approach?**)
This is the plumbing for supporing groups in `rustc_clean(labels="...")`, as well as supporting an `except="..."` which will remove the excepted labels in the "clean" check and then assert that they are dirty (this is still TODO).
See the code TODO's and example comments for a rough design.
I'd like to know if this is the design you would like to do, and then I can go about actually filling out the groups and implementing the remaining logic.
Allow atomic operations up to 32 bits
The ARMv5te platform does not have instruction-level support for atomics, however the kernel provides [user space helpers] which can be used to perform atomic operations. When linked with `libgcc`, the atomic symbols needed by Rust will be provided, rather than CPU level intrinsics.
[user space helpers]: https://www.kernel.org/doc/Documentation/arm/kernel_user_helpers.txt
32-bit versions of these kernel level helpers were introduced in Linux Kernel 2.6.12, and 64-bit version of these kernel level helpers were introduced in Linux Kernel 3.1. I have selected 32 bit versions as std currently only requires Linux version 2.6.18 and above as far as I am aware.
As this target is specifically linux and gnueabi, it is reasonable to assume the Linux Kernel and libc will be available for the target. There is a large performance penalty, as we are not using CPU level intrinsics, however this penalty is likely preferable to not having the target at all.
I have used this change in a custom target (along with xargo) to build std, as well as a number of higher level crates.
## Additional information
For reference, here is what a a code snippet decompiles to:
```rust
use std::sync::atomic::{AtomicIsize, Ordering};
#[no_mangle]
pub extern fn foo(a: &AtomicIsize) -> isize {
a.fetch_add(1, Ordering::SeqCst)
}
```
```
Disassembly of section .text.foo:
00000000 <foo>:
0: e92d4800 push {fp, lr}
4: e3a01001 mov r1, #1
8: ebfffffe bl 0 <__sync_fetch_and_add_4>
c: e8bd8800 pop {fp, pc}
```
Which in turn is provided by `libgcc.a`, which has code which looks like this:
```
Disassembly of section .text:
00000000 <__sync_fetch_and_add_4>:
0: e92d40f8 push {r3, r4, r5, r6, r7, lr}
4: e1a05000 mov r5, r0
8: e1a07001 mov r7, r1
c: e59f6028 ldr r6, [pc, #40] ; 3c <__sync_fetch_and_add_4+0x3c>
10: e5954000 ldr r4, [r5]
14: e1a02005 mov r2, r5
18: e1a00004 mov r0, r4
1c: e0841007 add r1, r4, r7
20: e1a0e00f mov lr, pc
24: e12fff16 bx r6
28: e3500000 cmp r0, #0
2c: 1afffff7 bne 10 <__sync_fetch_and_add_4+0x10>
30: e1a00004 mov r0, r4
34: e8bd40f8 pop {r3, r4, r5, r6, r7, lr}
38: e12fff1e bx lr
3c: ffff0fc0 .word 0xffff0fc0
```
Where you can see the reference to `0xffff0fc0`, which is provided by the [user space helpers].
rustc: Implement ThinLTO
This commit is an implementation of LLVM's ThinLTO for consumption in rustc
itself. Currently today LTO works by merging all relevant LLVM modules into one
and then running optimization passes. "Thin" LTO operates differently by having
more sharded work and allowing parallelism opportunities between optimizing
codegen units. Further down the road Thin LTO also allows *incremental* LTO
which should enable even faster release builds without compromising on the
performance we have today.
This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then
also implements two forms of ThinLTO:
* In one mode we'll *only* perform ThinLTO over the codegen units produced in a
single compilation. That is, we won't load upstream rlibs, but we'll instead
just perform ThinLTO amongst all codegen units produced by the compiler for
the local crate. This is intended to emulate a desired end point where we have
codegen units turned on by default for all crates and ThinLTO allows us to do
this without performance loss.
* In anther mode, like full LTO today, we'll optimize all upstream dependencies
in "thin" mode. Unlike today, however, this LTO step is fully parallelized so
should finish much more quickly.
There's a good bit of comments about what the implementation is doing and where
it came from, but the tl;dr; is that currently most of the support here is
copied from upstream LLVM. This code duplication is done for a number of
reasons:
* Controlling parallelism means we can use the existing jobserver support to
avoid overloading machines.
* We will likely want a slightly different form of incremental caching which
integrates with our own incremental strategy, but this is yet to be
determined.
* This buys us some flexibility about when/where we run ThinLTO, as well as
having it tailored to fit our needs for the time being.
* Finally this allows us to reuse some artifacts such as our `TargetMachine`
creation, where all our options we used today aren't necessarily supported by
upstream LLVM yet.
My hope is that we can get some experience with this copy/paste in tree and then
eventually upstream some work to LLVM itself to avoid the duplication while
still ensuring our needs are met. Otherwise I fear that maintaining these
bindings may be quite costly over the years with LLVM updates!
Fnty args rustdoc
Fixes#44570.
cc @QuietMisdreavus
cc @rust-lang/dev-tools
Considering the impact on the `hir` libs, I'll put @eddyb as reviewer.
r? @eddyb
As discovered in #44538 ARMv6 devices may or may not support unaligned memory accesses. ARMv6
Linux *seems* to have no problem with unaligned accesses but this is because the kernel is stepping
in to fix each unaligned memory access -- this incurs in a performance penalty.
This commit enforces aligned memory accesses on all our in-tree ARM targets that may be used with
ARMv6 devices. This should improve performance of Rust programs on ARMv6 devices. For the record,
clang also applies this attribute when targeting ARMv6 devices that are not running Darwin or
NetBSD.
This commit is an implementation of LLVM's ThinLTO for consumption in rustc
itself. Currently today LTO works by merging all relevant LLVM modules into one
and then running optimization passes. "Thin" LTO operates differently by having
more sharded work and allowing parallelism opportunities between optimizing
codegen units. Further down the road Thin LTO also allows *incremental* LTO
which should enable even faster release builds without compromising on the
performance we have today.
This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then
also implements two forms of ThinLTO:
* In one mode we'll *only* perform ThinLTO over the codegen units produced in a
single compilation. That is, we won't load upstream rlibs, but we'll instead
just perform ThinLTO amongst all codegen units produced by the compiler for
the local crate. This is intended to emulate a desired end point where we have
codegen units turned on by default for all crates and ThinLTO allows us to do
this without performance loss.
* In anther mode, like full LTO today, we'll optimize all upstream dependencies
in "thin" mode. Unlike today, however, this LTO step is fully parallelized so
should finish much more quickly.
There's a good bit of comments about what the implementation is doing and where
it came from, but the tl;dr; is that currently most of the support here is
copied from upstream LLVM. This code duplication is done for a number of
reasons:
* Controlling parallelism means we can use the existing jobserver support to
avoid overloading machines.
* We will likely want a slightly different form of incremental caching which
integrates with our own incremental strategy, but this is yet to be
determined.
* This buys us some flexibility about when/where we run ThinLTO, as well as
having it tailored to fit our needs for the time being.
* Finally this allows us to reuse some artifacts such as our `TargetMachine`
creation, where all our options we used today aren't necessarily supported by
upstream LLVM yet.
My hope is that we can get some experience with this copy/paste in tree and then
eventually upstream some work to LLVM itself to avoid the duplication while
still ensuring our needs are met. Otherwise I fear that maintaining these
bindings may be quite costly over the years with LLVM updates!
Fix TcpStream::local_addr docs example code
The local address's port is not 8080 in this example, that's the remote peer address port. On my machine, the local address is different every time, so I've changed `assert_eq` to only test the IP address
fix logic error in #44269's `prune_cache_value_obligations`
We want to retain obligations that *contain* inference variables, not
obligations that *don't contain* them, in order to fix#43132. Because
of surrounding changes to inference, the ICE doesn't occur in its
original case, but I believe it could still be made to occur on master.
Maybe I should try to write a new test case? Certainly not right now
(I'm mainly trying to get us a beta that we can ship) but maybe before
we land this PR on nightly?
This seems to cause a 10% performance regression in my imprecise
attempt to benchmark item-body checking for #43613, but it's better to
be slow and right than fast and wrong. If we want to recover that, I
think we can change the constrained-type-parameter code to actually
give a list of projections that are important for resolving inference
variables and filter everything else out.
We want to retain obligations that *contain* inference variables, not
obligations that *don't contain* them, in order to fix#43132. Because
of surrounding changes to inference, the ICE doesn't occur in its
original case, but I believe it could still be made to occur on master.
Maybe I should try to write a new test case? Certainly not right now
(I'm mainly trying to get us a beta that we can ship) but maybe before
we land this PR on nightly?
This seems to cause a 10% performance regression in my imprecise
attempt to benchmark item-body checking for #43613, but it's better to
be slow and right than fast and wrong. If we want to recover that, I
think we can change the constrained-type-parameter code to actually
give a list of projections that are important for resolving inference
variables and filter everything else out.
Implement `and_modify` on `Entry`
## Motivation
`Entry`s are useful for allowing access to existing values in a map while also allowing default values to be inserted for absent keys. The existing API is similar to that of `Option`, where `or` and `or_with` can be used if the option variant is `None`.
The `Entry` API is, however, missing an equivalent of `Option`'s `and_then` method. If it were present it would be possible to modify an existing entry before calling `or_insert` without resorting to matching on the entry variant.
Tracking issue: https://github.com/rust-lang/rust/issues/44733.
replace libc::res_init with res_init_if_glibc_before_2_26
The previous workaround for gibc's res_init bug is not thread-safe on
other implementations of libc, and it can cause crashes. Use a runtime
check to make sure we only call res_init when we need to, which is also
when it's safe. See https://github.com/rust-lang/rust/issues/43592.
~This PR is returning an InvalidData IO error if the glibc version string fails to parse. We could also have treated that case as "not glibc", and gotten rid of the idea that these functions could return an error. (Though I'm not a huge fan of ignoring error returns from `res_init` in any case.) Do other folks agree with these design choices?~
I'm pretty new to hacking on libstd. Is there an easy way to build a toy rust program against my changes to test this, other than doing an entire `sudo make install` on my system? What's the usual workflow?
Improve resolution of associated types in declarative macros 2.0
Make various identifier comparisons for associated types (and sometimes other associated items) hygienic.
Now declarative macros 2.0 can use `Self::AssocTy`, `TyParam::AssocTy`, `Trait<AssocTy = u8>` where `AssocTy` is an associated type of a trait `Trait` visible from the macro. Also, `Trait` can now be implemented inside the macro and specialization should work properly (fixes https://github.com/rust-lang/rust/pull/40847#issuecomment-310867299).
r? @jseyfried or @eddyb
incr compilation struct_defs.rs
I am prematurely openeing this as I need mentoring help from @michaelwoerister (also pinged @nikomatsakis)
First, is this the right approach for these changes?
Second, I'm a bit confused by the results so far.
- Changing `TupleStructFieldType(i32)` -> `...(u32)` changes only Hir and HirBody, not TypeOfItem
- Chaning `TupleStructAddField(i32)` -> `...(i32, u32)` *does* change TypeOfItem
This seems wrong. I feel like it should change TypeOfItem in both cases. Is this a bug in incr compilation or is it expected?
Faster compile times for release builds with llvm fix
Run global optimizations after the inliner to avoid spending time on optimizing dead code.
fixes#44655
The previous workaround for gibc's res_init bug is not thread-safe on
other implementations of libc, and it can cause crashes. Use a runtime
check to make sure we only call res_init when we need to, which is also
when it's safe. See https://github.com/rust-lang/rust/issues/43592.
There are a few exceptions to the rule that Arc/Rc are immutable. Rather
than dig into the details, add "generally" to hint at this difference,
as it's kind of a distraction at this point in the docs.
Additionally, Arc's docs were slightly different here generally, so add
in both the existing language and the exception.
Fixes#44105
