| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
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
|
|
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.
|
|
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
|
|
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
|
|
|
|
|
|
Fix ICE on parsing an invalid variable declaration as a statement like:
```
macro_rules! m { ($s:stmt) => {} }
m! { var x }
```
|
|
|
|
|
|
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}`
```
|
|
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
|
|
|
|
|
|
Reduce macro usage for lints
r? `@cjgillot`
|
|
fmt
add a comment
|
|
Add `type_ascribe!` macro as placeholder syntax for type ascription
This makes it still possible to test the internal semantics of type ascription even once the `:`-syntax is removed from the parser. The macro now gets used in a bunch of UI tests that test the semantics and not syntax of type ascription.
I might have forgotten a few tests but this should hopefully be most of them. The remaining ones will certainly be found once type ascription is removed from the parser altogether.
Part of #101728
|
|
Because the error message that emit out is from main error of parser
The information of enum variant disappears while parsing enum variant with error
We only check the syntax of expecting token, i.e, in case #103869
It will error it without telling the message that this error is from pasring enum variant.
Propagate the sub-error from parsing enum variant to the main error of parser by chaining it with map_err
Check the sub-error before emitting the main error of parser and attach it.
Fix #103869
|
|
|
|
|
|
rustc_ast_lowering: Stop lowering imports into multiple items
Lower them into a single item with multiple resolutions instead.
This also allows to remove additional `NodId`s and `DefId`s related to those additional items.
|
|
|
|
|
|
Because it complicates lint implementation greatly.
|
|
|
|
Lower them into a single item with multiple resolutions instead.
This also allows to remove additional `NodId`s and `DefId`s related to those additional items.
|
