| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Avoid some `InferCtxt::build` calls
Either because we're inside of an `InferCtxt` already, or because we're not in a place where we'd ever see inference vars.
r? types
|
|
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.
r? `@compiler-errors`
|
|
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.
Fixes #104519
|
|
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)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Use parent function WfCheckingContext to check RPITIT.
WF-check for RPITIT was done in the opaque type's param-env, so it could not benefit from assumed wf types from the function's parameters.
cc `@compiler-errors` since you chose that param-env in fd2766e7fde4
Fixes https://github.com/rust-lang/rust/issues/102682
Fixes https://github.com/rust-lang/rust/issues/104908
Fixes https://github.com/rust-lang/rust/issues/102552
Fixes https://github.com/rust-lang/rust/issues/104529
|
|
Add regression test for #47814
Closes #47814
r? `@compiler-errors`
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
|
|
Properly substitute inherent associated types.
Fixes https://github.com/rust-lang/rust/issues/104240
|
|
r=compiler-errors
Fix ICE on invalid variable declarations in macro calls
This fixes ICE that happens with invalid variable declarations in macro calls like:
```rust
macro_rules! m { ($s:stmt) => {} }
m! { var x }
m! { auto x }
m! { mut x }
```
Found this is because of not collecting tokens on recovery, so I changed to force collect them.
Fixes https://github.com/rust-lang/rust/issues/103529.
|
|
Suggest to use . instead of :: when accessing a method of an object
Fixes #101749
Fixes #101542
|
|
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.
|
|
Add regression test for #79450
Closes #79450
r? `@oli-obk`
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
|
|
Make inline const block `ExprWithBlock`
Fix https://github.com/rust-lang/rust/pull/104087#issuecomment-1324190817
`@rustbot` label: +T-lang +F-inline_const
|
|
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)
|
|
r=compiler-errors
Don't suggest associated function call for associated const.
Fixes #104801.
r? `@compiler-errors`
|
|
|
|
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.
Also add a mixed && / || test.
|
|
r=GuillaumeGomez,jyn514,Manishearth
Consolidate rustdoc's lint passes into a single pass
This should improve performance and simplify the code.
r? `@GuillaumeGomez`
|
|
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
|
|
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
|
|
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.
|
|
|
|
Add AmbiguityError for inconsistent resolution for an import
Fixes #105069
Fixes #83950
|
|
Do not call fn_sig on non-functions.
Fixes https://github.com/rust-lang/rust/issues/105040
Fixes https://github.com/rust-lang/rust/issues/89271
|
|
Remove useless filter in unused extern crate check.
Fixes https://github.com/rust-lang/rust/issues/104562
|
|
Disable coverage instrumentation for naked functions
Fixes #105170.
|
|
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...
Fixes #105159
|
|
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.
r? `@cjgillot`
|
|
|
|
|
|
Fix ICE on parsing an invalid variable declaration as a statement like:
```
macro_rules! m { ($s:stmt) => {} }
m! { var x }
```
|
|
Merge generics and where predicates and prevent duplicates in where predicates
Part of #104886 (I didn't include bounds from parent trait yet as I think the PR is already big enough).
Also we'll need to run a perf check.
cc `@fmease` since you worked a bit on this.
r? `@notriddle`
|
|
|
|
|
|
Don't elide type information when printing E0308 with `-Zverbose`
When we pass `-Zverbose`, we kinda expect for all `_` to be replaced with more descriptive information, for example --
```
= note: expected fn pointer `fn(_, u32)`
found fn item `fn(_, i32) {foo}`
```
Where `_` is the "identical" part of the fn signatures, now gets rendered as:
```
= note: expected fn pointer `fn(i32, u32)`
found fn item `fn(i32, i32) {foo}`
```
|
|
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
Fixes #105022
r? `@GuillaumeGomez`
|
|
Don't add a note for implementing a trait if its inner type is erroneous
Fix #105138
|
|
|
|
|
|
|
|
|
|
Check lifetime param count in `collect_trait_impl_trait_tys`
We checked the type and const generics count, but not the lifetimes, which were handled in a different function.
Fixes #105154
|
|
Properly synthesize `FnSig` value during cycle
Get the arity correct when creating a `FnSig` type during `tcx.fn_sig` cycle recovery
Fixes #105152
|
|
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.
r? ``@nikic``
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
Reduce macro usage for lints
r? `@cjgillot`
|
