bors [Sun, 4 Dec 2022 22:46:11 +0000 (22:46 +0000)]
Auto merge of #105094 - Swatinem:generator-not-future, r=compiler-errors
Make sure async constructs do not `impl Generator`
Async lowering turns async functions and blocks into generators internally.
Though these special kinds of generators should not `impl Generator` themselves.
The other way around, normal generators should not `impl Future`.
This was discovered in https://github.com/rust-lang/rust/pull/105082#issuecomment-1332210907 and is a regression from https://github.com/rust-lang/rust/pull/104321.
bors [Sun, 4 Dec 2022 20:05:32 +0000 (20:05 +0000)]
Auto merge of #104535 - mikebenfield:discr-fix, r=pnkfelix
rustc_codegen_ssa: Fix for codegen_get_discr
When doing the optimized implementation of getting the discriminant, the arithmetic needs to be done in the tag type so wrapping behavior works correctly.
bors [Sun, 4 Dec 2022 16:32:21 +0000 (16:32 +0000)]
Auto merge of #105261 - matthiaskrgr:rollup-9ghhc9c, r=matthiaskrgr
Rollup of 6 pull requests
Successful merges:
- #101975 (Suggest to use . instead of :: when accessing a method of an object)
- #105141 (Fix ICE on invalid variable declarations in macro calls)
- #105224 (Properly substitute inherent associated types.)
- #105236 (Add regression test for #47814)
- #105247 (Use parent function WfCheckingContext to check RPITIT.)
- #105253 (Update a couple of rustbuild deps)
Matthias Krüger [Sun, 4 Dec 2022 15:25:34 +0000 (16:25 +0100)]
Rollup merge of #105253 - bjorn3:update_rustbuild_deps, r=jyn514
Update a couple of rustbuild deps
These mostly remove some dependency edges potentially making compilation of rustbuild itself a tiny bit faster. I hoped to be able to completely remove some dependencies, but other than replacing ansi_term with yansi all dependencies are still used.
bors [Sun, 4 Dec 2022 14:03:12 +0000 (14:03 +0000)]
Auto merge of #103293 - est31:untwist_and_drop_order, r=nagisa
Remove drop order twist of && and || and make them associative
Previously a short circuiting binop chain (chain of && or ||s) would drop the temporaries created by the first element after all the other elements, and otherwise follow evaluation order. So `f(1).g() && f(2).g() && f(3).g() && f(4).g()` would drop the temporaries in the order `2,3,4,1`. This made `&&` and `||` non-associative regarding drop order. In other words, adding ()'s to the expression would change drop order: `f(1).g() && (f(2).g() && f(3).g()) && f(4).g()` for example would drop in the order `3,2,4,1`.
As, except for the bool result, there is no data returned by the sub-expressions of the short circuiting binops, we can safely discard of any temporaries created by the sub-expr. Previously, code was already putting the rhs's into terminating scopes, but missed it for the lhs's.
This commit addresses this "twist". We now also put the lhs into a terminating scope. The drop order of the above expressions becomes `1,2,3,4`.
There might be code relying on the current order, and therefore I'd recommend doing a crater run to gauge the impact. I'd argue that such code is already quite wonky as it is one `foo() &&` addition away from breaking. ~~For the impact, I don't expect any *build* failures, as the compiler gets strictly more tolerant: shortening the lifetime of temporaries only expands the list of programs the compiler accepts as valid. There might be *runtime* failures caused by this change however.~~ Edit: both build and runtime failures are possible, e.g. see the example provided by dtolnay [below](https://github.com/rust-lang/rust/pull/103293#issuecomment-1285341113). Edit2: the crater run has finished and [results](https://github.com/rust-lang/rust/pull/103293#issuecomment-1292275203) are that there is only one build failure which is easy to fix with a +/- 1 line diff.
I've included a testcase that now compiles thanks to this patch.
The breakage is also limited to drop order relative to conditionals in the && chain: that is, in code like this:
```Rust
let hello = foo().hi() && bar().world();
println!("hi");
```
we already drop the temporaries of `foo().hi()` before we reach "hi".
I'd ideally have this PR merged before let chains are stabilized. If this PR is taking too long, I'd love to have a more restricted version of this change limited to `&&`'s in let chains: the `&&`'s of such chains are quite special anyways as they accept `let` bindings, in there the `&&` is therefore more a part of the "if let chain" construct than a construct of its own.
Fixes #103107
Status: waiting on [this accepted FCP](https://github.com/rust-lang/rust/pull/103293#issuecomment-1293411354) finishing.
Matthias Krüger [Sun, 4 Dec 2022 10:38:51 +0000 (11:38 +0100)]
Rollup merge of #105123 - BlackHoleFox:fixing-the-macos-deployment, r=oli-obk
Fix passing MACOSX_DEPLOYMENT_TARGET to the linker
I messed up in https://github.com/rust-lang/rust/pull/103929 when merging the two base files together and as a result, started ignoring `MACOSX_DEPLOYMENT_TARGET` at the linker level. This ended up being the cause of nighty builds not running on older macOS versions.
My original hope with the previous PR was that CI would have caught something like that but there were only tests checking the compiler target definitions in codegen tests. Because of how badly this sucks to break, I put together a new test via `run-make` that actually confirms the deployment target set makes it to the linker instead of just LLVM.
Closes https://github.com/rust-lang/rust/issues/104570 (for real this time)
est31 [Sat, 3 Dec 2022 23:21:19 +0000 (00:21 +0100)]
Also avoid creating a terminating scope in mixed chains
This avoids creation of a terminating scope in
chains that contain both && and ||, because
also there we know that a terminating scope is
not neccessary: all the chain members are already
in such terminating scopes.
est31 [Thu, 20 Oct 2022 07:50:32 +0000 (09:50 +0200)]
Remove drop order twist of && and || and make them associative
Previously a short circuiting && chain would drop the
first element after all the other elements, and otherwise
follow evaluation order, so code like:
f(1).g() && f(2).g() && f(3).g() && f(4).g()
would drop the temporaries in the order 2,3,4,1. This made
&& and || non-associative regarding drop order, so
adding ()'s to the expression would change drop order:
f(1).g() && (f(2).g() && f(3).g()) && f(4).g()
for example would drop in the order 3,2,4,1.
As, except for the bool result, there is no data returned
by the sub-expressions of the short circuiting binops,
we can safely discard of any temporaries created by the
sub-expr. Previously, code was already putting the rhs's
into terminating scopes, but missed it for the lhs's.
This commit addresses this "twist". In the expression,
we now also put the lhs into a terminating scope.
The drop order for the above expressions is 1,2,3,4
now.
bors [Sat, 3 Dec 2022 21:25:45 +0000 (21:25 +0000)]
Auto merge of #105218 - matthiaskrgr:rollup-8d3k08n, r=matthiaskrgr
Rollup of 9 pull requests
Successful merges:
- #104199 (Keep track of the start of the argument block of a closure)
- #105050 (Remove useless borrows and derefs)
- #105153 (Create a hacky fail-fast mode that stops tests at the first failure)
- #105164 (Restore `use` suggestion for `dyn` method call requiring `Sized`)
- #105193 (Disable coverage instrumentation for naked functions)
- #105200 (Remove useless filter in unused extern crate check.)
- #105201 (Do not call fn_sig on non-functions.)
- #105208 (Add AmbiguityError for inconsistent resolution for an import)
- #105214 (update Miri)
Matthias Krüger [Sat, 3 Dec 2022 16:37:43 +0000 (17:37 +0100)]
Rollup merge of #105164 - compiler-errors:revert-import-filter, r=estebank
Restore `use` suggestion for `dyn` method call requiring `Sized`
Add the suggestion back that I accidentally removed in 88f2140d8736329610a4c0bd8000e164c9170537 because I didn't understand that suggestion was actually useful...
Matthias Krüger [Sat, 3 Dec 2022 16:37:41 +0000 (17:37 +0100)]
Rollup merge of #104199 - SarthakSingh31:issue-97417-1, r=cjgillot
Keep track of the start of the argument block of a closure
This removes a call to `tcx.sess.source_map()` from [compiler/rustc_trait_selection/src/traits/error_reporting/mod.rs](https://github.com/rust-lang/rust/compare/master...SarthakSingh31:issue-97417-1?expand=1#diff-8406bbc0d0b43d84c91b1933305df896ecdba0d1f9269e6744f13d87a2ab268a) as required by #97417.
VsCode automatically applied `rustfmt` to the files I edited under `src/tools`. I can undo that if its a problem.
Yutaro Ohno [Sat, 3 Dec 2022 14:37:23 +0000 (23:37 +0900)]
parser: refactoring on recovery from invalid variable declarations
Previously, the `recover_local_after_let` function was called from the
body of the `recover_stmt_local` function. Unifying these two functions
make it more simple and more readable.
bors [Sat, 3 Dec 2022 05:24:35 +0000 (05:24 +0000)]
Auto merge of #105196 - JohnTitor:rollup-8rxqnq6, r=JohnTitor
Rollup of 7 pull requests
Successful merges:
- #104903 (Use ocx.normalize in report_projection_error)
- #105032 (improve doc of into_boxed_slice and impl From<Vec<T>> for Box<[T]>)
- #105100 (Add missing intra-doc link)
- #105181 (Don't add a note for implementing a trait if its inner type is erroneous)
- #105182 (Rustdoc-Json: Don't inline foreign traits)
- #105188 (Don't elide type information when printing E0308 with `-Zverbose`)
- #105189 (rustdoc: clean up redundant CSS on `.rustdoc-toggle.hideme`)
Yuki Okushi [Sat, 3 Dec 2022 03:51:29 +0000 (12:51 +0900)]
Rollup merge of #105182 - aDotInTheVoid:rdj-no-foreign-traits, r=Enselic,GuillaumeGomez
Rustdoc-Json: Don't inline foreign traits
It wasn't done correctly, and [we want to move towards only having local items in the index, and making foreign items easier to resolved](https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/Rustdoc.20JSON.3A.20Include.20All.20Foreign.20Items.3F)
Fixes #105025. This means #105015 is included to test this
bors [Sat, 3 Dec 2022 02:12:48 +0000 (02:12 +0000)]
Auto merge of #105073 - weihanglo:update-cargo, r=weihanglo
Update cargo
9 commits in e027c4b5d25af2119b1956fac42863b9b3242744..f6e737b1e3386adb89333bf06a01f68a91ac5306
2022-11-25 19:44:46 +0000 to 2022-12-02 20:21:24 +0000
- Refactor generate_targets into separate module (https://github.com/rust-lang/cargo/pull/11445)
- Improve file found in multiple build targets warning (https://github.com/rust-lang/cargo/pull/11299)
- Error when precise without -p flag (https://github.com/rust-lang/cargo/pull/11349)
- Improve strategy for selecting targets to be scraped for examples (https://github.com/rust-lang/cargo/pull/11430)
- Aware of compression ratio for unpack size limit (https://github.com/rust-lang/cargo/pull/11337)
- Add test for rustdoc-map generation when using sparse registries (https://github.com/rust-lang/cargo/pull/11403)
- Add error message when `cargo fix` on an empty repo (https://github.com/rust-lang/cargo/pull/11400)
- Store the sparse+ prefix in the SourceId for sparse registries (https://github.com/rust-lang/cargo/pull/11387)
- Update documentation for -Zrustdoc-scrape-examples in the Cargo Book (https://github.com/rust-lang/cargo/pull/11425)
Weihang Lo [Sat, 3 Dec 2022 01:10:54 +0000 (01:10 +0000)]
Update cargo
9 commits in e027c4b5d25af2119b1956fac42863b9b3242744..f6e737b1e3386adb89333bf06a01f68a91ac5306
2022-11-25 19:44:46 +0000 to 2022-12-02 20:21:24 +0000
- Refactor generate_targets into separate module (rust-lang/cargo#11445)
- Improve file found in multiple build targets warning (rust-lang/cargo#11299)
- Error when precise without -p flag (rust-lang/cargo#11349)
- Improve strategy for selecting targets to be scraped for examples (rust-lang/cargo#11430)
- Aware of compression ratio for unpack size limit (rust-lang/cargo#11337)
- Add test for rustdoc-map generation when using sparse registries (rust-lang/cargo#11403)
- Add error message when `cargo fix` on an empty repo (rust-lang/cargo#11400)
- Store the sparse+ prefix in the SourceId for sparse registries (rust-lang/cargo#11387)
- Update documentation for -Zrustdoc-scrape-examples in the Cargo Book (rust-lang/cargo#11425)
bors [Fri, 2 Dec 2022 23:00:48 +0000 (23:00 +0000)]
Auto merge of #105187 - matthiaskrgr:rollup-nxyxpko, r=matthiaskrgr
Rollup of 7 pull requests
Successful merges:
- #105026 (v8a as default aarch64 target)
- #105033 (sparc-struct-abi: work around new tail-call optimization)
- #105144 (Document normalization methods `At::{normalize,query_normalize}`)
- #105155 (rustdoc: clean up help and settings button CSS)
- #105162 (Properly synthesize `FnSig` value during cycle)
- #105163 (Check lifetime param count in `collect_trait_impl_trait_tys`)
- #105185 (Move `normalize_fn_sig` to `TypeErrCtxt`)
Matthias Krüger [Fri, 2 Dec 2022 20:22:49 +0000 (21:22 +0100)]
Rollup merge of #105155 - notriddle:notriddle/flexbox-help-settings-buttons, r=GuillaumeGomez
rustdoc: clean up help and settings button CSS
The old version of this code specified a bunch of different numbers that had to line up just right to get the size it wanted. This version uses flexbox centering, specifies the font size, and lets the browser figure out the rest of the layout automatically.
Matthias Krüger [Fri, 2 Dec 2022 20:22:47 +0000 (21:22 +0100)]
Rollup merge of #105033 - durin42:llvm-16-dont-tail-call-me-bro, r=tmandry
sparc-struct-abi: work around new tail-call optimization
Upstream LLVM change https://reviews.llvm.org/D138741 introduced some new tail-call smarts for SPARC which broke some of the checks in this test. Rather than adjust the test expectations, we add an extra no-args function that can get tail-called or not without hurting the needs of the test.
Matthias Krüger [Fri, 2 Dec 2022 20:22:47 +0000 (21:22 +0100)]
Rollup merge of #105026 - oToToT:aarch64-v8a, r=davidtwco
v8a as default aarch64 target
After https://github.com/llvm/llvm-project/commit/8689f5e landed, LLVM takes the intersection of v8a and v8r as default. This commit brings back v8a support by explicitly specifying v8a in the feature list.
This should solve #97724.
p.s. a bit more context can also be found in https://github.com/llvm/llvm-project/issues/57904#issuecomment-1329555590.
bors [Fri, 2 Dec 2022 20:07:23 +0000 (20:07 +0000)]
Auto merge of #104999 - saethlin:immediate-abort-inlining, r=thomcc
Adjust inlining attributes around panic_immediate_abort
The goal of `panic_immediate_abort` is to permit the panic runtime and formatting code paths to be optimized away. But while poking through some disassembly of a small program compiled with that option, I found that was not the case. Enabling LTO did address that specific issue, but enabling LTO is a steep price to pay for this feature doing its job.
This PR fixes that, by tweaking two things:
* All the slice indexing functions that we `const_eval_select` on get `#[inline]`. `objdump -dC` told me that originally some `_ct` functions could end up in an executable. I won't pretend to understand what's going on there.
* Normalize attributes across all `panic!` wrappers: use `inline(never) + cold` normally, and `inline` when `panic_immediate_abort` is enabled.
But also, with LTO and `panic_immediate_abort` enabled, this patch knocks ~709 kB out of the `.text` segment of `librustc_driver.so`. That is slightly surprising to me, my best theory is that this shifts some inlining earlier in compilation, enabling some subsequent optimizations. The size improvement of `librustc_driver.so` with `panic_immediate_abort` due to this patch is greater with LTO than without LTO, which I suppose backs up this theory.
I do not know how to test this. I would quite like to, because I think what this is solving was an accidental regression. This only works with `-Zbuild-std` which is a cargo flag, and thus can't be used in a rustc codegen test.
r? `@thomcc`
---
I do not seriously think anyone is going to use a compiler built with `panic_immediate_abort`, but I wanted a big complicated Rust program to try this out on, and the compiler is such.