Rollup of 8 pull requests #40886
Closed
Rollup of 8 pull requests #40886
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
It's fairly common to expose an API which takes an `IntoIterator` and immediately collects that into a vector. It's also common to buffer a bunch of items into a vector and then pass that into one of these APIs. If the iterator hasn't been advanced, we can make this `from_iter` simply reassemble the original `Vec` with no actual iteration or reallocation.
... even if contained `Vec` is not empty. E. g. for
```
let v = vec![10u8, 20];
let mut c = io::Cursor::new(v);
c.write_all(b"aaaa").unwrap();
println!("{:?}", c.into_inner());
```
result is
```
[97, 97, 97, 97]
```
and not
```
[10, 20, 97, 97, 97, 97]
```
In master, this field was an arbitrary node-id (in fact, an id for something that doesn't even exist in the HIR -- the `catch` node). Breaks targeting this block used that id. In the newer system, this field is a boolean, and any breaks targeted this block will use the id of the block.
The new strategy is as follows. First, the `!` type is assigned
in two cases:
- a block with a diverging statement and no tail expression (e.g.,
`{return;}`);
- any expression with the type `!` is considered diverging.
Second, we track when we are in a diverging state, and we permit a value
of any type to be coerced **into** `!` if the expression that produced
it is diverging. This means that `fn foo() -> ! { panic!(); 22 }`
type-checks, even though the block has a type of `usize`.
Finally, coercions **from** the `!` type to any other are always
permitted.
Fixes rust-lang#39808.
The existing pattern for coercions is fairly complex. `CoerceMany` enapsulates it better into a helper.
`match { }` now (correctly?) indicates divergence, which results in more
unreachable warnings. We also avoid fallback to `!` if there is just one
arm (see new test: `match-unresolved-one-arm.rs`).
This slightly affects the error messages in one particular compile-fail test.
Instead, wait until coercion time. This has some small effects on a few tests (one less temporary, generally better errors when trying to call methods or otherwise "force" the type).
First, we keep a `CoerceMany` now to find the LUB of all the break expressions. Second, this `CoerceMany` is actually an `Option<CoerceMany>`, and we store `None` for loops where "break with an expression" is disallowed. This avoids silly duplicate errors about a type mismatch, since the loops pass already reports an error that the break cannot have an expression. Finally, since we now detect an invalid break target during HIR lowering, refactor `find_loop` to be infallible. Adjust tests as needed: - some spans from breaks are slightly different - break up a single loop into multiple since `CoerceMany` silences redundant and derived errors - add a ui test that we only give on error for loop-break-value
Part of rust-lang#29363 In the section about the default implementations of ToSocketAddrs, I moved the bulletpoint of SocketAddrV4 & SocketAddrV6 to the one stating that SocketAddr is constructed trivially, as this is what's actually the case
The `try_coerce` method coerces from a source to a target type, possibly inserting adjustments. It should guarantee that the post-adjustment type is a subtype of the target type (or else that some side-constraint has been registered which will lead to an error). However, it used to return the (possibly adjusted) source as the type of the expression rather than the target. This led to less good downstream errors. To work around this, the code around blocks -- and particular tail expressions in blocks -- had some special case manipulation. However, since that code is now using the more general `CoerceMany` construct (to account for breaks), it can no longer take advantage of that. This lead to some regressions in compile-fail tests were errors were reported at "less good" locations than before. This change modifies coercions to return the target type when successful rather the source type. This extends the behavior from blocks to all coercions. Typically this has limited effect but on a few tests yielded better errors results (and avoided regressions, of course). This change also restores the hint about removing semicolons which went missing (by giving 'force-unit' coercions a chance to add notes etc).
They are so annoying to update, and haven't caught any bugs afaik.
We no longer give suggestions; this is presumably related to the changes I made in coercion. However, those suggestions appear to be wrong anyhow!
This includes an important fix for rustc contributors in rust-lang/book#571 I'm going to update the other ones as well here while we're at it; no need to spam PRs.
change the strategy for diverging types
The new strategy is as follows. First, the `!` type is assigned
in two cases:
- a block with a diverging statement and no tail expression (e.g.,
`{return;}`);
- any expression with the type `!` is considered diverging.
Second, we track when we are in a diverging state, and we permit a value
of any type to be coerced **into** `!` if the expression that produced
it is diverging. This means that `fn foo() -> ! { panic!(); 22 }`
type-checks, even though the block has a type of `usize`.
Finally, coercions **from** the `!` type to any other are always
permitted.
Fixes rust-lang#39808.
Fixes rust-lang#39984.
Handle extern functions and statics in save-analysis r? @eddyb
Update docs for std::str fixes rust-lang#29375 I noticed there are docs for the `str` primitive type, which contained extensive examples, so my additions give a more general explanation of `&str`. But please let me know if something can be explained more or changed. r? @steveklabnik
Specialize Vec::from_iter for vec::IntoIter It's fairly common to expose an API which takes an `IntoIterator` and immediately collects that into a vector. It's also common to buffer a bunch of items into a vector and then pass that into one of these APIs. If the iterator hasn't been advanced, we can make this `from_iter` simply reassemble the original `Vec` with no actual iteration or reallocation. r? @aturon
Document Cursor::new position is 0
... even if contained `Vec` is not empty. E. g. for
```
let v = vec![10u8, 20];
let mut c = io::Cursor::new(v);
c.write_all(b"aaaa").unwrap();
println!("{:?}", c.into_inner());
```
result is
```
[97, 97, 97, 97]
```
and not
```
[10, 20, 97, 97, 97, 97]
```
Rustdoc: memoize `pub use`-reexported macros so they don't appear twice in docs Closes rust-lang#39436 Preserves existing behavior for `#[macro_reexport]`. `pub use`'d macros are shown as reexports unless inlined, and also correctly obey `#[doc(hidden)]`. r? @jseyfried cc @SergioBenitez
…omez Improve std::net docs Fixes rust-lang#29363 Summary: * Added a _lot_ of missing links, both to other types/methods and to IETF RFCs, and changed occurences of just "RFC" to "IETF RFC" * Expanded a bunch of top-level docs, specifically the module docs & the docs for `TcpListener`, `TcpStream`, `UdpSocket`, `IpAddr`, `Ipv4Addr`, `Ipv6Addr`, `SocketAddr`, `SocketAddrV4`, `SocketAddrV6`, * Expanded method docs for `SocketAddrV6`, `AddrParseError`, * Various edits for clarity, consistency, and accuracy See the commit descriptions for more detail. Things not done quite as laid out in the task list in rust-lang#29363: * `AddrParseError` still doesn't have examples, but I wasn't quite sure how to do them; other `FromStr` error types don't have any, either * I didn't link to an IETF RFC in `IpAddr`, but in `Ipv4Addr` and `Ipv6Addr` and linked tho those from `IpAddr`; this seems more appropriate to me * Similarly, I didn't really exand `SocketAddr`'s docs, but elaborated on `SocketAddrV4` and `SocketAddrV6`'s and linked to them from `SocketAddr` Theres definitely still room for improvement, but this should be a good first effort 😄
Update various book modules This includes an important fix for rustc contributors in rust-lang/book#571 I'm going to update the other ones as well here while we're at it; no need to spam PRs. r? @nrc
|
@bors r+ p=10 |
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nikomatsakis (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
|
📌 Commit b75dd8e has been approved by |
|
@nikomatsakis (or maybe @nrc?) I'm going to guess that your PR here is causing this Travis failure. That line in particular was added recently, so your branches never ran against that change. |
|
Pretty sure that's not me |
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.
pub use-reexported macros so they don't appear twice in docs #40814, Improve std::net docs #40838, Update various book modules #40864