Add example using Self to reference
When I first came across `Self` I had a hard time finding references to it in the docs (and it's also been asked about on [StackOverflow](http://stackoverflow.com/questions/32304595/whats-the-difference-between-self-and-self).
I hope this example provides someone who comes across it for the first time a little more help. If there is a better way to show an example actually using `Self`, I'm happy to modify this. It was just the simplest place to start I could see.
std: Track change to cprng syscall signature (Fuchsia)
The mx_cprng_draw syscall has changed signature to separate the status
and size return values, rather than multiplexing them into a single
value with errors interpreted as a negative value. This patch tracks
that change.
Fix issues with the Add/AddAssign impls for Cow<str>
* Correct the stability attributes.
* Make Add and AddAssign actually behave the same.
* Use String::with_capacity when allocating a new string.
* Fix the tests.
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#37534.
r? @eddyb.
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.
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 #37499
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.
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".
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.
The content is duplicated, and it doesn't need to be in this location.
It's mostly trivia that doesn't apply to most of the audience.
The forge is up to date.
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".
[5/n] rustc: record the target type of every adjustment.
_This is part of a series ([prev](https://github.com/rust-lang/rust/pull/37404) | [next](https://github.com/rust-lang/rust/pull/37412)) 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>
The first commit rearranges `tcx.tables` so that all users go through `tcx.tables()`. This in preparation for per-body `Tables` where they will be requested for a specific `DefId`. Included to minimize churn.
The rest of the changes focus on adjustments, there are some renamings, but the main addition is the target type, always available in all cases (as opposed to just for unsizing where it was previously needed).
Possibly the most significant effect of this change is that figuring out the final type of an expression is now _always_ just one successful `HashMap` lookup (either the adjustment or, if that doesn't exist, the node type).
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 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.
The mx_cprng_draw syscall has changed signature to separate the status
and size return values, rather than multiplexing them into a single
value with errors interpreted as a negative value. This patch tracks
that change.
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#37232
detect extra region requirements in impls
The current "compare method" check fails to check for the "region obligations" that accrue in the fulfillment context. This branch switches that code to create a `FnCtxt` so that it can invoke the regionck code. Previous crater runs (I haven't done one with the latest tip) have found some small number of affected crates, so I went ahead and introduced a warning cycle. I will kick off a crater run with this branch shortly.
This is a [breaking-change] because previously unsound code was accepted. The crater runs also revealed some cases where legitimate code was no longer type-checking, so the branch contains one additional (but orthogonal) change. It improves the elaborator so that we elaborate region requirements more thoroughly. In particular, if we know that `&'a T: 'b`, we now deduce that `T: 'b` and `'a: 'b`.
I invested a certain amount of effort in getting a good error message. The error message looks like this:
```
error[E0276]: impl has stricter requirements than trait
--> traits-elaborate-projection-region.rs:33:5
|
21 | fn foo() where T: 'a;
| --------------------- definition of `foo` from trait
...
33 | fn foo() where U: 'a { }
| ^^^^^^^^^^^^^^^^^^^^^^^^ impl has extra requirement `U: 'a`
|
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #18937 <https://github.com/rust-lang/rust/issues/18937>
note: lint level defined here
--> traits-elaborate-projection-region.rs:12:9
|
12 | #![deny(extra_requirement_in_impl)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^
```
Obviously the warning only prints if this is a _new_ error (that resulted from the bugfix). But all existing errors that fit this description are updated to follow the general template. In order to get the lint to preserve the span-labels and the error code, I separate out the core `Diagnostic` type (which encapsulates the error code, message, span, and children) from the `DiagnosticBuilder` (which layers on a `Handler` that can be used to report errors). I also extended `add_lint` with an alternative `add_lint_diagnostic` that takes in a full diagnostic (cc @jonathandturner for those changes). This doesn't feel ideal but feels like it's moving in the right direction =).
r? @pnkfelix
cc @arielb1
Fixes#18937
