| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Optimized error reporting for recursive requirements #47720
Fixes #47720
|
|
Add `-Zteach` documentation
Add extra inline documentation to E0019, E0016, E0013, E0396, E0017,
E0018, E0010, E0022, E0030, E0029, E0033, E0026 and E0027.
Follow up to #47652.
|
|
Implement `?` macro repetition
See rust-lang/rfcs#2298 (with disposition merge)
|
|
rustc_mir: insert a dummy access to places being matched on, when building MIR.
Fixes #47412 by adding a `_dummy = Discriminant(place)` before each `match place {...}`.
r? @nikomatsakis
|
|
fix typo: substract -> subtract
|
|
Fix visitation order of calls so that it matches execution order. Fixes #48048
r? @nikomatsakis
|
|
etaoins:fix-ice-for-mismatched-args-on-target-without-span, r=estebank
Fix ICE for mismatched args on target without span
Commit 7ed00caacc improved our error reporting by including the target function in our error messages when there is an argument count mismatch. A simple example from the UI tests is:
```
error[E0593]: function is expected to take a single 2-tuple as argument, but it takes 0 arguments
--> $DIR/closure-arg-count.rs:32:53
|
32 | let _it = vec![1, 2, 3].into_iter().enumerate().map(foo);
| ^^^ expected function that takes a single 2-tuple as argument
...
44 | fn foo() {}
| -------- takes 0 arguments
```
However, this assumed the target span was always available. This does not hold true if the target function is in `std` or another crate. A simple example from #48046 is assigning `str::split` to a function type with a different number of arguments.
Fix by omitting all of the labels and suggestions related to the target span when it's not found.
Fixes #48046
r? @estebank
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rollup of 10 pull requests
- Successful merges: #47613, #47631, #47810, #47883, #47922, #47944, #48014, #48018, #48020, #48028
- Failed merges:
|
|
correct E0619 span re method call receivers whose type must be known
Previously, when the type of a method receiver could not be determined,
the error message would, potentially confusingly, highlight the span of
the entire method call.
Resolves #36598, resolves #42234.
|
|
Warn about more ignored bounds in type aliases
It seems that all bounds in type aliases are entirely ignored, not just type bounds. This extends the warning appropriately.
I assume this should be made a hard error with the next epoch? I can't see any reason to accept these programs. (And suddenly enforcing these type bounds would be a breaking change.)
|
|
zackmdavis:and_the_case_of_the_unused_field_pattern, r=estebank
correct unused field pattern suggestions
r? @estebank
|
|
Add filtering options to `rustc_on_unimplemented`
- Add filtering options to `rustc_on_unimplemented` for local traits, filtering on `Self` and type arguments.
- Add a way to provide custom notes.
- Tweak binops text.
- Add filter to detect wether `Self` is local or belongs to another crate.
- Add filter to `Iterator` diagnostic for `&str`.
Partly addresses #44755 with a different syntax, as a first approach. Fixes #46216, fixes #37522, CC #34297, #46806.
|
|
[NLL] Improve DefiningTy::Const
Fixes #47590 by fixing the way DefiningTy represents constants. Previously, constants were represented using just the type of the variable. However, this will fail to capture early-bound regions as NLL inference vars, resulting in an ICE when we try to compute region VIDs a little bit later in the universal
region resolution process. (ref #47590)
|
|
Commit 7ed00caacc improved our error reporting by including the target
function in our error messages when there is an argument count mismatch.
A simple example from the UI tests is:
```
error[E0593]: function is expected to take a single 2-tuple as argument, but it takes 0 arguments
--> $DIR/closure-arg-count.rs:32:53
|
32 | let _it = vec![1, 2, 3].into_iter().enumerate().map(foo);
| ^^^ expected function that takes a single 2-tuple as argument
...
44 | fn foo() {}
| -------- takes 0 arguments
```
However, this assumed the target span was always available. This does
not hold true if the target function is in `std` or another crate. A
simple example from #48046 is assigning `str::split` to a function type
with a different number of arguments.
Fix by removing all of the labels and suggestions related to the target
span when it's not found.
Fixes #48046
|
|
|
|
Fixes #47590 by fixing the way DefiningTy represents constants. Previously,
constants were represented using just the type of the variable. However, this
will fail to capture early-bound regions as NLL inference vars, resulting in an
ICE when we try to compute region VIDs a little bit later in the universal
region resolution process.
|
|
MIR-borrowck: augmented assignment causes duplicate errors
Fixes #45697. This PR resolves the error duplication. I attempted to replace the existing sets since there were quite a few but only managed to replace two of them.
r? @nikomatsakis
|
|
|
|
|
|
Previously, when the type of a method receiver could not be determined,
the error message would, potentially confusingly, highlight the span of
the entire method call.
Resolves #36598, resolves #42234.
|
|
ordering when -O is passed.
|
|
|
|
|
|
r=petrochenkov
Stabilize feature(match_beginning_vert)
With this feature stabilized, match expressions can optionally have a `|` at the beginning of each arm.
Reference PR: rust-lang-nursery/reference#231
Closes #44101
|
|
zackmdavis:and_the_case_of_the_necessary_unnecessary_parens, r=nikomatsakis
decline to lint technically-unnecessary parens in function or method arguments inside of nested macros
In #46980 ("in which the unused-parens lint..." (14982db2d6)), the
unused-parens lint was made to check function and method arguments,
which it previously did not (seemingly due to oversight rather than
willful design). However, in #47775 and discussion thereon,
user–developers of Geal/nom and graphql-rust/juniper reported that the
lint was seemingly erroneously triggering on certain complex macros in
those projects. While this doesn't seem like a bug in the lint in the
particular strict sense that the expanded code would, in fact, contain
unncecessary parentheses, it also doesn't seem like the sort of thing
macro authors should have to think about: the spirit of the
unused-parens lint is to prevent needless clutter in code, not to give
macro authors extra heartache in the handling of token trees.
We propose the expediency of declining to lint unused parentheses in
function or method args inside of nested expansions: we believe that
this should eliminate the petty, troublesome lint warnings reported
in the issue, without forgoing the benefits of the lint in simpler
macros.
It seemed like too much duplicated code for the `Call` and `MethodCall`
match arms to duplicate the nested-macro check in addition to each
having their own `for` loop, so this occasioned a slight refactor so
that the function and method cases could share code—hopefully the
overall intent is at least no less clear to the gentle reader.
This is concerning #47775.
|
|
Generator bugfixes
r? @nikomatsakis
|
|
elided lifetime
Closes #45992
Hey
Having a problem with my config so decided to make a WIP PR nevertheless. Will add some more tests.
|
|
Rollup of 10 pull requests
- Successful merges: #46156, #47829, #47842, #47898, #47914, #47916, #47919, #47942, #47951, #47973
- Failed merges: #47753
|
|
Tweak presentation on lifetime trait mismatch
- On trait/impl method discrepancy, add label pointing at trait signature.
- Point only at method definition when referring to named lifetimes on lifetime mismatch.
- When the sub and sup expectations are the same, tweak the output to avoid repeated spans.
Fix #30790, CC #18759.
|
|
spans involving macro context Sometimes the parser attempts to synthesize spans from within a macro context with the span for the captured argument, leading to non-sensical spans with very bad output. Given that an incorrect span is worse than a partially incomplete span, when detecting this situation return only one of the spans without merging them. Fix #32072, #47778. CC #23480.
|
|
value from `break` when invalid When attempting to use `break` with a value in a type of loop where it'd be invalid (any non-`loop`), suggest using `break` on its own. Close #34359.
|
|
Include space in suggestion `mut` in bindings
Fix #46614.
|
|
|
|
|
|
|
|
|
|
- filter error on the evaluated value of `Self`
- filter error on the evaluated value of the type arguments
- add argument to include custom note in diagnostic
- allow the parser to parse `Self` when processing attributes
- add custom message to binops
|
|
|
|
Sometimes the parser attempts to synthesize spans from within a macro
context with the span for the captured argument, leading to non-sensical
spans with very bad output. Given that an incorrect span is worse than
a partially incomplete span, when detecting this situation return only
one of the spans without mergin them.
|
|
Previously, unused variables would get a note that the warning could be
silenced by prefixing the variable with an underscore, but that doesn't
work for field shorthand patterns, which the liveness analysis didn't
know about.
The "to avoid this warning" verbiage seemed unnecessary.
Resolves #47390.
|
|
Fix regression: account for trait methods in arg count mismatch error
Fixed #47706 (https://github.com/rust-lang/rust/issues/47706#issuecomment-361161495)
Original PR #47747 missed methods on trait definitions.
This edit was done in GitHub. I think I got the signature of the variant right, going by the ICE debug output and the other cases above.
|
|
use correct casing for rename suggestions
If the original name is uppercase, use camel case. Otherwise, use snake
case.
|
|
In #46980 ("in which the unused-parens lint..." (14982db2d6)), the
unused-parens lint was made to check function and method arguments,
which it previously did not (seemingly due to oversight rather than
willful design). However, in #47775 and discussion thereon,
user–developers of Geal/nom and graphql-rust/juniper reported that the
lint was seemingly erroneously triggering on certain complex macros in
those projects. While this doesn't seem like a bug in the lint in the
particular strict sense that the expanded code would, in fact, contain
unncecessary parentheses, it also doesn't seem like the sort of thing
macro authors should have to think about: the spirit of the
unused-parens lint is to prevent needless clutter in code, not to give
macro authors extra heartache in the handling of token trees.
We propose the expediency of declining to lint unused parentheses in
function or method args inside of nested expansions: we believe that
this should eliminate the petty, troublesome lint warnings reported
in the issue, without forgoing the benefits of the lint in simpler
macros.
It seemed like too much duplicated code for the `Call` and `MethodCall`
match arms to duplicate the nested-macro check in addition to each
having their own `for` loop, so this occasioned a slight refactor so
that the function and method cases could share code—hopefully the
overall intent is at least no less clear to the gentle reader.
This is concerning #47775.
|
|
|
