| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
If we encounter a borrow error on `vec![1, 2, 3].iter()`, suggest
`into_iter`.
Fix #68445.
|
|
When encountering a binding that isn't found but has a typo suggestion
for a binding with a leading underscore, suggest changing the binding
definition instead of the use place.
Fix #60164.
|
|
Move where doc comment meant as comment check
The new place makes more sense and covers more cases beyond individual statements.
```
error: expected one of `.`, `;`, `?`, `else`, or an operator, found doc comment `//!foo
--> $DIR/doc-comment-in-stmt.rs:25:22
|
LL | let y = x.max(1) //!foo
| ^^^^^^ expected one of `.`, `;`, `?`, `else`, or an operator
|
help: add a space before `!` to write a regular comment
|
LL | let y = x.max(1) // !foo
| +
```
Fix #65329.
|
|
Nowadays there is an `invalid-compile-flags` folder, thus move this
one there.
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
|
|
|
|
|
|
Add a test showing failing closure signature inference in new solver
Been thinking a bit about how to make this test pass... but we don't actually have any good tests exercising this behavior in the suite.
r? lcnr
|
|
The new place makes more sense and covers more cases beyond individual
statements.
```
error: expected one of `.`, `;`, `?`, `else`, or an operator, found doc comment `//!foo
--> $DIR/doc-comment-in-stmt.rs:25:22
|
LL | let y = x.max(1) //!foo
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected one of `.`, `;`, `?`, `else`, or an operator
|
help: add a space before `!` to write a regular comment
|
LL | let y = x.max(1) // !foo
| +
```
Fix #65329.
|
|
Fix duplicate labels emitted in `render_multispan_macro_backtrace()`
This PR replaces the `Vec` used to store labels with an `FxIndexSet` in order to eliminate duplicates
Fixes #116836
|
|
|
|
Implement rustc part of RFC 3127 trim-paths
This PR implements (or at least tries to) [RFC 3127 trim-paths](https://github.com/rust-lang/rust/issues/111540), the rustc part. That is `-Zremap-path-scope` with all of it's components/scopes.
`@rustbot` label: +F-trim-paths
|
|
This commit improves warnings emitted for malformed on unimplemented
attributes by:
* Improving the span of the warnings
* Adding a label message to them
* Separating the messages for missing and unexpected options
* Adding a help message that says which options are supported
|
|
Tweak wording of type errors involving type params
Fix #78206.
|
|
Make `#[repr(Rust)]` incompatible with other (non-modifier) representation hints like `C` and `simd`
Read more about this change here: https://github.com/rust-lang/rust/pull/116829#issuecomment-1768618240.
Fixes [after backport] #116825.
|
|
Don't ICE when encountering unresolved regions in `fully_resolve`
We can encounter unresolved regions due to unconstrained impl lifetime arguments because `collect_return_position_impl_trait_in_trait_tys` runs before WF actually checks that the impl is well-formed.
Fixes #116525
|
|
Using hash set instead of vec to weed out duplicates
|
|
Fix #85378.
|
|
Fix #78206.
|
|
|
|
|
|
|
|
|
|
revert #114586
Reverts #114586.
cc #116877 (not closing until this gets a beta backport)
fixes #116684
fixes https://github.com/rust-lang/rust/pull/114586#issuecomment-1751967321
r? `@oli-obk` or `@lcnr`
|
|
Suggest constraining assoc types in more cases
Fix #46969.
```
error[E0308]: mismatched types
--> $DIR/suggest-contraining-assoc-type-because-of-assoc-const.rs:12:21
|
LL | const N: C::M = 4u8;
| ^^^ expected associated type, found `u8`
|
= note: expected associated type `<C as O>::M`
found type `u8`
help: consider constraining the associated type `<C as O>::M` to `u8`
|
LL | impl<C: O<M = u8>> U<C> for u16 {
| ++++++++
```
|
|
Disable effects in libcore again
r? `@fee1-dead`
This was accidentally allowed by https://github.com/rust-lang/rust/pull/114776 without feature gates
|
|
rmehri01:missing_copy_implementations_non_exhaustive, r=petrochenkov
Disable missing_copy_implementations lint on non_exhaustive types
Fixes #116766
|
|
|
|
Properly account for self ty in method disambiguation suggestion
Fix #116703.
|
|
|
|
Fix #46969.
|
|
Normalize alloc-id in tests.
AllocIds are globally numbered in a rustc invocation. This makes them very sensitive to changes unrelated to what is being tested. This commit normalizes them by renumbering, in order of appearance in the output.
The renumbering allows to keep the identity, that a simple `allocN` wouldn't. This is useful when we have memory dumps.
cc `@saethlin`
r? `@oli-obk`
|
|
|
|
|
|
|
|
Fix #116703.
|
|
Special case iterator chain checks for suggestion
When encountering method call chains of `Iterator`, check for trailing `;` in the body of closures passed into `Iterator::map`, as well as calls to `<T as Clone>::clone` when `T` is a type param and `T: !Clone`.
Fix #9082.
|
|
Add new simpler and more explicit syntax for check-cfg
<details>
<summary>
Old proposition (before the MCP)
</summary>
This PR adds a new simpler and more explicit syntax for check-cfg. It consist of two new form:
- `exhaustive(names, values)`
- `configure(name, "value1", "value2", ... "valueN")`
The preview forms `names(...)` and `values(...)` have implicit meaning that are not strait-forward. In particular `values(foo)`&`values(bar)` and `names(foo, bar)` are not equivalent which has created [some confusions](https://github.com/rust-lang/rust/pull/98080).
Also the `names()` and `values()` form are not clear either and again created some confusions where peoples believed that `values()`&`values(foo)` could be reduced to just `values(foo)`.
To fix that the two new forms are made to be explicit and simpler. See the table of correspondence:
- `names()` -> `exhaustive(names)`
- `values()` -> `exhaustive(values)`
- `names(foo)` -> `exhaustive(names)`&`configure(foo)`
- `values(foo)` -> `configure(foo)`
- `values(feat, "foo", "bar")` -> `configure(feat, "foo", "bar")`
- `values(foo)`&`values(bar)` -> `configure(foo, bar)`
- `names()`&`values()`&`values(my_cfg)` -> `exhaustive(names, values)`&`configure(my_cfg)`
Another benefits of the new syntax is that it allow for further options (like conditional checking for --cfg, currently always on) without syntax change.
The two previous forms are deprecated and will be removed once cargo and beta rustc have the necessary support.
</details>
This PR is the first part of the implementation of [MCP636 - Simplify and improve explicitness of the check-cfg syntax](https://github.com/rust-lang/compiler-team/issues/636).
## New `cfg` form
It introduces the new [`cfg` form](https://github.com/rust-lang/compiler-team/issues/636) and deprecate the other two:
```
rustc --check-cfg 'cfg(name1, ..., nameN, values("value1", "value2", ... "valueN"))'
```
## Default built-in names and values
It also changes the default for the built-in names and values checking.
- Built-in values checking would always be activated as long as a `--check-cfg` argument is present
- Built-in names checking would always be activated as long as a `--check-cfg` argument is present **unless** if any `cfg(any())` arg is passed
~~**Note: depends on https://github.com/rust-lang/rust/pull/111068 but is reviewable (last two commits)!**~~
Resolve https://github.com/rust-lang/compiler-team/issues/636
r? `@petrochenkov`
|
|
use is_variant_list_non_exhaustive/is_field_list_non_exhaustive
remove unused tcx
inline non_exhaustive def/variant check
|
|
Duplicate `~const` bounds with a non-const one in effects desugaring
This should unblock #116058.
r? `@oli-obk`
|
|
|
|
|
|
|
|
Fix implied outlives check for GAT in RPITIT
We enforce certain `Self: 'lt` bounds for GATs to save space for more sophisticated implied bounds, but those currently operate on the HIR. Code was easily reworked to operate on def-ids so that we can properly let these suggestions propagate through synthetic associated types like RPITITs and AFITs.
r? `@jackh726` or `@aliemjay`
Fixes #116789
|
|
|
|
|
