Skip to content

Rollup of 8 pull requests - #98381

Closed
Dylan-DPC wants to merge 24 commits into
rust-lang:masterfrom
Dylan-DPC:rollup-38bx55j
Closed

Rollup of 8 pull requests#98381
Dylan-DPC wants to merge 24 commits into
rust-lang:masterfrom
Dylan-DPC:rollup-38bx55j

Conversation

@Dylan-DPC

Copy link
Copy Markdown
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

compiler-errorsand others added 24 commits June 19, 2022 20:49
The source sidebar has a setting to remember whether it should be open or
closed. Previously, this setting was handled in source-script.js, which
is loaded with `defer`, meaning it is often run after the document is rendered.
Since CSS renders the source sidebar as closed by default, changing this
after the initial render results in a relayout.
Instead, handle the setting in storage.js, which is the first script to load
and is the only script that blocks render. This avoids a relayout and means
navigating between files with the sidebar open is faster.
…=jsha
Add macro support in jump to definition feature
Fixesrust-lang#91174.
To do so, I check if the span comes from an expansion, and if so, I infer the original macro `DefId` or `Span` depending if it's a defined in the current crate or not.
There is one limitation due to macro expansion though:
```rust
macro_rules! yolo { () => {}}
fn foo() {
yolo!();
}
```
In `foo`, `yolo!` won't be linked because after expansion, it is replaced by nothing (which seems logical). So I can't get an item from the `Visitor` from which I could tell if its `Span` comes from an expansion.
I added a test for this specific limitation alongside others.
Demo: https://rustdoc.crud.net/imperio/macro-jump-to-def/src/foo/check-source-code-urls-to-def-std.rs.html
As for the empty macro issue that cannot create a jump to definition, you can see it [here](https://rustdoc.crud.net/imperio/macro-jump-to-def/src/foo/check-source-code-urls-to-def-std.rs.html#35).
r? `@jyn514`
…impl-nll, r=cjgillot
Give name if anonymous region appears in impl signature
Fixesrust-lang#98170
We probably should remove the two unwraps in [`report_general_error`](https://doc.rust-lang.org/nightly/nightly-rustc/src/rustc_borrowck/diagnostics/region_errors.rs.html#683-685), but I have no idea what to provide if those regions are missing, so I've kept those in. Let me know if I should try harder to remove those.
…t-res, r=petrochenkov
Provide a `PathSegment.res` in more cases
I find that in many cases, the `res` associated with a `PathSegment` is `Res::Err` even though the path was fully resolved. A few diagnostics use this `res` and their error messages suffer because of the lack of resolved segment.
This fixes it a bit, but it's obviously not complete and I'm not exactly sure if it's correct.
…bank
Fix trait object reborrow suggestion
Fixesrust-lang#93596
Slightly generalizes the logic we use to suggest fix first implemented in rust-lang#95609, specifically when we have a `Sized` obligation that comes from a struct's unsized tail.
…struct-literal, r=compiler-errors
Point at private fields in struct literal
closesrust-lang#95872
prohibit_generics: don't alloc error string if no error emitted
Noticed unreaded allocs in DHAT.
…umeGomez
rustdoc: optimize loading of source sidebar
The source sidebar has a setting to remember whether it should be open or
closed. Previously, this setting was handled in source-script.js, which
is loaded with `defer`, meaning it is often run after the document is rendered.
Since CSS renders the source sidebar as closed by default, changing this
after the initial render results in a relayout.
Instead, handle the setting in storage.js, which is the first script to load
and is the only script that blocks render. This avoids a relayout and means
navigating between files with the sidebar open is faster.
Demo: https://rustdoc.crud.net/jsha/defer-source-sidebar/src/alloc/ffi/c_str.rs.html
r? `@GuillaumeGomez`
[RFC 2011] Optimize non-consuming operators
Tracking issue: rust-lang#44838
Fifth step of rust-lang#96496
The most non-invasive approach that will probably have very little to no performance impact.
## Current behaviour
Captures are handled "on-the-fly", i.e., they are performed in the same place expressions are located.
```rust
// `let a = 1; let b = 2; assert!(a > 1 && b < 100);`
if !(
{ ***try capture `a` and then return `a`*** } > 1 && { ***try capture `b` and then return `b`*** } < 100
) {
panic!( ... );
}
```
As such, some overhead is likely to occur (Specially with very large chains of conditions).
## New behaviour for non-consuming operators
When an operator is known to not take `self`, then it is possible to capture variables **AFTER** the condition.
```rust
// `let a = 1; let b = 2; assert!(a > 1 && b < 100);`
if !( a > 1 && b < 100 ) {
{ ***try capture `a`*** }
{ ***try capture `b`*** }
panic!( ... );
}
```
So the possible impact on the runtime execution time will be diminished.
r? `@oli-obk`
@rustbotrustbot added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Jun 22, 2022
@Dylan-DPC

Copy link
Copy Markdown
MemberAuthor

@bors r+ rollup=never p=5

@bors

bors commented Jun 22, 2022

Copy link
Copy Markdown
Collaborator

📌 Commit 77732a5 has been approved by Dylan-DPC

@borsbors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Jun 22, 2022
@borsbors added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 23, 2022
@rust-log-analyzer

Copy link
Copy Markdown
Collaborator

A job failed! Check out the build log: (web)(plain)

Click to see the possible cause of the failure (guessed by this bot)

@lqd

lqd commented Jun 23, 2022

Copy link
Copy Markdown
Member

a try build has succeeded a short while ago, so let's see if this has been fixed altogether

@bors retry

@borsbors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 23, 2022
@bors

bors commented Jun 23, 2022

Copy link
Copy Markdown
Collaborator

⌛ Testing commit 77732a5 with merge e9da05ce4354c8edec674393626a6396149fa657...

@rust-log-analyzer

Copy link
Copy Markdown
Collaborator

A job failed! Check out the build log: (web)(plain)

Click to see the possible cause of the failure (guessed by this bot)

@bors

bors commented Jun 23, 2022

Copy link
Copy Markdown
Collaborator

💔 Test failed - checks-actions

@borsbors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jun 23, 2022
@JohnTitor

Copy link
Copy Markdown
Member

Closing as outdated.

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

rollupA PR which is a rollupS-waiting-on-reviewStatus: Awaiting review from the assignee but also interested parties.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.T-rustdocRelevant to the rustdoc team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

13 participants

@Dylan-DPC@bors@rust-log-analyzer@lqd@m-ou-se@compiler-errors@JohnTitor@rustbot@TaKO8Ki@GuillaumeGomez@klensy@jsha@c410-f3r