Skip to content

Rollup of 9 pull requests - #98480

Closed
Dylan-DPC wants to merge 34 commits into
rust-lang:masterfrom
Dylan-DPC:rollup-gocmstk
Closed

Rollup of 9 pull requests#98480
Dylan-DPC wants to merge 34 commits into
rust-lang:masterfrom
Dylan-DPC:rollup-gocmstk

Conversation

@Dylan-DPC

Copy link
Copy Markdown
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

ChrisDentonand others added 30 commits April 26, 2022 00:13
This will allow better strategies for use of memory and File handles. However, fully taking advantage of that is left to future work.
It's possible that a file in the directory is pending deletion. In that case we might succeed after a few attempts.
rust-lang#91318 introduced a trait for infallible folders distinct from the fallible version. For some reason (completely unfathomable to me now that I look at it with fresh eyes), the infallible trait was a supertrait of the fallible one: that is, all fallible folders were required to also be infallible. Moreover the `Error` associated type was defined on the infallible trait! It's so absurd that it has me questioning whether I was entirely sane.
This trait reverses the hierarchy, so that the fallible trait is a supertrait of the infallible one: all infallible folders are required to also be fallible (which is a trivial blanket implementation). This of course makes much more sense! It also enables the `Error` associated type to sit on the fallible trait, where it sensibly belongs.
There is one downside however: folders expose a `tcx` accessor method. Since the blanket fallible implementation for infallible folders only has access to a generic `F: TypeFolder`, we need that trait to expose such an accessor to which we can delegate. Alternatively it's possible to extract that accessor into a separate `HasTcx` trait (or similar) that would then be a supertrait of both the fallible and infallible folder traits: this would ensure that there's only one unambiguous `tcx` method, at the cost of a little additional boilerplate. If desired, I can submit that as a separate PR.
r? @jackh726
Co-authored-by: Wesley Wiser <wwiser@gmail.com>
Windows: Iterative `remove_dir_all`
This will allow better strategies for use of memory and File handles. However, fully taking advantage of that is left to future work.
Note to reviewer: It's probably best to view the `remove_dir_all_recursive` as a new function. The diff is not very helpful (imho).
Add a test for issue rust-lang#33172
Adds a test confirming that rust-lang#33172 has been fixed.
CDB has some surprising results as it looks like the supposedly unmangled static's symbol name is prefixed when it shouldn't be.
r? ```@wesleywiser```
Closesrust-lang#33172
Pull Derefer before ElaborateDrops
_Follow up work to rust-lang#97025rust-lang#96549rust-lang#96116rust-lang#95887 #95649_
This moves `Derefer` before `ElaborateDrops` and creates a new `Rvalue` called `VirtualRef` that allows us to bypass many constraints for `DerefTemp`.
r? ``@oli-obk``
…nkov
Set relocation_model to Pic on emscripten target
So we can support dynamically linking libraries with Emscripten (otherwise we need to use nightly and `-Zbuild-std` to rebuild std with relocations).
```@sbc100```
…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.
…notriddle
Transform help popup into a pocket menu
Just like we moved the settings menu into a "pocket menu", it's doing the same to the help popup.
You can test it [here](https://rustdoc.crud.net/imperio/help-pocket-menu/doc/foo/index.html) and here is a screenshot:
![Screenshot from 2022-06-20 20-58-29](https://user-images.githubusercontent.com/3050060/174663718-538e9d11-3bf9-48b2-8909-f9bfe75af135.png)
r? ```@jsha```
…jackh726
Reverse folder hierarchy
rust-lang#91318 introduced a trait for infallible folders distinct from the fallible version. For some reason (completely unfathomable to me now that I look at it with fresh eyes), the infallible trait was a supertrait of the fallible one: that is, all fallible folders were required to also be infallible. Moreover the `Error` associated type was defined on the infallible trait! It's so absurd that it has me questioning whether I was entirely sane.
This trait reverses the hierarchy, so that the fallible trait is a supertrait of the infallible one: all infallible folders are required to also be fallible (which is a trivial blanket implementation). This of course makes much more sense! It also enables the `Error` associated type to sit on the fallible trait, where it sensibly belongs.
There is one downside however: folders expose a `tcx` accessor method. Since the blanket fallible implementation for infallible folders only has access to a generic `F: TypeFolder`, we need that trait to expose such an accessor to which we can delegate. Alternatively it's possible to extract that accessor into a separate `HasTcx` trait (or similar) that would then be a supertrait of both the fallible and infallible folder traits: this would ensure that there's only one unambiguous `tcx` method, at the cost of a little additional boilerplate. If desired, I can submit that as a separate PR.
r? ``@jackh726``
…ing, r=oli-obk
Fix printing `impl trait` under binders
Before, we would render `impl for<'a> Trait<'a>` like `impl Trait<for<'a> 'a>`, lol.
…nant-cast, r=lcnr
Use correct substs in enum discriminant cast
Fixesrust-lang#97634
r? ``@lcnr``
@rustbotrustbot added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library 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 25, 2022
@Dylan-DPC

Copy link
Copy Markdown
MemberAuthor

@bors r+ rollup=never p=5

@bors

bors commented Jun 25, 2022

Copy link
Copy Markdown
Collaborator

📌 Commit a80dffb 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 25, 2022
@Dylan-DPC

Copy link
Copy Markdown
MemberAuthor

@bors retry

@bors

bors commented Jun 25, 2022

Copy link
Copy Markdown
Collaborator

⌛ Testing commit a80dffb with merge 3c0b4645b095f09b5a8a5e80c31270d702951bf6...

@rust-log-analyzer

Copy link
Copy Markdown
Collaborator

The job x86_64-gnu-distcheck failed! Check out the build log: (web)(plain)

Click to see the possible cause of the failure (guessed by this bot)
test [debuginfo-gdb] src/test/debuginfo/cross-crate-type-uniquing.rs ... ok
failures:
---- [debuginfo-gdb] src/test/debuginfo/no_mangle-info.rs stdout ----
NOTE: compiletest thinks it is using GDB without native rust support
NOTE: compiletest thinks it is using GDB version 7011001
error: line not found in debugger output: $2 = 42
status: exit status: 0
status: exit status: 0
command: "/usr/bin/gdb" "-quiet" "-batch" "-nx" "-command=/checkout/obj/build/tmp/distcheck/build/x86_64-unknown-linux-gnu/test/debuginfo/no_mangle-info.gdb/no_mangle-info.debugger.script"
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
Breakpoint 1 at 0xbbd: file src/test/debuginfo/no_mangle-info.rs, line 38.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, no_mangle_info::main::hb3b9c5efc50504a9 () at src/test/debuginfo/no_mangle-info.rs:38
38 println!("OTHER TEST: {}", namespace::OTHER_TEST); // #break
------------------------------------------
--- stderr -------------------------------
--- stderr -------------------------------
/checkout/obj/build/tmp/distcheck/build/x86_64-unknown-linux-gnu/test/debuginfo/no_mangle-info.gdb/no_mangle-info.debugger.script:11: Error in sourced command file:
No type "namespace" within class or namespace "no_mangle_info".
failures:
failures:
[debuginfo-gdb] src/test/debuginfo/no_mangle-info.rs
test result: FAILED. 85 passed; 1 failed; 54 ignored; 0 measured; 0 filtered out; finished in 4.48s
Build completed unsuccessfully in 0:18:18
make: *** [check] Error 1
Makefile:42: recipe for target 'check' failed

@bors

bors commented Jun 25, 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 25, 2022
@JohnTitor

Copy link
Copy Markdown
Member

Failed by #97085, closing.

@Dylan-DPC
Dylan-DPC deleted the rollup-gocmstk branch June 25, 2022 09:53
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-libsRelevant to the library 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@JohnTitor@rustbot@ChrisDenton@rylev@eggyal@ouz-a@GuillaumeGomez@b-naber@hoodmane@compiler-errors