| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Point at variant on pattern field count mismatch
|
|
or-patterns: Uniformly use `PatKind::Or` in AST & Fix/Cleanup resolve
Following up on work in https://github.com/rust-lang/rust/pull/63693 and https://github.com/rust-lang/rust/pull/61708, in this PR we:
- Uniformly use `PatKind::Or(...)` in AST:
- Change `ast::Arm.pats: Vec<P<Pat>>` => `ast::Arm.pat: P<Pat>`
- Change `ast::ExprKind::Let.0: Vec<P<Pat>>` => `ast::ExprKind::Let.0: P<Pat>`
- Adjust `librustc_resolve/late.rs` to correctly handle or-patterns at any level of nesting as a result.
In particular, the already-bound check which rejects e.g. `let (a, a);` now accounts for or-patterns. The consistency checking (ensures no missing bindings and binding mode consistency) also now accounts for or-patterns. In the process, a bug was found in the current compiler which allowed:
```rust
enum E<T> { A(T, T), B(T) }
use E::*;
fn foo() {
match A(0, 1) {
B(mut a) | A(mut a, mut a) => {}
}
}
```
The new algorithms took a few iterations to get right. I tried several clever schemes but ultimately a version based on a stack of hashsets and recording product/sum contexts was chosen since it is more clearly correct.
- Clean up `librustc_resolve/late.rs` by, among other things, using a new `with_rib` function to better ensure stack dicipline.
- Do not push the change in AST to HIR for now to avoid doing too much in this PR. To cope with this, we introduce a temporary hack in `rustc::hir::lowering` (clearly marked in the diff).
cc https://github.com/rust-lang/rust/issues/54883
cc @dlrobertson @matthewjasper
r? @petrochenkov
|
|
Improve searching in rustdoc and add tests
👋 I have made searching in rustdoc more intuitive, added a couple more tests and made a little shell script to aid testing. Closes #63005.
It took me quite a while to figure out how to run the tests for rustdoc (instead of running tests for other crates with rustdoc); the only pointer I found was [hidden in the rustc book](https://rust-lang.github.io/rustc-guide/rustdoc.html#cheat-sheet). Maybe this could be better documented? I shall be delighted to help if it is desirable.
|
|
Opaque type locations in error message for clarity.
Attempts to fix #63167
|
|
Point at appropriate arm on type error on if/else/match with one non-! arm
Fix https://github.com/rust-lang/rust/issues/61281.
|
|
Fix const_err with `-(-0.0)`
Fixes #64059
r? @oli-obk
|
|
use TokenStream rather than &[TokenTree] for built-in macros
That way, we don't loose the jointness info
|
|
Account for doc comments coming from proc macros without spans
Fix https://github.com/rust-lang/rust/issues/63821.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Also document `ast::Pat::walk`.
|
|
|
|
|
|
unused_parens: account for or-patterns and `&(mut x)`
Fixes https://github.com/rust-lang/rust/issues/55342.
Fixes https://github.com/rust-lang/rust/issues/64106.
cc https://github.com/rust-lang/rust/issues/54883
cc https://github.com/rust-lang/rust/pull/64111
r? @oli-obk
|
|
Refer to "`self` type" instead of "receiver type"
Fix https://github.com/rust-lang/rust/issues/42603.
|
|
Add some more tests for underscore imports
|
|
r=varkor
Check impl trait substs when checking for recursive types
closes #64004
|
|
Harden `param_attrs` test wrt. usage of a proc macro `#[attr]`
The `param-attrs-builtin-attrs.rs` test file uses the `#[test]` attribute which should cover this but `#[test]` isn't a proc macro attribute so we add another test to be on the safe side. This intends to address https://github.com/rust-lang/rust/pull/64010#issuecomment-526564316.
r? @nikomatsakis
cc @c410-f3r @petrochenkov
cc https://github.com/rust-lang/rust/issues/60406
|
|
|
|
Allow checking of run-pass execution output in compiletest
Closes #63751
Adds a `check-run-results` flag to compiletest headers, which if enabled checks the output of the execution of a run-pass test's binary against expected output.
|
|
|
|
That way, we don't loose the jointness info
|
|
|
|
|
|
Emit error on intrinsic to fn ptr casts
I'm not sure if a type error is the best way of doing this but it seemed like a relatively correct place to do it, and I expect this is a pretty rare case to hit anyway.
Fixes #15694
|
|
Account for arbitrary self types in E0599
Fix https://github.com/rust-lang/rust/issues/62373
|
|
Emit a single error on if expr with expectation and no else clause
Fix https://github.com/rust-lang/rust/issues/60254.
r? @Centril
|
|
|
|
|
|
|
|
|
|
|
|
Test that Wrapping arithmetic ops are implemented for all int types
Closes #49660
|
|
|
|
remove the unstable rustdoc parameter --linker
use the code generation parameter -Clinker (same parameter as rustc)
to control what linker to use for building the rustdoc test executables.
closes: #63816
|
|
|
|
|
|
|
|
Suggest call fn ctor passed as arg to fn with type param bounds
_Reviewer note: the relevant changes are in the second commit, the first is simple and mechanical, but verbose._
When forgetting to call a fn in an argument position to an fn that has a generic bound:
```rust
async fn foo() {}
fn bar(f: impl Future<Output=()>) {}
fn main() {
bar(foo); // <- should be `bar(foo());`
}
```
suggest calling it:
```
error[E0277]: the trait bound `fn() -> impl std::future::Future {foo}: std::future::Future` is not satisfied
--> $DIR/async-fn-ctor-passed-as-arg-where-it-should-have-been-called.rs:9:5
|
LL | fn bar(f: impl Future<Output=()>) {}
| --------------------------------- required by `bar`
...
LL | bar(foo);
| ^^^ the trait `std::future::Future` is not implemented for `fn() -> impl std::future::Future {foo}`
|
= help: it looks like you forgot to use parentheses to call the function: `foo()`
```
Fix #63100. Follow up to #63833 and #63337.
|
|
|
|
|
|
|
|
|
|
|
|
Kill borrows from assignments after generating new borrows
Closes #63719
|
