Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of 15 pull requests #91941

Closed
wants to merge 33 commits into from

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

tmiasko and others added 30 commits December 13, 2021 00:00
The resulting profile will include the crate name and will be stored in
the `--out-dir` directory.

This implementation makes it convenient to use LLVM time trace together
with cargo, in the contrast to the previous implementation which would
overwrite profiles or store them in `.cargo/registry/..`.
This avoids a needless query invocation
…i-obk

Recover on invalid operators `<>` and `<=>`

Thanks to rust-lang#89871 for showing me how to do this.
Next, I think it'd be nice to recover on `<=>` too, like rust-lang#89871 intended, if this even works.
Iterator::cycle() — document empty iterator special case
Use `OutputFilenames` to generate output file for `-Zllvm-time-trace`

The resulting profile will include the crate name and will be stored in
the `--out-dir` directory.

This implementation makes it convenient to use LLVM time trace together
with cargo, in the contrast to the previous implementation which would
overwrite profiles or store them in `.cargo/registry/..`.
…wiser

Remove `in_band_lifetimes` from `rustc_borrowck`

See rust-lang#91867 for more information.
…times-from-rustc-typeck, r=jackh726

Remove `in_band_lifetimes` from `rustc_typeck`

Joining in on the effort to remove the `in_band_lifetimes` features, as described in issue rust-lang#91867.
Handle unordered const/ty generics for object lifetime defaults

*feel like I should have a PR description but cant think of what to put here*

r? `@lcnr`
…stc_symbol_mangling, r=jackh726

Remove `in_band_lifetimes` from `rustc_symbol_mangling`

Helping out with  rust-lang#91867
…stc_trait_selection, r=petrochenkov

Remove `in_band_lifetimes` from `rustc_trait_selection`

Another one for rust-lang#91867
…es_library_proc_macro, r=petrochenkov

Removed `in_band_lifetimes` from `library\proc_macro`

Issue [rust-lang#91867](rust-lang#91867)

This is my first try, I followed the instructions given. Fixed all the errors that were thrown while compiling.
Compiled with stage 0,1, and 2 all of them compiled successfully.
…crum

Add another regression test for unnormalized fn args with Self

Closes rust-lang#91899
Fix a bunch of typos

I hope that none of these files is not supposed to be modified.

FYI, I opened separate PRs for typos in submodules, in the respective repositories
* rust-lang/stdarch#1267
* rust-lang/backtrace-rs#455
…-constification-begins, r=oli-obk

Constify `bool::then{,_some}`

Note on `~const Drop`: it has no effect when called from runtime functions, when called from const contexts, the trait system ensures that the type can be dropped in const contexts.
Use `tcx.def_path_hash` in `ExistentialPredicate.stable_cmp`

This avoids a needless query invocation
…_llvm, r=davidtwco

Remove `in_band_lifetimes` from `rustc_codegen_llvm`

See rust-lang#91867 for more information.

This one took a while. This crate has dozens of functions not associated with any type, and most of them were using in-band lifetimes for `'ll` and `'tcx`.
@rustbot rustbot added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Dec 14, 2021
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=15

@bors
Copy link
Contributor

bors commented Dec 14, 2021

📌 Commit 71b2c82 has been approved by matthiaskrgr

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Dec 14, 2021
@camelid
Copy link
Member

camelid commented Dec 14, 2021

Hmm, I'm not sure if it's such a good idea to roll up so many of the in_band_lifetimes PRs together. IIUC, the changes could accidentally introduce the wrong lifetimes, which would make bisecting harder.

@matthiaskrgr
Copy link
Member Author

Ah, in theory this could have max-rss changes then, right? Didn't think of that...

@camelid
Copy link
Member

camelid commented Dec 14, 2021

I'm not sure; it could be fine, but it may not. 🤷

@matthiaskrgr
Copy link
Member Author

Should we do a perf-run on the rollup? 🙃

@camelid
Copy link
Member

camelid commented Dec 14, 2021

Well sometimes different perf changes can cancel out. Your choice :)

@matthiaskrgr
Copy link
Member Author

MMh ok, I'll try to split then up a bit among different rollup..

@matthiaskrgr matthiaskrgr deleted the rollup-7xyta31 branch January 2, 2022 22:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.