Rollup of 9 pull requests
Successful merges:
- #103221 (Fix `SelfVisitor::is_self_ty` ICE)
- #103230 (Clarify startup)
- #103281 (Adjust `transmute{,_copy}` to be clearer about which of `T` and `U` is input vs output)
- #103288 (Fixed docs typo in `library/std/src/time.rs`)
- #103296 (+/- shortcut now only expand/collapse, not both)
- #103297 (fix typo)
- #103313 (Don't label `src/test` tests as `A-testsuite`)
- #103315 (interpret: remove an incorrect assertion)
- #103319 (Improve "`~const` is not allowed here" message)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
interpret: remove an incorrect assertion
This fixes an ICE in Miri, [reported](https://rust-lang.zulipchat.com/#narrow/stream/269128-miri/topic/SwitchInt.20with.20no.20targets.3F) by `@saethlin.` The faulty assertion was introduced by 432535da2b, when a previously correct assertion checking that the `otherwise` target exists got replaced by this assertion checking that at least one more target beyond `otherwise` exists.
Sadly we don't have a small reproducer so I don't think we can easily add a testcase.
Fixed docs typo in `library/std/src/time.rs`
* Changed comment from `Previous rust versions panicked when self was earlier than the current time.` to `Previous rust versions panicked when the current time was earlier than self.`
* Resolves#103282.
Adjust `transmute{,_copy}` to be clearer about which of `T` and `U` is input vs output
This is essentially a documentation-only change (although it does touch code in an irrelevant way).
Workaround the python vscode extension's polyfill
Fixes#13442
`String.replaceAll` and `String.replace` behave the same when given a (/g-flagged) Regex, so fix is very simple.
linker: Fix weak lang item linking with combination windows-gnu + LLD + LTO
In https://github.com/rust-lang/rust/pull/100404 this logic was originally disabled for MSVC due to issues with LTO, but the same issues appear on windows-gnu with LLD because that LLD uses the same underlying logic as MSVC LLD, just with re-syntaxed command line options.
So this PR just disables it for LTO builds in general.
Fix bug introduced by #9386#9386 introduced a potential out-of-bounds array access. Specifically, a location returned by `local_assignments` could have [`location.statement_index` equal to `mir.basic_blocks[location.block].statements.len()`](b8a9a507bf/clippy_utils/src/mir/mod.rs (L129)), in which case the location would refer to the block terminator:
b8a9a507bf/clippy_lints/src/dereference.rs (L1204-L1206)
I suspect the bug is not triggerable now, because of checks leading up to where it occurs. But a future code change could make it triggerable. Hence, it should be fixed.
r? `@Jarcho`
changelog: none
feat: add multiple getters mode in `generate_getter`
This commit adds two modes to generate_getter action.
First, the plain old working on single fields.
Second, working on a selected range of fields.
Should partially solve #13246
If this gets approved will create a separate PR for setters version of the same
### Points to help in review:
- `generate_getter_from_record_info` contains code which is mostly taken from assist before refactor
- Same goes for `parse_record_fields`
- There are changes in other assists, as one of the methods in utils named `find_struct_impl` is changed, before it used to accept a single `fn_name`, now it takes a list of function names to check against. All old impls are updated to create a small list to pass their single element.
### Assumptions:
- If any of the fields have an implementation, the action will quit.
