- 08 10月, 2017 6 次提交
-
-
由 kennytm 提交于
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
-
由 kennytm 提交于
Update trait summaries for std::fmt This patch is part of #29355. r? @steveklabnik
-
由 kennytm 提交于
incr.comp.: Fix infinite recursion in Debug implementation of DepNode Small bug fix. Depends on #44901 to land first.
-
由 bors 提交于
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].
-
由 bors 提交于
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!
-
- 07 10月, 2017 10 次提交
-
-
由 Guillaume Gomez 提交于
-
由 Alex Crichton 提交于
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!
-
由 bors 提交于
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
-
由 Guillaume Gomez 提交于
-
由 bors 提交于
Fix issue #44731. Also excludes `impl Trait` from everybody_loops if it appears in the path. Fixes #44731.
-
由 bors 提交于
{compiler-builtins,libc} shim cleanup ~~Depends on https://github.com/rust-lang/libc/pull/764; opening early for feedback.~~ r? @alexcrichton
-
由 Tamir Duberstein 提交于
-
由 bors 提交于
implement pattern-binding-modes RFC See the [RFC] and [tracking issue]. [tracking issue]: #42640 [RFC]: https://github.com/rust-lang/rfcs/blob/491e0af/text/2005-match-ergonomics.md
-
由 Tobias Schottdorf 提交于
See the [RFC] and [tracking issue]. [tracking issue]: https://github.com/rust-lang/rust/issues/42640 [RFC]: https://github.com/rust-lang/rfcs/blob/491e0af/text/2005-match-ergonomics.md
-
由 bors 提交于
Improvements to `proc_macro::Span` API Motivation: https://internals.rust-lang.org/t/better-panic-location-reporting-for-unwrap-and-friends/5042/12?u=logician TODO: - [x] Bikeshedding/complete API - [x] Implement tests/verify return values cc @jseyfried @nrc
-
- 06 10月, 2017 15 次提交
-
-
由 bors 提交于
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.
-
由 Ariel Ben-Yehuda 提交于
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.
-
由 bors 提交于
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.
-
由 bors 提交于
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?
-
由 mchlrhw 提交于
-
由 bors 提交于
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
-
由 bors 提交于
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?
-
由 Austin Bonander 提交于
-
由 bors 提交于
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
-
由 Jack O'Connor 提交于
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.
-
由 Vadim Petrochenkov 提交于
-
由 steveklabnik 提交于
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
-
由 bors 提交于
address some FIXME whose associated issues were marked as closed part of #44366
-
由 Andreas Jonson 提交于
-
由 bors 提交于
Store a new Region value every time we create a new region variable Paired with @spastorino to walk through this and implement #44870.
-
- 05 10月, 2017 9 次提交
-
-
由 bors 提交于
Rollup of 9 pull requests - Successful merges: #44664, #44935, #44972, #44980, #44987, #44997, #45006, #45017, #45024 - Failed merges:
-
由 kennytm 提交于
add the issue number to doc_masked's feature gate Whoops, missed this in the original `#[doc(masked)]` PR.
-
由 kennytm 提交于
Add missing urls for Mutex r? @rust-lang/docs
-
由 kennytm 提交于
Typo in `librustc/README.md`
-
由 kennytm 提交于
Use HTTPS protocol for "chat.mibbit.com" I changed the `http://` protocol to `https://` for the `chat.mibbit.com` website.
📝 --[**Suriyaa**](https://mozillians.org/de/u/suriyaakudo/)🦊 (*PS: Is somebody interested to vouch me at https://mozillians.org/de/u/suriyaakudo/?*) -
由 kennytm 提交于
`EndRegion` do not always correspond to borrow-data entries Remove assertion that the argument to every `EndRegion` correspond to some dataflow-tracked borrow-data entry. Fix #44828 (The comment thread on the aforementioned issue discusses why its best to just remove this assertion.)
-
由 kennytm 提交于
update books for next release Also fixes some stdlib links to the reference which have changed. First step in https://forge.rust-lang.org/release-process.html, doing it a few days early
😄 -
由 kennytm 提交于
fix ItemKind::DefaultImpl doc comment Upgrade comment to doc comment. ...Is this actually used? If so, why does the `Impl` variant right below have a `Defaultness`?
-
由 kennytm 提交于
Add links to headers in README and CONTRIBUTING this also adds dependencies to CONTRIBUTING I'm just getting started building the rust compiler and noticed this information/ability was missing. It was also missing the gdb dependency for running tests. I pulled the information out of `appveyor.yml` and recommended later than 7.1 because that is what [apt ships](https://packages.ubuntu.com/search?suite=trusty&keywords=gdb). Feel free to tell me something different!
-