Rollup of 17 pull requests #37581
Closed
Rollup of 17 pull requests #37581
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The example code for higher-ranked trait bounds on closures had an unnecessary `mut` which was confusing, and the text referred to an mutable reference which does not exist in the code (and isn't needed). Removed the `mut`s and fixed the text to better describe the actual error for the failing example.
The new Vec::extend covers the duties of .extend_from_slice() and some previous specializations.
.wrapping_offset() exposes the arith_offset intrinsic in the core module. This is the first step in making it possible to stabilize the interface later. `arith_offset` is a useful tool for developing iterators for two reasons: 1. `arith_offset` is used by the slice's iterator, the most important iterator in libcore, and it is natural that Rust users need the same power available to implement similar iterators. 2. It is a good way to implement raw pointer iterations with step greater than one. The name seems to fit the style of methods like "wrapping_add".
This now produces as good code (with optimizations) using the TrustedLen codepath.
This commit is an implementation of [RFC 1665] which adds support for the `#![windows_subsystem]` attribute. This attribute allows specifying either the "windows" or "console" subsystems on Windows to the linker. [RFC 1665]: https://github.com/rust-lang/rfcs/blob/master/text/1665-windows-subsystem.md Previously all Rust executables were compiled as the "console" subsystem which meant that if you wanted a graphical application it would erroneously pop up a console whenever opened. When compiling an application, however, this is undesired behavior and the "windows" subsystem is used instead to have control over user interactions. This attribute is validated, but ignored on all non-Windows platforms. cc rust-lang#37499
This significantly reduces the number of bytes hashed by IchHasher.
This significantly reduces the number of bytes hashed by IchHasher.
The rustc-generated function `main` should respect the same config for frame pointer elimination as the rest of code.
Environment variables on windows can't be empty.
On 64-bit platforms this reduces the size of `Expr` from 96 bytes to 88 bytes.
On 64-bit platforms this reduces the size of `Expr_` from 64 bytes to 56 bytes, and reduces the size of `Expr` from 88 bytes to 80 bytes.
Fix some mistakes in HRTB docs The example code for higher-ranked trait bounds on closures had an unnecessary `mut` which was confusing, and the text referred to an mutable reference which does not exist in the code (and isn't needed). Removed the `mut`s and fixed the text to better describe the actual error for the failing example. Thanks to csd_ on IRC for pointing out these problems! r? @steveklabnik
Add Iterator trait TrustedLen to enable better FromIterator / Extend This trait attempts to improve FromIterator / Extend code by enabling it to trust the iterator to produce an exact number of elements, which means that reallocation needs to happen only once and is moved out of the loop. `TrustedLen` differs from `ExactSizeIterator` in that it attempts to include _more_ iterators by allowing for the case that the iterator's len does not fit in `usize`. Consumers must check for this case (for example they could panic, since they can't allocate a collection of that size). For example, chain can be TrustedLen and all numerical ranges can be TrustedLen. All they need to do is to report an exact size if it fits in `usize`, and `None` as the upper bound otherwise. The trait describes its contract like this: ``` An iterator that reports an accurate length using size_hint. The iterator reports a size hint where it is either exact (lower bound is equal to upper bound), or the upper bound is `None`. The upper bound must only be `None` if the actual iterator length is larger than `usize::MAX`. The iterator must produce exactly the number of elements it reported. This trait must only be implemented when the contract is upheld. Consumers of this trait must inspect `.size_hint()`’s upper bound. ``` Fixes rust-lang#37232
Add release notes for 1.12.1 It completely slipped my mind that this is something I'm supposed to do as part of the release process...
Add impls for `&Wrapping`. Also `Sum`, `Product` impls for both `Wrapping` and `&Wrapping`.
There are two changes here (split into two commits):
- Ops for references to `&Wrapping` (`Add`, `Sub`, `Mul` etc.) similar to the way they are implemented for primitives.
- Impls for `iter::{Sum,Product}` for `Wrapping`.
As far as I know `impl` stability attributes don't really matter so I didn't bother breaking up the macro for two different kinds of stability. Happy to change if it does matter.
[3/n] rustc: unify and simplify managing associated items. _This is part of a series ([prev](rust-lang#37401) | [next](rust-lang#37404)) of patches designed to rework rustc into an out-of-order on-demand pipeline model for both better feature support (e.g. [MIR-based](https://github.com/solson/miri) early constant evaluation) and incremental execution of compiler passes (e.g. type-checking), with beneficial consequences to IDE support as well. If any motivation is unclear, please ask for additional PR description clarifications or code comments._ <hr> `ImplOrTraitItem`/`impl_or_trait_item` have been renamed to `AssociatedItem`/`associated_item`. The common fields from (what used to be) `ty::ImplOrTraitItem`'s variants have been pulled out, leaving only an `AssociatedKind` C-like enum to distinguish between methods, constants and types. The type information has been removed from `AssociatedItem`, and as such the latter can now be computed on-demand from the local HIR map, i.e. an extern-crate-enabled `TraitItem | ImplItem`. It may be moved to HIR in the future, if we intend to start using HIR types cross-crate. `ty::ExplicitSelfCategory` has been moved to `rustc_typeck` and is produced on-demand from the signature of the method, and a `method_has_self_argument` field on `AssociatedItem`, which is used to indicate that the first argument is a sugary "method receiver" and as such, method call syntax can be used.
Support GDB with native rust support This PR aims at making the debuginfo tests pass with the newer GDB versions which have native rust support (RGDB) To that end debuginfo tests now support three GDB prefixes: - `gdb` applicable to both GDB varieties - `gdbg` (**G**eneric) only applicable to the old GDB - `gdbr` (**R**ust) only applicable to the new RGDB Whether the GDB has rust support is detected based on it's version: GDB >= 7.11.10 is considered to have rust support. --- **Test updates** All tests have been updated to the new GDB version. Note that some tests currently require the GDB trunk<sup>1</sup>. --- **How to move forward with this PR:** I propose the following steps for moving forward with this PR: - [x] Validate the general approach of this PR (the `gdb-`, `gdbg-` and `gdbr-` split) - [x] Validate the approach taken for updating the debuginfo tests (I've checked this since there's (almost) no `set language c` left, which was my main concern) - [x] Determine how to distinguish between the new and old GDB (and implement that) - [ ] Add one or more non-gating build bots with the new GDB (blocked on the previous item, can happen after this PR has been merged) - [ ] If the new bots pass the tests, gate on them - [x] \(Maybe) update the remaining tests to run without `set syntax c` (in a separate PR) - [ ] \(Maybe) add tests specifically for the new GDB (in a separate PR / open an issue about this) I'm not completely sure about the build bot related steps (cc @alexcrichton), the current approach was suggested to prevent any downtime / broken build time between a new GDB gating builder being added and this PR being merged. --- **Suboptimal RGDB Output** I've found several places where the output of RGDB is not ideal. They are tagged with `// FIXME`, here is an overview: - [x] Trait references are not syntactically correct: `type_names::&Trait2<...>` (**WontFix**: the issue is minor and from @Manishearth below: "to properly address the trait issue we should wait for trait object support") - [x] Univariant enums are printed as `<error reading variable>` (**Fixed** in GDB trunk<sup>1<sup>) - [x] Unions are printed as `<error reading variable>` (**Fixed** in GDB trunk<sup>1</sup>) - [x] "Nil Enums" (`enum Foo {}`) are printed as `<error reading variable>` (**WontFix**: the are not supposed to exist) - [x] I have found no alternative for `sizeof(var)` in rust mode, so had to resort to `set language c` (**Fixed** in GDB trunk<sup>1</sup>) - [x] I have found not way of interpreting a value as a specific enum variant, so had to resort to `set language c` (**Fixed** in GDB trunk<sup>1</sup>) - [x] Before the initial `run` command, gdb does not realise it should be in rust mode (thus, if one want's to print statics before the run one has to explicitly `set language rust`) (maybe this is intended / expected behaviour, if so, someone please tell me ;) (**"Expected"** / current behaviour of GDB: picks up jemalloc, see rust-lang#37410 (comment)) <sup>1</sup>: Or rather in @Manishearth's trunk, waiting to be merged upstream. --- cc @alexcrichton, @michaelwoerister, rust-lang#36323
Add .wrapping_offset() methods .wrapping_offset() exposes the arith_offset intrinsic in the core module (as methods on raw pointers, next to offset). This is the first step in making it possible to stabilize the interface later. `arith_offset` is a useful tool for developing iterators for two reasons: 1. `arith_offset` is used by the slice's iterator, the most important iterator in libcore, and it is natural that Rust users need the same power available to implement similar iterators. 2. It is a good way to implement raw pointer iterations with step greater than one. The name seems to fit the style of methods like "wrapping_add".
…lwoerister
Reduce the number of bytes hashed by IchHasher.
IchHasher uses blake2b hashing, which is expensive, so the fewer bytes hashed
the better. There are two big ways to reduce the number of bytes hashed.
- Filenames in spans account for ~66% of all bytes (for builds with debuginfo).
The vast majority of spans have the same filename for the start of the span
and the end of the span, so hashing the filename just once in those cases is
a big win.
- u32 and u64 and usize values account for ~25%--33% of all bytes (for builds
with debuginfo). The vast majority of these are small, i.e. fit in a u8, so
shrinking them down before hashing is also a big win.
This PR implements these two optimizations. I'm certain the first one is safe.
I'm about 90% sure that the second one is safe.
Here are measurements of the number of bytes hashed when doing
debuginfo-enabled builds of stdlib and
rustc-benchmarks/syntex-0.42.2-incr-clean.
```
stdlib syntex-incr
------ -----------
original 156,781,386 255,095,596
half-SawSpan 106,744,403 176,345,419
short-ints 45,890,534 118,014,227
no-SawSpan[*] 6,831,874 45,875,714
[*] don't hash the SawSpan at all. Not part of this PR, just implemented for
comparison's sake.
```
For debug builds of syntex-0.42.2-incr-clean, the two changes give a 1--2%
speed-up.
Don't reuse RandomState seeds cc rust-lang#36481
…rson rustc: Add knowledge of Windows subsystems. This commit is an implementation of [RFC 1665] which adds support for the `#![windows_subsystem]` attribute. This attribute allows specifying either the "windows" or "console" subsystems on Windows to the linker. [RFC 1665]: https://github.com/rust-lang/rfcs/blob/master/text/1665-windows-subsystem.md Previously all Rust executables were compiled as the "console" subsystem which meant that if you wanted a graphical application it would erroneously pop up a console whenever opened. When compiling an application, however, this is undesired behavior and the "windows" subsystem is used instead to have control over user interactions. This attribute is validated, but ignored on all non-Windows platforms. cc rust-lang#37499
…eveklabnik Add missing urls for ErrorKind's variants r? @steveklabnik
set frame pointer elimination attribute for main The rustc-generated function `main` should respect the same config for frame pointer elimination as the rest of code.
Use DefId's in const eval for cross-crate const fn's Fixes rust-lang#36954. r? @eddyb cc @raphaelcohn
Fix ICE when querying DefId on Def::Err. Also moves computations into check that `kind_id` is `Ok(_)`, which is in theory an optimization, though I expect it's minor. Fixes rust-lang#37534. r? @eddyb.
…hton Peekable::peek(): Use Option::as_ref() Replace the match expression in .peek() with Option::as_ref() since it's the same functionality.
Set RUSTC_BOOTSTRAP to some value. Environment variables on windows can't be empty.
…=eddyb Shrink `hir::Expr` slightly r? @eddyb
|
(rust_highfive has picked a reviewer for you, use r? to override) |
|
Experimenting with a rollup to clear up the backlog... |
|
Nevermind, having problems with this one |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
&Wrapping. AlsoSum,Productimpls for bothWrappingand&Wrapping. #37356, [3/n] rustc: unify and simplify managing associated items. #37402, Support GDB with native rust support #37410, Add .wrapping_offset() methods #37422, Reduce the number of bytes hashed by IchHasher. #37427, Don't reuse RandomState seeds #37470, rustc: Add knowledge of Windows subsystems. #37501, Add missing urls for ErrorKind's variants #37537, set frame pointer elimination attribute for main #37556, Use DefId's in const eval for cross-crate const fn's #37557, Fix ICE when querying DefId on Def::Err. #37564, Peekable::peek(): Use Option::as_ref() #37565, Set RUSTC_BOOTSTRAP to some value. #37566, Shrinkhir::Exprslightly #37577