bors [Fri, 21 May 2021 05:47:24 +0000 (05:47 +0000)]
Auto merge of #85060 - ChrisDenton:win-file-exists, r=yaahc
Windows implementation of feature `path_try_exists`
Draft of a Windows implementation of `try_exists` (#83186).
The first commit reorganizes the code so I would be interested to get some feedback on if this is a good idea or not. It moves the `Path::try_exists` function to `fs::exists`. leaving the former as a wrapper for the latter. This makes it easier to provide platform specific implementations and matches the `fs::metadata` function.
The other commit implements a Windows specific variant of `exists`. I'm still figuring out my approach so this is very much a first draft. Eventually this will need some more eyes from knowledgable Windows people.
bors [Fri, 21 May 2021 02:39:39 +0000 (02:39 +0000)]
Auto merge of #85382 - Aaron1011:project-eval, r=nikomatsakis
Always produce sub-obligations when using cached projection result
See https://github.com/rust-lang/rust/issues/85360
When we skip adding the sub-obligations to the `obligation` list, we can affect whether or not the final result is `EvaluatedToOk` or `EvaluatedToOkModuloObligations`. This creates problems for incremental compilation, since the projection cache is untracked shared state.
To solve this issue, we unconditionally process the sub-obligations. Surprisingly, this is a slight performance *win* in many cases.
bors [Thu, 20 May 2021 21:11:19 +0000 (21:11 +0000)]
Auto merge of #85521 - alexcrichton:less-tls-inline, r=Mark-Simulacrum
std: Don't inline TLS accessor on MinGW
This is causing [issues] on Cargo's own CI for MinGW and given the
original investigation there's no reason that MinGW should work when
MSVC doesn't, this this tweaks the MSVC exception to being a Windows exception.
Alex Crichton [Thu, 20 May 2021 19:45:05 +0000 (12:45 -0700)]
std: Don't inline TLS accessor on MinGW
This is causing [issues] on Cargo's own CI for MinGW and given the
original investigation there's no reason that MinGW should work when
MSVC doesn't, this this tweaks the MSVC exception to being a Windows exception.
bors [Thu, 20 May 2021 18:30:26 +0000 (18:30 +0000)]
Auto merge of #85518 - GuillaumeGomez:rollup-mq4ohfy, r=GuillaumeGomez
Rollup of 5 pull requests
Successful merges:
- #85275 (Move `std::memchr` to `sys_common`)
- #85326 (bootstrap: ensure host std when cross-compiling tools, fixes #85320)
- #85375 (Fix missing lifetimes diagnostics after #83759)
- #85507 (Extend escape key check)
- #85509 (Prevent tab title to "null" if the URL is a search one)
Guillaume Gomez [Thu, 20 May 2021 15:56:56 +0000 (17:56 +0200)]
Rollup merge of #85375 - SkiFire13:fix-85347, r=jackh726
Fix missing lifetimes diagnostics after #83759
In #83759 while rebasing I didn't realize there was a new function for suggesting to add lifetime arguments. It relied on some invariants, namely that if a generic type/trait has angle brackets then it must have some generic argument, which is now no longer true. This PR updates that function to handle the new invariants.
This also adds a new regression test but I'm not sure if that's the correct place for it.
Guillaume Gomez [Thu, 20 May 2021 15:56:46 +0000 (17:56 +0200)]
Rollup merge of #85275 - CDirkx:memchr, r=m-ou-se
Move `std::memchr` to `sys_common`
`std::memchr` is a thin abstraction over the different `memchr` implementations in `sys`, along with documentation and tests. The module is only used internally by `std`, nothing is exported externally. Code like this is exactly what the `sys_common` module is for, so this PR moves it there.
bors [Thu, 20 May 2021 13:07:35 +0000 (13:07 +0000)]
Auto merge of #84665 - adamgemmell:aarch64-features, r=Amanieu
Update list of allowed aarch64 features
I recently added these features to std_detect for aarch64 linux, pending [review](https://github.com/rust-lang/stdarch/pull/1146).
I have commented any features not supported by LLVM 9, the current minimum version for Rust. Some (PAuth at least) were renamed between 9 & 12 and I've left them disabled. TME, however, is not in LLVM 9 but I've left it enabled.
See https://github.com/rust-lang/stdarch/issues/993
bors [Thu, 20 May 2021 07:39:24 +0000 (07:39 +0000)]
Auto merge of #85486 - RalfJung:rollup-4ibcxuu, r=RalfJung
Rollup of 8 pull requests
Successful merges:
- #84717 (impl FromStr for proc_macro::Literal)
- #85169 (Add method-toggle to <details> for methods)
- #85287 (Expose `Concurrent` (private type in public i'face))
- #85315 (adding time complexity for partition_in_place iter method)
- #85439 (Add diagnostic item to `CStr`)
- #85464 (Fix UB in documented example for `ptr::swap`)
- #85470 (Fix invalid CSS rules for a:hover)
- #85472 (CTFE Machine: do not expose Allocation)
bors [Thu, 20 May 2021 04:58:13 +0000 (04:58 +0000)]
Auto merge of #84697 - CDirkx:util, r=m-ou-se
Introduce `sys_common::rt::rtprintpanic!` to replace `sys_common::util` functionality
This PR introduces a new macro `rtprintpanic!`, similar to `sys_common::util::dumb_print` and uses that macro to replace all `sys_common::util` functionality.
bors [Thu, 20 May 2021 00:55:27 +0000 (00:55 +0000)]
Auto merge of #85391 - Mark-Simulacrum:opt-tostring, r=scottmcm
Avoid zero-length memcpy in formatting
This has two separate and somewhat orthogonal commits. The first change adjusts the ToString general impl for all types that implement Display; it no longer uses the full format machinery, rather directly falling onto a `std::fmt::Display::fmt` call. The second change directly adjusts the general core::fmt::write function which handles the production of format_args! to avoid zero-length push_str calls.
Both changes target the fact that push_str will still call memmove internally (or a similar function), as it doesn't know the length of the passed string. For zero-length strings in particular, this is quite expensive, and even for very short (several bytes long) strings, this is also expensive. Future work in this area may wish to have us fallback to write_char or similar, which may be cheaper on the (typically) short strings between the interpolated pieces in format_args!.
Ralf Jung [Wed, 19 May 2021 22:19:08 +0000 (00:19 +0200)]
Rollup merge of #85464 - steffahn:fix_ub_in_ptr_swap_docs, r=dtolnay
Fix UB in documented example for `ptr::swap`
Compare [this (short) discussion on zulip](https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Pointers.20to.20overlapping.20arrays) (or [in the archive](https://zulip-archive.rust-lang.org/122651general/92017Pointerstooverlappingarrays.html), if you don’t have an account).
Ralf Jung [Wed, 19 May 2021 22:19:02 +0000 (00:19 +0200)]
Rollup merge of #85315 - satylogin:master, r=yaahc
adding time complexity for partition_in_place iter method
I feel that one thing missing from rust docs compared to cpp references is existence of time complexity for all methods and functions. While it would be humongous task to include it for everything in single go, it is still doable if we as community keep on adding it in relevant places as and when we find them.
This PR adds the time complexity for partition_in_place method in iter.
Ralf Jung [Wed, 19 May 2021 22:18:58 +0000 (00:18 +0200)]
Rollup merge of #85287 - eggyal:expose-test-concurrent, r=m-ou-se
Expose `Concurrent` (private type in public i'face)
#53410 introduced experimental support for custom test frameworks.
Such frameworks may wish to build upon `library/test` by calling into its publicly exposed API (which I entirely understand is wholly unstable). However, any that wish to call `test::run_test` cannot currently do so because `test::options::Concurrent` (the type of its `concurrent` parameter) is not publicly exposed.
Ralf Jung [Wed, 19 May 2021 22:18:56 +0000 (00:18 +0200)]
Rollup merge of #84717 - dtolnay:literalfromstr, r=petrochenkov
impl FromStr for proc_macro::Literal
Note that unlike `impl FromStr for proc_macro::TokenStream`, this impl does not permit whitespace or comments. The input string must consist of nothing but your literal.
bors [Wed, 19 May 2021 21:50:45 +0000 (21:50 +0000)]
Auto merge of #85340 - the8472:no-inplaceiterable-on-peekable, r=yaahc
remove InPlaceIterable marker from Peekable due to unsoundness
The unsoundness is not in Peekable per se, it rather is due to the
interaction between Peekable being able to hold an extra item
and vec::IntoIter's clone implementation shortening the allocation.
An alternative solution would be to change IntoIter's clone implementation
to keep enough spare capacity available.
bors [Wed, 19 May 2021 18:41:23 +0000 (18:41 +0000)]
Auto merge of #83842 - LeSeulArtichaut:thir-vec, r=nikomatsakis
Store THIR in `IndexVec`s instead of an `Arena`
This is a necessary step to store the THIR in a query: #85273. See [relevant discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/278509-project-thir-unsafeck/topic/THIR-dependent.20queries.20design).
bors [Wed, 19 May 2021 15:59:46 +0000 (15:59 +0000)]
Auto merge of #84876 - alexcrichton:inline-thread-locals-cross-crate, r=Mark-Simulacrum
std: Attempt again to inline thread-local-init across crates
Issue #25088 has been part of `thread_local!` for quite some time now.
Historical attempts have been made to add `#[inline]` to `__getit`
in #43931, #50252, and #59720, but these attempts ended up not landing
at the time due to segfaults on Windows.
In the interim though with `const`-initialized thread locals AFAIK this
is the only remaining bug which is why you might want to use
`#[thread_local]` over `thread_local!`. As a result I figured it was
time to resubmit this and see how it fares on CI and if I can help
debugging any issues that crop up.
bors [Wed, 19 May 2021 10:11:28 +0000 (10:11 +0000)]
Auto merge of #85376 - RalfJung:ptrless-allocs, r=oli-obk
CTFE core engine allocation & memory API improvemenets
This is a first step towards https://github.com/rust-lang/miri/issues/841.
- make `Allocation` API offset-based (no more making up `Pointer`s just to access an `Allocation`)
- make `Memory` API higher-level (combine checking for access and getting access into one operation)
The Miri-side PR is at https://github.com/rust-lang/miri/pull/1804.
r? `@oli-obk`
bors [Wed, 19 May 2021 07:25:17 +0000 (07:25 +0000)]
Auto merge of #85276 - Bobo1239:more_dso_local, r=nagisa
Set dso_local for more items
Related to https://github.com/rust-lang/rust/pull/83592. (cc `@nagisa)`
Noticed that on x86_64 with `relocation-model: static` `R_X86_64_GOTPCREL` relocations were still generated in some cases. (related: https://github.com/Rust-for-Linux/linux/issues/135; Rust-for-Linux needs these fixes to successfully build)
First time doing anything with LLVM so not sure whether this is correct but the following are some of the things I've tried to convince myself.
## C equivalent
Example from clang which also sets `dso_local` in these cases:
`clang-12 -fno-PIC -S -emit-llvm test.c`
```C
extern int A;
pub fn a() -> &'static i32 {
&STATIC
}
pub fn b() -> &'static i32 {
unsafe {&EXT_STATIC}
}
```
`objdump test.o -r`
nightly-2021-02-20 (rustc target is `x86_64-linux-kernel`):
```
RELOCATION RECORDS FOR [.text._ZN4test1a17h1024ba65f3424175E]:
OFFSET TYPE VALUE 0000000000000007 R_X86_64_32S _ZN4test6STATIC17h3adc41a83746c9ffE
RELOCATION RECORDS FOR [.text._ZN4test1b17h86a6a80c1190ac8dE]:
OFFSET TYPE VALUE 0000000000000007 R_X86_64_32S EXT_STATIC
```
nightly-2021-05-10:
```
RELOCATION RECORDS FOR [.text._ZN4test1a17he846f03bf37b2d20E]:
OFFSET TYPE VALUE 0000000000000007 R_X86_64_GOTPCREL _ZN4test6STATIC17h5a059515bf3d4968E-0x0000000000000004
RELOCATION RECORDS FOR [.text._ZN4test1b17h7e0f7f80fbd91125E]:
OFFSET TYPE VALUE 0000000000000007 R_X86_64_GOTPCREL EXT_STATIC-0x0000000000000004
```
This PR:
```
RELOCATION RECORDS FOR [.text._ZN4test1a17he846f03bf37b2d20E]:
OFFSET TYPE VALUE 0000000000000007 R_X86_64_32S _ZN4test6STATIC17h5a059515bf3d4968E
RELOCATION RECORDS FOR [.text._ZN4test1b17h7e0f7f80fbd91125E]:
OFFSET TYPE VALUE 0000000000000007 R_X86_64_32S EXT_STATIC
```
Jack Huey [Wed, 19 May 2021 02:36:19 +0000 (22:36 -0400)]
Rollup merge of #85438 - GuillaumeGomez:fix-escape-handling, r=jsha
Fix escape handling
Currently, when we press Escape while on the search results, nothing is happening, this PR fixes it.
More information: it's because in case the element doesn't exist, `hasClass` will return `null`, which coerces into `false` with the `!` comparison operator. But even if it returned `false`, it would still be an issue because if the element doesn't exist, it means it's hidden so in this case it's just as good, hence the additional check I added.
Jack Huey [Wed, 19 May 2021 02:36:13 +0000 (22:36 -0400)]
Rollup merge of #85396 - jsha:top-doc-font-sizes, r=GuillaumeGomez
rustdoc: restore header sizes
The `<details>` toggle work changed the relationship from #main to the top-doc docblock so it was no longer a parent relationship but a great-grandparent relationship. This updates the CSS rules that set the heading sizes so they still apply.
Jack Huey [Wed, 19 May 2021 02:36:08 +0000 (22:36 -0400)]
Rollup merge of #85297 - infinity0:master, r=Mark-Simulacrum
bootstrap: build cargo only if requested in tools
In Debian we'd like to build rustfmt and clippy alongside rustc, but we're still excluding cargo from the rustc build and doing that separately. This patch makes that possible.
Jack Huey [Wed, 19 May 2021 02:36:04 +0000 (22:36 -0400)]
Rollup merge of #85274 - luqmana:linker-is-gnu-gc-sections, r=petrochenkov
Only pass --[no-]gc-sections if linker is GNU ld.
Fixes a regression from #84468 where linking now fails with solaris linkers. LinkerFlavor::Gcc does not always mean GNU ld specifically. And in the case of at least the solaris ld in illumos, that flag is unrecognized and will cause the linking step to fail.
Even though removing the `is_like_solaris` branch from `gc_sections` in #84468 made sense as `-z ignore/record` are more analogous to the `--[no-]-as-needed` flags, it inadvertently caused solaris linkers to be passed the `--gc-sections` flag. So let's just change it to be more explicit about when we pass those flags.
Jack Huey [Wed, 19 May 2021 02:35:59 +0000 (22:35 -0400)]
Rollup merge of #84883 - durin42:allow-unused-prefixes, r=nikic
compiletest: "fix" FileCheck with --allow-unused-prefixes
The default of --allow-unused-prefixes used to be false, but in LLVM
change 87dbdd2e3b (https://reviews.llvm.org/D95849) the default became
true. I'm not quite sure how we could do better here (specifically not
providing the CHECK prefix when it's not needed), but this seems to work
for now.
This reduces codegen test failures against LLVM HEAD from 31 cases to 5.
Jack Huey [Wed, 19 May 2021 02:35:54 +0000 (22:35 -0400)]
Rollup merge of #83366 - jyn514:stabilize-key-value-attrs, r=petrochenkov
Stabilize extended_key_value_attributes
Closes https://github.com/rust-lang/rust/issues/44732. Closes https://github.com/rust-lang/rust/issues/78835. Closes https://github.com/rust-lang/rust/issues/82768 (by making it irrelevant).
# Stabilization report
## Summary
This stabilizes using macro expansion in key-value attributes, like so:
#[path = concat!(env!("OUT_DIR"), "/generated.rs")]
mod m;
```
See Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455)
for alternatives that were considered and rejected ("why accept no more and no less?")
This has been available on nightly since 1.50 with no major issues.
## Notes
### Accepted syntax
The parser accepts arbitrary Rust expressions in this position, but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g., `#[doc]`). Note that decorators and the like may be able to observe other expression forms.
### Expansion ordering
Expansion of macro expressions in "inert" attributes occurs after decorators have executed, analogously to macro expressions appearing in the function body or other parts of decorator input.
There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion, that can work).
- Initial proposal: https://github.com/rust-lang/rust/issues/55414#issuecomment-554005412
- Experiment to see how much code it would break: https://github.com/rust-lang/rust/pull/67121
- Preliminary work to restrict expansion that would conflict with this
feature: https://github.com/rust-lang/rust/pull/77271
- Initial implementation: https://github.com/rust-lang/rust/pull/78837
- Fix for an ICE: https://github.com/rust-lang/rust/pull/80563
## Unresolved Questions
~~https://github.com/rust-lang/rust/pull/83366#issuecomment-805180738 listed some concerns, but they have been resolved as of this final report.~~
## Additional Information
There are two workarounds that have a similar effect for `#[doc]`
attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons:
forward_inner_docs!(include_str!("lib.rs") => struct S {});
```
This also works for other attributes (like `#[path = concat!(...)]`).
The other is to use `doc(include)`:
```rust
#![feature(external_doc)]
#[doc(include = "lib.rs")]
struct S {}
```
The first works, but is non-trivial for people to discover, and
difficult to read and maintain. The second is a strange special-case for
a particular use of the macro. This generalizes it to work for any use
case, not just including files.
I plan to remove `doc(include)` when this is stabilized
(https://github.com/rust-lang/rust/pull/82539). The `forward_inner_docs`
workaround will still compile without warnings, but I expect it to be
used less once it's no longer necessary.
the8472 [Sun, 16 May 2021 13:35:05 +0000 (15:35 +0200)]
from review: more robust test
This also checks the contents and not only the capacity in case IntoIter's clone implementation is changed to add capacity at the end. Extra capacity at the beginning would be needed to make InPlaceIterable work.
The8472 [Sat, 15 May 2021 18:08:09 +0000 (20:08 +0200)]
remove InPlaceIterable marker from Peekable due to unsoundness
The unsoundness is not in Peekable per se, it rather is due to the
interaction between Peekable being able to hold an extra item
and vec::IntoIter's clone implementation shortening the allocation.
An alternative solution would be to change IntoIter's clone implementation
to keep enough spare capacity available.
bors [Tue, 18 May 2021 20:50:01 +0000 (20:50 +0000)]
Auto merge of #84767 - scottmcm:try_trait_actual, r=lcnr
Implement the new desugaring from `try_trait_v2`
~~Currently blocked on https://github.com/rust-lang/rust/issues/84782, which has a PR in https://github.com/rust-lang/rust/pull/84811~~ Rebased atop that fix.
Unfortunately this is already touching a ton of things, so if you have suggestions for good ways to split it up, I'd be happy to hear them. (The combination between the use in the library, the compiler changes, the corresponding diagnostic differences, even MIR tests mean that I don't really have a great plan for it other than trying to have decently-readable commits.
r? `@ghost`
~~(This probably shouldn't go in during the last week before the fork anyway.)~~ Fork happened.
Alex Crichton [Mon, 3 May 2021 18:39:10 +0000 (11:39 -0700)]
std: Attempt again to inline thread-local-init across crates
Issue #25088 has been part of `thread_local!` for quite some time now.
Historical attempts have been made to add `#[inline]` to `__getit`
in #43931, #50252, and #59720, but these attempts ended up not landing
at the time due to segfaults on Windows.
In the interim though with `const`-initialized thread locals AFAIK this
is the only remaining bug which is why you might want to use
`#[thread_local]` over `thread_local!`. As a result I figured it was
time to resubmit this and see how it fares on CI and if I can help
debugging any issues that crop up.
bors [Tue, 18 May 2021 18:04:47 +0000 (18:04 +0000)]
Auto merge of #85443 - RalfJung:rollup-d9gd64t, r=RalfJung
Rollup of 7 pull requests
Successful merges:
- #84462 (rustdoc: use focus for search navigation)
- #85251 (Make `const_generics_defaults` not an incomplete feature)
- #85404 (Backport 1.52.1 release notes)
- #85407 (Improve display for "copy-path" button, making it more discreet)
- #85423 (Don't require cmake on Windows when LLVM isn't being built)
- #85428 (Add x.py pre-setup instructions)
- #85442 (fix typo)
Ralf Jung [Tue, 18 May 2021 17:35:47 +0000 (19:35 +0200)]
Rollup merge of #85428 - leebradley:add-xpy-presetup-instructions, r=Mark-Simulacrum
Add x.py pre-setup instructions
This change adds pre-setup instructions that outline how x.py requires
python to be setup and how to work around the problem of x.py failing to
locate python, especially now that Ubuntu 20.04's dropped default python
command is causing people to encounter this issue regularly.
Ralf Jung [Tue, 18 May 2021 17:35:35 +0000 (19:35 +0200)]
Rollup merge of #84462 - jsha:focus-search-results2, r=GuillaumeGomez
rustdoc: use focus for search navigation
Rather than keeping track of highlighted element inside the JS, take advantage of `.focus()` and the :focus CSS pseudo-class.
This required wrapping each row of results in one big `<a>` tag (because anchors can be focused, but table rows cannot). That in turn required moving from a table layout to a div layout with float.
This makes it so Ctrl+Enter opens links in new tabs, and using the arrow keys to navigate off the bottom of the page scrolls the rest of the page into view. It also simplifies the keyboard event handling. It eliminates the need for click handlers on the search results, and for tracking mouse movements.
This changes the UI treatment of mouse hovering. A hovered element now gets a light grey background, but does not change the focus. It's possible to have two highlighted search results: one that is focused (via keyboard) and one that is hovered (via mouse). Pressing enter will activate the focused link; clicking will activate the hovered link. This matches up with how Firefox and Chrome handle suggestions in their URL bar, and avoids stray mouse movements changing the focus.
Selecting tabs is now done with left/right arrows while any search result is focused. The visibility of results on each search tab is
controlled with the "active" class, rather than by setting display: none directly. Note that the old code kept track of highlighted search element when tabbing back and forth. The new code doesn't.
Demo at https://hoffman-andrews.com/rust/focus-search-results2/std/?search=fn
Ralf Jung [Sun, 16 May 2021 16:53:20 +0000 (18:53 +0200)]
CTFE core engine allocation & memory API improvemenets
- make Allocation API offset-based (no more Pointer)
- make Memory API higher-level (combine checking for access and getting access into one operation)
bors [Tue, 18 May 2021 14:48:53 +0000 (14:48 +0000)]
Auto merge of #85437 - GuillaumeGomez:rollup-3jcirty, r=GuillaumeGomez
Rollup of 7 pull requests
Successful merges:
- #84587 (rustdoc: Make "rust code block is empty" and "could not parse code block" warnings a lint (`INVALID_RUST_CODEBLOCKS`))
- #85280 (Toggle-wrap items differently than top-doc.)
- #85338 (Implement more Iterator methods on core::iter::Repeat)
- #85339 (Report an error if a lang item has the wrong number of generic arguments)
- #85369 (Suggest borrowing if a trait implementation is found for &/&mut <type>)
- #85393 (Suppress spurious errors inside `async fn`)
- #85415 (Clean up remnants of BorrowOfPackedField)
Guillaume Gomez [Tue, 18 May 2021 12:08:55 +0000 (14:08 +0200)]
Rollup merge of #85369 - FabianWolff:issue-84973, r=jackh726
Suggest borrowing if a trait implementation is found for &/&mut <type>
This pull request fixes #84973 by suggesting to borrow if a trait is not implemented for some type `T`, but it is for `&T` or `&mut T`. For instance:
```rust
trait Ti {}
impl<T> Ti for &T {}
fn foo<T: Ti>(_: T) {}
trait Tm {}
impl<T> Tm for &mut T {}
fn bar<T: Tm>(_: T) {}
fn main() {
let a: i32 = 5;
foo(a);
let b: Box<i32> = Box::new(42);
bar(b);
}
```
gives, on current nightly:
```
error[E0277]: the trait bound `i32: Ti` is not satisfied
--> t2.rs:11:9
|
3 | fn foo<T: Ti>(_: T) {}
| -- required by this bound in `foo`
...
11 | foo(a);
| ^ the trait `Ti` is not implemented for `i32`
error[E0277]: the trait bound `Box<i32>: Tm` is not satisfied
--> t2.rs:14:9
|
7 | fn bar<T: Tm>(_: T) {}
| -- required by this bound in `bar`
...
14 | bar(b);
| ^ the trait `Tm` is not implemented for `Box<i32>`
error: aborting due to 2 previous errors
```
whereas with my changes, I get:
```
error[E0277]: the trait bound `i32: Ti` is not satisfied
--> t2.rs:11:9
|
3 | fn foo<T: Ti>(_: T) {}
| -- required by this bound in `foo`
...
11 | foo(a);
| ^
| |
| expected an implementor of trait `Ti`
| help: consider borrowing here: `&a`
error[E0277]: the trait bound `Box<i32>: Tm` is not satisfied
--> t2.rs:14:9
|
7 | fn bar<T: Tm>(_: T) {}
| -- required by this bound in `bar`
...
14 | bar(b);
| ^
| |
| expected an implementor of trait `Tm`
| help: consider borrowing mutably here: `&mut b`
error: aborting due to 2 previous errors
```
In my implementation, I have added a "blacklist" to make these suggestions flexible. In particular, suggesting to borrow can interfere with other suggestions, such as to add another trait bound to a generic argument. I have tried to configure this blacklist to cause the least amount of test case failures, i.e. to model the current behavior as closely as possible (I only had to change one existing test case, and this change was quite clearly an improvement).
Guillaume Gomez [Tue, 18 May 2021 12:08:51 +0000 (14:08 +0200)]
Rollup merge of #85339 - FabianWolff:issue-83893, r=varkor
Report an error if a lang item has the wrong number of generic arguments
This pull request fixes #83893. The issue is that the lang item code currently checks whether the lang item has the correct item kind (e.g. a `#[lang="add"]` has to be a trait), but not whether the item has the correct number of generic arguments.
This can lead to an "index out of bounds" ICE when the compiler tries to create more substitutions than there are suitable types available (if the lang item was declared with too many generic arguments).
For instance, here is a reduced ("reduced" in the sense that it does not trigger additional errors) version of the example given in #83893:
```rust
#![feature(lang_items,no_core)]
#![no_core]
#![crate_type="lib"]
#[lang = "sized"]
trait MySized {}
#[lang = "add"]
trait MyAdd<'a, T> {}
fn ice() {
let r = 5;
let a = 6;
r + a
}
```
On current nightly, this immediately causes an ICE without any warnings or errors emitted. With the changes in this PR, however, I get no ICE and two errors:
```
error[E0718]: `add` language item must be applied to a trait with 1 generic argument
--> pr-ex.rs:8:1
|
8 | #[lang = "add"]
| ^^^^^^^^^^^^^^^
9 | trait MyAdd<'a, T> {}
| ------- this trait has 2 generic arguments, not 1
error[E0369]: cannot add `{integer}` to `{integer}`
--> pr-ex.rs:14:7
|
14 | r + a
| - ^ - {integer}
| |
| {integer}
error: aborting due to 2 previous errors
Some errors have detailed explanations: E0369, E0718.
For more information about an error, try `rustc --explain E0369`.
```
Guillaume Gomez [Tue, 18 May 2021 12:08:46 +0000 (14:08 +0200)]
Rollup merge of #85338 - lopopolo:core-iter-repeat-gh-81292, r=joshtriplett
Implement more Iterator methods on core::iter::Repeat
`core::iter::Repeat` always returns the same element, which means we can
do better than implementing most `Iterator` methods in terms of
`Iterator::next`.
Fixes #81292.
#81292 raises the question of whether these changes violate the contract of `core::iter::Repeat`, but as far as I can tell `core::iter::repeat` doesn't make any guarantees around how it calls `Clone::clone`.
Guillaume Gomez [Tue, 18 May 2021 12:08:42 +0000 (14:08 +0200)]
Rollup merge of #85280 - jsha:move-trait-toggles, r=GuillaumeGomez
Toggle-wrap items differently than top-doc.
This makes sure things like trait methods get wrapped at the
`<h3><code>` level rather than at the `.docblock` level. Also it ensures
that only the actual top documentation gets the `.top-doc` class.
Guillaume Gomez [Tue, 18 May 2021 12:08:41 +0000 (14:08 +0200)]
Rollup merge of #84587 - jyn514:rustdoc-lint-block, r=CraftSpider
rustdoc: Make "rust code block is empty" and "could not parse code block" warnings a lint (`INVALID_RUST_CODEBLOCKS`)
Fixes https://github.com/rust-lang/rust/issues/79792. This already went through FCP in https://github.com/rust-lang/rust/pull/79816, so it only needs final review.
This is mostly a rebase of https://github.com/rust-lang/rust/pull/79816 - thank you ``@poliorcetics`` for doing most of the work!