Yuki Okushi [Fri, 6 Aug 2021 02:21:30 +0000 (11:21 +0900)]
Rollup merge of #87727 - SkiFire13:fix-87718, r=jackh726
explicit_generic_args_with_impl_trait: fix min expected number of generics
Fixes #87718
The problem was that `synth_type_param_count` was already subtracted from `named_type_param_count`, so this ended up being subtracted again. This caused `expected_min` to overflow, and ultimately resulting in weird and wrong behaviour.
I've also added another test not present in the original issue but caused by the same bug.
In the example (mostly in the `x` function), `other_module::Trait`, `Foo`, `other_module::Whatever`, `bar` and `some_method` are now links (and `other_module` at the top too).
In case there is a type coming from another crate, it'll link to its documentation page and not its definition (but you can then click on `[src]` so I guess it's fine).
Another important detail: I voluntarily didn't add links for primitive types. I think we can discuss about adding links on them or not in a later PR (adding the support for them would require only a few lines).
Here is a video summing up everything I wrote above:
So, on my computer, the performance remains more or less the same (which is quite surprising but that's a nice surprise). Here are the numbers:
Without the option:
* core: 1m 21s
* alloc: 26.78s
* std: 27.30s
* proc_macro: 4.50s
With source to definition links generation (I enabled by default the option):
* core: 1m 25s
* alloc: 25.76s
* std: 27.07s
* proc_macro: 4.66s
So no real change here (again, I'm very surprised by this fact).
For the size of the generated source files (only taking into account the `src` folder here since it's the only one impacted) by running `du -shc .` (when I am in the source folder).
Without the option: 11.939 MB
With the option: 12.611 MB
So not a big change here either. In all those docs, I ran `grep -nR '<a class=' . | wc -l` and got 43917. So there are quite a lot of links added. :)
bors [Thu, 5 Aug 2021 14:45:09 +0000 (14:45 +0000)]
Auto merge of #87737 - LeSeulArtichaut:unsafeck-less-freeze, r=oli-obk
Only compute `is_freeze` for layout-constrained ADTs
Places are usually shallow and quick to visit. By contrast, computing `is_freeze` can be much costlier, involving inference and trait solving. Making sure to call `is_freeze` only when necessary should be beneficial for performance in most cases.
bors [Thu, 5 Aug 2021 10:35:21 +0000 (10:35 +0000)]
Auto merge of #87740 - npmccallum:naked_args, r=Amanieu
Disable unused variable lint for naked functions
In most calling conventions, accessing function parameters may require
stack access. However, naked functions have no assembly prelude to set
up stack access. This is why naked functions may only contain a single
`asm!()` block. All parameter access is done inside the `asm!()` block,
so we cannot validate the liveness of the input parameters. Therefore,
we should disable the lint for naked functions.
bors [Thu, 5 Aug 2021 07:33:20 +0000 (07:33 +0000)]
Auto merge of #87532 - tlyu:bootstrap-rev-list, r=jyn514
bootstrap.py: use `git rev-list` for robustness
Use `git rev-list` instead of `git log` to be more robust against
UI changes in git. Also, use the full email address for bors,
because `--author` uses a substring match.
Based on #87513, but is separate because it's less minimal and may require additional manual testing.
~Open questions:~
* ~Should the `merge_base` search also use `--first-parent`?~
* ~Do we exclude non-merge commits from bors? There are a few, and I'm not sure what they have in common. Some of them look like squashes, and some look like they're in rollup branches.~
bors [Wed, 4 Aug 2021 21:09:53 +0000 (21:09 +0000)]
Auto merge of #86155 - alexcrichton:abort-on-unwind, r=nikomatsakis
rustc: Fill out remaining parts of C-unwind ABI
This commit intends to fill out some of the remaining pieces of the
C-unwind ABI. This has a number of other changes with it though to move
this design space forward a bit. Notably contained within here is:
* On `panic=unwind`, the `extern "C"` ABI is now considered as "may
unwind". This fixes a longstanding soundness issue where if you
`panic!()` in an `extern "C"` function defined in Rust that's actually
UB because the LLVM representation for the function has the `nounwind`
attribute, but then you unwind.
* Whether or not a function unwinds now mainly considers the ABI of the
function instead of first checking the panic strategy. This fixes a
miscompile of `extern "C-unwind"` with `panic=abort` because that ABI
can still unwind.
* The aborting stub for non-unwinding ABIs with `panic=unwind` has been
reimplemented. Previously this was done as a small tweak during MIR
generation, but this has been moved to a separate and dedicated MIR
pass. This new pass will, for appropriate functions and function
calls, insert a `cleanup` landing pad for any function call that may
unwind within a function that is itself not allowed to unwind. Note
that this subtly changes some behavior from before where previously on
an unwind which was caught-to-abort it would run active destructors in
the function, and now it simply immediately aborts the process.
* The `#[unwind]` attribute has been removed and all users in tests and
such are now using `C-unwind` and `#![feature(c_unwind)]`.
I think this is largely the last piece of the RFC to implement.
Unfortunately I believe this is still not stabilizable as-is because
activating the feature gate changes the behavior of the existing `extern
"C"` ABI in a way that has no replacement. My thinking for how to enable
this is that we add support for the `C-unwind` ABI on stable Rust first,
and then after it hits stable we change the behavior of the `C` ABI.
That way anyone straddling stable/beta/nightly can switch to `C-unwind`
safely.
In most calling conventions, accessing function parameters may require
stack access. However, naked functions have no assembly prelude to set
up stack access. This is why naked functions may only contain a single
`asm!()` block. All parameter access is done inside the `asm!()` block,
so we cannot validate the liveness of the input parameters. Therefore,
we should disable the lint for naked functions.
This test proves that naked functions are treated the same as regular
functions regarding unused function parameters. We will change this
behavior in the next patch.
bors [Wed, 4 Aug 2021 15:39:20 +0000 (15:39 +0000)]
Auto merge of #87736 - the8472:inline-advance-by, r=Mark-Simulacrum
#[inline] slice::Iter::advance_by
https://github.com/rust-lang/rust/pull/87387#issuecomment-891942661 was marked as a regression. One of the methods in the PR was missing an inline annotation unlike all the other methods on slice iterators.
bors [Wed, 4 Aug 2021 12:58:31 +0000 (12:58 +0000)]
Auto merge of #87150 - rusticstuff:simplify_wrapping_neg, r=m-ou-se
Make wrapping_neg() use wrapping_sub(), #[inline(always)]
This is a follow-up change to the fix for #75598. It simplifies the implementation of wrapping_neg() for all integer types by just calling 0.wrapping_sub(self) and always inlines it. This leads to much less assembly code being emitted for opt-level≤1 and thus much better performance for debug-compiled code.
Background is [this discussion on the internals forum](https://internals.rust-lang.org/t/why-does-rust-generate-10x-as-much-unoptimized-assembly-as-gcc/14930).
bors [Wed, 4 Aug 2021 09:58:16 +0000 (09:58 +0000)]
Auto merge of #86197 - FabianWolff:trailing-whitespace, r=JohnTitor
Remove unnecessary trailing whitespace from error messages
Some error messages currently contain unnecessary trailing whitespace. There are some legitimate reasons for having trailing whitespace in the output, such as for uniform indentation of possibly-empty input lines, but the whitespace I have addressed here occurs in a line used only for spacing, and I see no reason why that should have trailing whitespace (spacing lines inserted in other places also don't have trailing whitespace).
I have also removed a superfluous call to `buffer.putc()`, which has no effect because the same character is already placed there by `draw_col_separator()`.
Use `git diff --ignore-space-at-eol` to see my changes; otherwise the diff is quite large due to the whitespace removed from expected outputs in `src/test/ui/`.
bors [Wed, 4 Aug 2021 07:17:25 +0000 (07:17 +0000)]
Auto merge of #87026 - FabianWolff:issue-86948, r=estebank
Allow labeled loops as value expressions for `break`
Fixes #86948. This is currently allowed:
```rust
return 'label: loop { break 'label 42; };
break ('label: loop { break 'label 42; });
break 1 + 'label: loop { break 'label 42; };
break 'outer 'inner: loop { break 'inner 42; };
```
But not this:
```rust
break 'label: loop { break 'label 42; };
```
I have fixed this, so that the above now parses as an unlabeled break with a labeled loop as its value expression.
bors [Tue, 3 Aug 2021 23:07:07 +0000 (23:07 +0000)]
Auto merge of #87746 - JohnTitor:rollup-zaapqgl, r=JohnTitor
Rollup of 8 pull requests
Successful merges:
- #81797 (Add `core::stream::from_iter`)
- #87267 (Remove space after negative sign in Literal to_string)
- #87663 (Rustdoc accessibility: use an icon for the [-]/[+] controls)
- #87720 (don't use .into() to convert types to identical types (clippy::useless_conversion))
- #87723 (Use .contains instead of manual reimplementation.)
- #87729 (Remove the aarch64 `crypto` target_feature)
- #87731 (Update cargo)
- #87734 (Test dropping union fields more)
Yuki Okushi [Tue, 3 Aug 2021 23:05:56 +0000 (08:05 +0900)]
Rollup merge of #87729 - adamgemmell:dev/deprecate-crypto, r=Amanieu
Remove the aarch64 `crypto` target_feature
The subfeatures `aes` or `sha2` should be used instead.
This can't yet be done for ARM targets as some LLVM intrinsics still require `crypto`.
Also update the runtime feature detection tests in `library/std` to mirror the updates in `stdarch`. This also helps https://github.com/rust-lang/rust/issues/86941
Yuki Okushi [Tue, 3 Aug 2021 23:05:53 +0000 (08:05 +0900)]
Rollup merge of #87663 - GuillaumeGomez:rustdoc-brace-minus-brace, r=notriddle
Rustdoc accessibility: use an icon for the [-]/[+] controls
This is a reopening of #87207 with improvement for the way of generating the `background-image` CSS property.
I quote from the original PR:
> This way, we can show the plus and minus buttons on screens, while voice
> control will read off actual words "Collapse" and "Expand" instead of reading
> "open brace minus close brace" and "open brace plus close brace".
Yuki Okushi [Tue, 3 Aug 2021 23:05:50 +0000 (08:05 +0900)]
Rollup merge of #87267 - dtolnay:negspace, r=Aaron1011
Remove space after negative sign in Literal to_string
Negative proc macro literal tokens used to be printed with a space between the minus sign and the magnitude. That's because `impl ToString for Literal` used to convert the Literal into a TokenStream, which splits the minus sign into a separate Punct token.
This PR updates the ToString impl to directly use `rustc_ast::token::Lit`'s ToString, which matches the way Rust negative numbers are idiomatically written without a space.
This_ PR implements `std::stream::from_iter`, as outlined in the _"Converting an Iterator to a Stream"_ section of the [Stream RFC](https://github.com/nellshamrell/rfcs/blob/add-async-stream-rfc/text/0000-async-stream.md#converting-an-iterator-to-a-stream). This function enables converting an `Iterator` to a `Stream` by wrapping each item in the iterator with a `Poll::Ready` instance.
Being able to convert from an iterator into a stream is useful when refactoring from iterative loops into a more functional adapter-based style. This is fairly common when using more complex `filter` / `map` / `find` chains. In its basic form this conversion looks like this:
**before**
```rust
let mut output = vec![];
for item in my_vec {
let out = do_io(item).await?;
output.push(out);
}
```
**after**
```rust
use std::stream;
let output = stream::from_iter(my_vec.iter())
.map(async |item| do_io(item).await)
.collect()?;
```
Having a way to convert an `Iterator` to a `Stream` is essential in enabling this flow.
## Implementation Notes
This PR makes use of `unsafe {}` to pin an item. Currently we're having conversations on the libs stream in Zulip how to bring `pin-project` in as a dependency to `core` so we can omit the `unsafe {}`.
This PR also includes a documentation block which references `Stream::next` which currently doesn't exist in the stdlib (originally included in the RFC and PR, but later omitted because of an unresolved issue). `stream::from_iter` can't stabilize before `Stream` does, and there's still a chance we may stabilize `Stream` with a `next` method. So this PR includes documentation referencing that method, which we can remove as part of stabilization if by any chance we don't have `Stream::next`.
## Alternatives Considered
### `impl IntoStream for T: IntoIterator`
An obvious question would be whether we could make it so every iterator can automatically be converted into a stream by calling `into_stream` on it. The answer is: "perhaps, but it could cause type issues". Types like `std::collections` may want to opt to create manual implementations for `IntoStream` and `IntoIter`, which wouldn't be possible if it was implemented through a catch-all trait.
Possibly an alternative such as `impl IntoStream for T: Iterator` could work, but it feels somewhat restrictive. In the end, converting an iterator to a stream is likely to be a bit of a niche case. And even then, **adding a standalone function to convert an `Iterator` into a `Stream` would not be mutually exclusive with a blanket implementation**.
### Naming
The exact name can be debated in the period before stabilization. But I've chosen `stream::from_iter` rather than `stream::iter` because we are _creating a stream from an iterator_ rather than _iterating a stream_. We also expect to add a stream counterpart to `iter::from_fn` later on (blocked on async closures), and having `stream::from_fn` and `stream::from_iter` would feel like a consistent pair. It also has prior art in `async_std::stream::from_iter`.
## Future Directions
### Stream conversions for collections
This is a building block towards implementing `stream/stream_mut/into_stream` methods for `std::collections`, `std::vec`, and more. This would allow even quicker refactorings from using loops to using iterator adapters by omitting the import altogether:
Only compute `is_freeze` for layout-constrained ADTs
Places are usually shallow and quick to visit. By contrast, computing
`is_freeze` can be much costlier, involving inference and trait
solving. Making sure to call `is_freeze` only when necessary should be
beneficial for performance in most cases.
This pull request closes #85735. The actual issue is a duplicate of #21974, but #85735 contains a further problem, which is an invalid suggestion if `Fn`/`FnMut`/`FnOnce` trait bounds are involved: The suggestion code checks whether the trait bound ends with `>` to determine whether it has any generic arguments, but the `Fn*` traits have a special syntax for generic arguments that doesn't involve angle brackets. The example given in #85735:
```rust
trait Foo {}
impl<'a, 'b, T> Foo for T
where
T: FnMut(&'a ()),
T: FnMut(&'b ()), {
}
```
currently produces:
```
error[E0283]: type annotations needed
--> src/lib.rs:4:8
|
4 | T: FnMut(&'a ()),
| ^^^^^^^^^^^^^ cannot infer type for type parameter `T`
|
= note: cannot satisfy `T: FnMut<(&'a (),)>`
help: consider specifying the type arguments in the function call
|
4 | T: FnMut(&'a ())::<Self, Args>,
| ^^^^^^^^^^^^^^
error: aborting due to previous error
```
which is incorrect, because there is no function call, and applying the suggestion would lead to a parse error. With my changes, I get:
```
error[E0283]: type annotations needed
--> test.rs:4:8
|
4 | T: FnMut(&'a ()),
| ^^^^^^^^^^^^^ cannot infer type for type parameter `T`
|
::: [...]/library/core/src/ops/function.rs:147:1
|
147 | pub trait FnMut<Args>: FnOnce<Args> {
| ----------------------------------- required by this bound in `FnMut`
|
= note: cannot satisfy `T: FnMut<(&'a (),)>`
error: aborting due to previous error
```
i.e. I have added a check to prevent the invalid suggestion from being issued for `Fn*` bounds, while the underlying issue #21974 remains for now.
Alex Crichton [Tue, 8 Jun 2021 18:23:58 +0000 (11:23 -0700)]
rustc: Fill out remaining parts of C-unwind ABI
This commit intends to fill out some of the remaining pieces of the
C-unwind ABI. This has a number of other changes with it though to move
this design space forward a bit. Notably contained within here is:
* On `panic=unwind`, the `extern "C"` ABI is now considered as "may
unwind". This fixes a longstanding soundness issue where if you
`panic!()` in an `extern "C"` function defined in Rust that's actually
UB because the LLVM representation for the function has the `nounwind`
attribute, but then you unwind.
* Whether or not a function unwinds now mainly considers the ABI of the
function instead of first checking the panic strategy. This fixes a
miscompile of `extern "C-unwind"` with `panic=abort` because that ABI
can still unwind.
* The aborting stub for non-unwinding ABIs with `panic=unwind` has been
reimplemented. Previously this was done as a small tweak during MIR
generation, but this has been moved to a separate and dedicated MIR
pass. This new pass will, for appropriate functions and function
calls, insert a `cleanup` landing pad for any function call that may
unwind within a function that is itself not allowed to unwind. Note
that this subtly changes some behavior from before where previously on
an unwind which was caught-to-abort it would run active destructors in
the function, and now it simply immediately aborts the process.
* The `#[unwind]` attribute has been removed and all users in tests and
such are now using `C-unwind` and `#![feature(c_unwind)]`.
I think this is largely the last piece of the RFC to implement.
Unfortunately I believe this is still not stabilizable as-is because
activating the feature gate changes the behavior of the existing `extern
"C"` ABI in a way that has no replacement. My thinking for how to enable
this is that we add support for the `C-unwind` ABI on stable Rust first,
and then after it hits stable we change the behavior of the `C` ABI.
That way anyone straddling stable/beta/nightly can switch to `C-unwind`
safely.
Michael Howell [Sat, 17 Jul 2021 00:24:35 +0000 (17:24 -0700)]
Rustdoc accessibility: use an icon for the [-]/[+] controls
This way, we can show the plus and minus buttons on screens, while voice
control will read off actual words "Collapse" and "Expand" instead of reading
"open brace minus close brace" and "open brace plus close brace".
bors [Tue, 3 Aug 2021 10:42:30 +0000 (10:42 +0000)]
Auto merge of #87725 - JohnTitor:rollup-2ywcpuk, r=JohnTitor
Rollup of 8 pull requests
Successful merges:
- #87645 (Properly find owner of closure in THIR unsafeck)
- #87646 (Fix a parser ICE on invalid `fn` body)
- #87652 (Validate that naked functions are never inlined)
- #87685 (Write docs for SyncOnceCell From and Default impl)
- #87693 (Add `aarch64-apple-ios-sim` as a possible target to the manifest)
- #87708 (Add convenience method for handling ipv4-mapped addresses by canonicalizing them)
- #87711 (Correct typo)
- #87716 (Allow generic SIMD array element type)
Yuki Okushi [Tue, 3 Aug 2021 10:07:48 +0000 (19:07 +0900)]
Rollup merge of #87708 - the8472:canonical_v6, r=dtolnay
Add convenience method for handling ipv4-mapped addresses by canonicalizing them
This simplifies checking common properties in an address-family-agnostic
way since #86335 commits to not checking IPv4 semantics
of IPv4-mapped addresses in the `Ipv6Addr` property methods.
Yuki Okushi [Tue, 3 Aug 2021 10:07:44 +0000 (19:07 +0900)]
Rollup merge of #87646 - JohnTitor:fix-parser-ice, r=oli-obk
Fix a parser ICE on invalid `fn` body
Fixes #87635
A better fix would add a check for `fn` body on `expected_one_of_not_found` but I haven't come up with a graceful way. Any idea?
r? ```@oli-obk``` ```@estebank```
Yuki Okushi [Tue, 3 Aug 2021 10:07:43 +0000 (19:07 +0900)]
Rollup merge of #87645 - LeSeulArtichaut:issue-87414, r=oli-obk
Properly find owner of closure in THIR unsafeck
Previously, when encountering a closure in a constant, the THIR unsafeck gets invoked on the owner of the constant instead of the constant itself, producing cycles.
Supersedes #87492. ```@FabianWolff``` thanks for your work on that PR, I copied your test file and added you as a co-author.