Suggest changing `iter`/`into_iter` when the other was meant
When encountering a call to `iter` that should have been `into_iter` and vice-versa, provide a structured suggestion:
```
error[E0271]: type mismatch resolving `<IntoIter<{integer}, 3> as IntoIterator>::Item == &{integer}`
--> $DIR/into_iter-when-iter-was-intended.rs:5:37
|
LL | let _a = [0, 1, 2].iter().chain([3, 4, 5].into_iter());
| ----- ^^^^^^^^^^^^^^^^^^^^^ expected `&{integer}`, found integer
| |
| required by a bound introduced by this call
|
note: the method call chain might not have had the expected associated types
--> $DIR/into_iter-when-iter-was-intended.rs:5:47
|
LL | let _a = [0, 1, 2].iter().chain([3, 4, 5].into_iter());
| --------- ^^^^^^^^^^^ `IntoIterator::Item` is `{integer}` here
| |
| this expression has type `[{integer}; 3]`
note: required by a bound in `std::iter::Iterator::chain`
--> $SRC_DIR/core/src/iter/traits/iterator.rs:LL:COL
help: consider not consuming the `[{integer}, 3]` to construct the `Iterator`
|
LL - let _a = [0, 1, 2].iter().chain([3, 4, 5].into_iter());
LL + let _a = [0, 1, 2].iter().chain([3, 4, 5].iter());
|
```
Finish addressing the original case in rust-lang/rust#68095. Only the case of chaining a `Vec` or `[]` is left unhandled.
Remove uses of `&mut CmResolver`
Before rust-lang/rust#148329, using CmResolver in closures was not possible when trying to reborrow. This pr changes uses of `&mut CmResolver` into a bare `CmResolver`, to keep the code clean (and to not have `&mut &mut Resolver`)
r? @petrochenkov
- Added `RecordSpread` enum to distinguish between no spread, field defaults, and spread expressions
- Updated `FieldData` to include `default_value` field
- Modified record literal lowering to handle default field values
- Updated diagnostics to check for missing fields considering defaults
- Added methods to get matched fields for records for completions
- Enhanced hover support for struct rest patterns
Rollup of 2 pull requests
Successful merges:
- rust-lang/rust#151612 (Update documentation for `cold_path`, `likely`, and `unlikely`)
- rust-lang/rust#151670 (compiletest: Parse aux `proc-macro` directive into struct)
Update documentation for `cold_path`, `likely`, and `unlikely`
* Add a note recommending benchmarks to `cold_path`, as other hints have
* Note that `cold_path` can be used to implement `likely` and `unlikely`
* Update the tracking issue for the `likely_unlikely` feature
Tracking issue: https://github.com/rust-lang/rust/issues/136873
Tracking issue: https://github.com/rust-lang/rust/issues/151619
Fix broken WASIp1 reference link
### Location (URL)
https://doc.rust-lang.org/rustc/platform-support/wasm32-wasip1.html
<img width="800" alt="image" src="https://github.com/user-attachments/assets/b9402b3a-db7b-405f-b4ef-d849c03ad893" />
### Summary
The WASIp1 reference link in the `wasm32-wasip1` platform documentation currently points to a path that no longer exists in the WASI repository.
The WASI project recently migrated the WASI 0.1 (preview1) documentation from the `legacy/preview1` directory to the dedicated `wasi-0.1` branch (WebAssembly/WASI#855).
This updates the link to point to the intended historical WASIp1 reference, which matches the documented intent of the `wasm32-wasip1` target.
Add a `documentation` remapping path scope for rustdoc usage
This PR adds a new remapping path scope for rustdoc usage: `documentation`, instead of rustdoc abusing the other scopes for it's usage.
Like remapping paths in rustdoc, this scope is unstable. (rustdoc doesn't even have yet an equivalent to [rustc `--remap-path-scope`](https://doc.rust-lang.org/nightly/rustc/remap-source-paths.html#--remap-path-scope)).
I also took the opportunity to add a bit of documentation in rustdoc book.
compiletest: add implied `needs-target-std` for `codegen` mode tests unless annotated with `#![no_std]`/`#![no_core]`
A `codegen` mode test (such as `codegen-llvm` test suite) will now by default have an implied `//@ needs-target-std` directive, *unless* the test explicitly has an `#![no_std]`/`#![no_core]` attribute which disables this behavior.
- When a test has both `#![no_std]`/`#![no_core]` and `//@ needs-target-std`, the explicit `//@ needs-target-std` directive will cause the test to be ignored for targets that do not support std still.
This is to make it easier to test out-of-tree targets / custom targets (and targets not tested in r-l/r CI) without requiring target maintainers to do a bunch of manual `//@ needs-target-std` busywork.
Context: [#t-compiler/help > `compiletest` cannot find `core` library for target != host](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/.60compiletest.60.20cannot.20find.20.60core.60.20library.20for.20target.20!.3D.20host/with/568652419)
## Implementation remarks
This is an alternative version of https://github.com/rust-lang/rust/pull/150672, with some differences:
- *This* PR applies this implied-`needs-target-std` behavior to all `codegen` test mode tests.
- *This* PR does the synthetic directive injection in the same place as implied-`codegen-run` directives. Both are of course hacks, but at least they're together next to each other.
