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.
Magic functions for writing to stdout/stderr.
This enables I/O in no_std contexts (or, really, any Miri-specific OS-independent context). Combined with the `abort` intrinsic it should allow a reasonable test framework in no_std.
**Question for maintainers:** So, the `no_std` panic test needs work, for two reasons:
- First, its stdout includes Miri's whole message about the abort intrinsic having been used. I guess whatever panic handler you use in `std` contexts exits cleanly without triggering this message. Comparing the entire output with backtrace as golden seems fragile.
- Second, likely for the same reason, the test framework appears to expect the test to exit successfully, when in fact it exits with status 1 due to the abort. This means the test doesn't actually pass right now.
What shall I do there?
Fix the bug of next_point in source_map
There is a bug in `next_point`, the new span won't move to next position when be called in the first time.
For this reason, our current code is working like this:
1. When we really want to move to the next position, we called two times of `next_point`
2. Some code which use `next_point` actually done the same thing with `shrink_to_hi`
This fix make sure when `next_point` is called, span will move with the width at least 1, and also work correctly in the scenario of multiple bytes.
Ref: https://github.com/rust-lang/rust/pull/103140#discussion_r997710998
r? `@davidtwco`
fix: Don't catch the server activation error
We are are rethrowing and showing errors higher up in the call stack already. This just ate the error hiding the stacktrace unnecessarily.
rustdoc: remove no-op CSS `nav.sub { font-size: 1rem }`
This rule originated as a `font-size: 16px`, when body had `font-size: 13px` set in 4fd061c426902b0904c65e64a3780b21f9ab3afb.
It remained even when body's font size was bumped up to 16px, 4d5f4ff5e9297dcad21612f9dd20ae4598b5b7e2, making the rule a no-op, and was carried forward when it was converted to 1rem in cc18120425a5c571a968d850c75cc935a8321136.
Deny hashing ty/re/ct inference variables
cc `@cjgillot` and https://github.com/rust-lang/rust/pull/102695#issuecomment-1275706528
r? `@lcnr`
best reviewed one commit at a time, mostly because the second commit that fixes `ClosureOutlivesRequirement` is mostly noise because of losing its `<'tcx>` lifetime parameter.
Do anonymous lifetimes remapping correctly for nested rpits
Closes#103141
r? `@cjgillot` `@nikomatsakis`
This fixes a stable to stable regression that in my opinion is `P-critical` so, we probably want to backport it all the way up to stable.
This enables I/O in no_std contexts (or, really, any Miri-specific
OS-independent context). Combined with the `abort` intrinsic it should
allow a reasonable test framework in no_std.
