Consider indirect mutation during const qualification dataflow
Previously a local would be qualified if either one of two separate data
flow computations indicated so. First determined if a local could
contain the qualif, but ignored any forms of indirect mutation. Second
determined if a local could be mutably borrowed (and so indirectly
mutated), but which in turn ignored the qualif.
The end result was incorrect because the effect of indirect mutation was
effectivelly ignored in the all but the final stage of computation.
In the new implementation the indirect mutation is directly incorporated
into the qualif data flow. The local variable becomes immediately
qualified once it is mutably borrowed and borrowed place type can
contain the qualif.
In general we will now reject additional programs, program that were
prevously unintentionally accepted.
There are also some cases which are now accepted but were previously
rejected, because previous implementation didn't consider whether
borrowed place could have the qualif under the consideration.
Fixes#90124.
r? `@ecstatic-morse`
Revert "Add rustc lint, warning when iterating over hashmaps"
Fixes perf regressions introduced in https://github.com/rust-lang/rust/pull/90235 by temporarily reverting the relevant PR.
Improve perf measurements of `build_extern_trait_impl`
Before, it was only measuring one callsite of `build_impl`, and it
incremented the call count even if `build_impl` returned early because
the `did` was already inlined.
Now, it measures all calls, minus calls that return early.
The rustc fork of rayon integrates with Cargo's jobserver to limit the
amount of parallelism. However, rustdoc's use case is concurrent I/O,
which is not CPU-heavy, so it should be able to use mainline rayon.
See this discussion [1] for more details.
[1]: https://github.com/rust-lang/rust/issues/90227#issuecomment-952468618
Note: I chose rayon 1.3.1 so that the rayon version used elsewhere in
the workspace does not change.
Fixes incorrect handling of ADT's drop requirements
Fixes#90024 and a bunch of duplicates.
The main issue was just that the contract of `NeedsDropTypes::adt_components` was inconsistent; the list of types it might return were the generic parameters themselves or the fields of the ADT, depending on the nature of the drop impl. This meant that the caller could not determine whether a `.subst()` call was still needed on those types; it called `.subst()` in all cases, and this led to ICEs when the returned types were the generic params.
First contribution of more than a few lines, so feedback definitely appreciated.
Before, it was only measuring one callsite of `build_impl`, and it
incremented the call count even if `build_impl` returned early because
the `did` was already inlined.
Now, it measures all calls, minus calls that return early.
Union field access is currently qualified based on the qualification of
a value previously assigned to the union. At the same time, every union
access transmutes the content of the union, which might result in a
different qualification.
For example, consider constants A and B as defined below, under the
current rules neither contains interior mutability, since a value used
in the initial assignment did not contain `UnsafeCell` constructor.
```rust
#![feature(untagged_unions)]
union U { i: u32, c: std::cell::Cell<u32> }
const A: U = U { i: 0 };
const B: std::cell::Cell<u32> = unsafe { U { i: 0 }.c };
```
To avoid the issue, the changes here propose to consider the content of
a union as opaque and use type based qualification for union types.
Add hint for people missing `TryFrom`, `TryInto`, `FromIterator` import pre-2021
Adds a hint anytime a `TryFrom`, `TryInto`, `FromIterator` import is suggested noting that these traits are automatically imported in Edition 2021.
fix: inner attribute followed by outer attribute causing ICE
Fixes#87936, #88938, and #89971.
This removes the assertion that validates that there are no outer attributes following inner attributes. Where the inner attribute is invalid you get an actual error.
Add LLVM CFI support to the Rust compiler
This PR adds LLVM Control Flow Integrity (CFI) support to the Rust compiler. It initially provides forward-edge control flow protection for Rust-compiled code only by aggregating function pointers in groups identified by their number of arguments.
Forward-edge control flow protection for C or C++ and Rust -compiled code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code share the same virtual address space) will be provided in later work as part of this project by defining and using compatible type identifiers (see Type metadata in the design document in the tracking issue #89653).
LLVM CFI can be enabled with -Zsanitizer=cfi and requires LTO (i.e., -Clto).
Thank you, `@eddyb` and `@pcc,` for all the help!
Rollup of 3 pull requests
Successful merges:
- #90154 (rustdoc: Remove `GetDefId`)
- #90232 (rustdoc: Use TTF based font instead of OTF for CJK glyphs to improve readability)
- #90278 (rustdoc: use better highlighting for *const, *mut, and &mut)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
rustdoc: Use TTF based font instead of OTF for CJK glyphs to improve readability
Due to Windows' implementation of font rendering, OpenType fonts can be distorted. So the existing font, Noto Sans KR, is not very readable on Windows. This PR improves readability of Korean glyphs on Windows.
## Before
## After
The fonts included in this PR are licensed under the SIL Open Font License and generated with these commands:
```sh
pyftsubset NanumBarunGothic.ttf \
--unicodes=U+AC00-D7AF,U+1100-11FF,U+3130-318F,U+A960-A97F,U+D7B0-D7FF \
--output-file=NanumBarunGothic.ttf.woff --flavor=woff
```
```sh
pyftsubset NanumBarunGothic.ttf \
--unicodes=U+AC00-D7AF,U+1100-11FF,U+3130-318F,U+A960-A97F,U+D7B0-D7FF \
--output-file=NanumBarunGothic.ttf.woff2 --flavor=woff2
```
r? ``@GuillaumeGomez``
Properly check `target_features` not to trigger an assertion
Fixes#89875
I think it should be a condition instead of an assertion to check if it's a register as it's possible that `reg` is a register class.
Also, this isn't related to the issue directly, but `is_target_supported` doesn't check `target_features` attributes. Is there any way to check it on rustc_codegen_llvm?
r? `@Amanieu`
Edit error messages for `rustc_resolve::AmbiguityKind` variants
Edit the language of the ambiguity descriptions for E0659. These strings now appear as notes.
Closes#79717.
Previously a local would be qualified if either one of two separate data
flow computations indicated so. First determined if a local could
contain the qualif, but ignored any forms of indirect mutation. Second
determined if a local could be mutably borrowed (and so indirectly
mutated), but which in turn ignored the qualif.
The end result was incorrect because the effect of indirect mutation was
effectivelly ignored in the all but the final stage of computation.
In the new implementation the indirect mutation is directly incorporated
into the qualif data flow. The local variable becomes immediately
qualified once it is mutably borrowed and borrowed place type can
contain the qualif.
In general we will now reject additional programs, program that were
prevously unintentionally accepted.
There are also some cases which are now accepted but were previously
rejected, because previous implementation didn't consider whether
borrowed place could have the qualif under the consideration.
Update books
## nomicon
3 commits in 2d66852a27c5d0ec50ae021820d1de22caa2b1bd..358e6a61d5f4f0496d0a81e70cdcd25d05307342
2021-10-07 19:00:37 +0900 to 2021-10-20 11:23:12 -0700
- Write a basic "call Rust from C" example (rust-lang/nomicon#296)
- Clarify the Safe vs. Unsafe Rust relationship (rust-lang/nomicon#294)
- Fix typo with respect to dangling pointer (rust-lang/nomicon#319)
## book
8 commits in eb1282ec444db94055fa9531b6f3f803e86bb382..fd9299792852c9a368cb236748781852f75cdac6
2021-09-16 21:17:09 -0400 to 2021-10-22 21:59:46 -0400
- Reword description to emphasize what return does in a match arm
- Correct backwards wording describing From impls. Fixesrust-lang/book#2829
- Remove multiple negatives, add examples. Fixesrust-lang/book#2833
- Fix capitalization in sidebar. Fixesrust-lang/book#2860
- fix quotes
- comments from nostarch and responses for chapter 2
- (rust-lang/book#2906)
- Merge pull request rust-lang/book#2892 from Enrico2/patch-1
## rust-by-example
1 commits in 9a60624fcad0140826c44389571dc622917cd632..27f1ff5e440ef78828b68ab882b98e1b10d9af32
2021-10-04 08:13:53 -0300 to 2021-10-13 08:04:40 -0300
- Added example of `impl Trait` as an argument (rust-lang/rust-by-example#1468)
## embedded-book
1 commits in 270fccd339e5972d9c900e788f197e81a0bcd956..51739471276b1776dea27cf562b974ef07e24685
2021-10-06 16:28:48 +0000 to 2021-10-17 16:48:42 +0000
- Fix typo in 'The Borrow Checker' (rust-embedded/book#305)
Emit description of the ambiguity as a note.
Co-authored-by: Noah Lev <camelidcamel@gmail.com>
Co-authored-by: Vadim Petrochenkov <vadim.petrochenkov@gmail.com>
Avoid a branch on key being local for queries that use the same local and extern providers
Currently based on https://github.com/rust-lang/rust/pull/85810 as it slightly conflicts with it. Only the last two commits are new.
This commit adds LLVM Control Flow Integrity (CFI) support to the Rust
compiler. It initially provides forward-edge control flow protection for
Rust-compiled code only by aggregating function pointers in groups
identified by their number of arguments.
Forward-edge control flow protection for C or C++ and Rust -compiled
code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code
share the same virtual address space) will be provided in later work as
part of this project by defining and using compatible type identifiers
(see Type metadata in the design document in the tracking issue #89653).
LLVM CFI can be enabled with -Zsanitizer=cfi and requires LTO (i.e.,
-Clto).
Prevent duplicate caller bounds candidates by exposing default substs in Unevaluated
Fixes https://github.com/rust-lang/rust/issues/89334
The changes introduced in https://github.com/rust-lang/rust/pull/87280 allowed for "duplicate" caller bounds candidates to be assembled that only differed in their default substs having been "exposed" or not and resulted in an ambiguity error during trait selection. To fix this we expose the defaults substs during the creation of the ParamEnv.
r? `@lcnr`
Add -Z no-unique-section-names to reduce ELF header bloat.
This change adds a new compiler flag that can help reduce the size of ELF binaries that contain many functions.
By default, when enabling function sections (which is the default for most targets), the LLVM backend will generate different section names for each function. For example, a function `func` would generate a section called `.text.func`. Normally this is fine because the linker will merge all those sections into a single one in the binary. However, starting with [LLVM 12](https://github.com/llvm/llvm-project/commit/ee5d1a04), the backend will also generate unique section names for exception handling, resulting in thousands of `.gcc_except_table.*` sections ending up in the final binary because some linkers like LLD don't currently merge or strip these EH sections (see discussion [here](https://reviews.llvm.org/D83655)). This can bloat the ELF headers and string table significantly in binaries that contain many functions.
The new option is analogous to Clang's `-fno-unique-section-names`, and instructs LLVM to generate the same `.text` and `.gcc_except_table` section for each function, resulting in a smaller final binary.
The motivation to add this new option was because we have a binary that ended up with so many ELF sections (over 65,000) that it broke some existing ELF tools, which couldn't handle so many sections.
Here's our old binary:
```
$ readelf --sections old.elf | head -1
There are 71746 section headers, starting at offset 0x2a246508:
$ readelf --sections old.elf | grep shstrtab
[71742] .shstrtab STRTAB 0000000000000000 2977204c ad44bb 00 0 0 1
```
That's an 11MB+ string table. Here's the new binary using this option:
```
$ readelf --sections new.elf | head -1
There are 43 section headers, starting at offset 0x29143ca8:
$ readelf --sections new.elf | grep shstrtab
[40] .shstrtab STRTAB 0000000000000000 29143acc 0001db 00 0 0 1
```
The whole binary size went down by over 20MB, which is quite significant.
Move back to linux builder on try builds
Apparently deleted the wrong line when trying to revert changes to try in #90100 which I now see still contains the do not merge commit -- maybe I forgot to force push the local changes I had pending or something.
r? `@pietroalbini`
Do not mention a reexported item if it's private
Fixes#90113
The _actual_ regression was introduced in #73652, then #88838 made it worse. This fixes the issue by not counting such an import as a candidate.
Use the "nice E0277 errors"[1] for `!Send` `impl Future` from foreign crate
Partly address #78543 by making the error quieter.
We don't have access to the `typeck` tables from foreign crates, so we
used to completely skip the new code when checking foreign crates. Now,
we carry on and don't provide as nice output (we don't clarify *what* is
making the `Future: !Send`), but at least we no longer emit a sea of
derived obligations in the output.
[1]: https://blog.rust-lang.org/inside-rust/2019/10/11/AsyncAwait-Not-Send-Error-Improvements.html
r? `@tmandry`
Partly address #78543 by making the error quieter.
We don't have access to the `typeck` tables from foreign crates, so we
used to completely skip the new code when checking foreign crates. Now,
we carry on and don't provide as nice output (we don't clarify *what* is
making the `Future: !Send`), but at least we no longer emit a sea of
derived obligations in the output.
[1]: https://blog.rust-lang.org/inside-rust/2019/10/11/AsyncAwait-Not-Send-Error-Improvements.html
Fix ICE when forgetting to `Box` a parameter to a `Self::func` call
Closes#90213 .
Assuming we can get the `DefId` of the receiver causes an ICE if the receiver is `Self`. We can just avoid doing this though.
Skip documentation for tier 2 targets on dist-x86_64-apple-darwin
I don't have an easy way to test this locally, but I believe it should work. Based on one log result should shave ~14 minutes off the dist-x86_64-apple builder (doesn't help with aarch64 dist or x86_64 test builder, so not actually decreasing total CI time most likely).
r? ```@pietroalbini```
CI: Enable overflow checks for test (non-dist) builds
They stay disabled for Apple builds though, which take the most time already due to running on slow hw.
Update the minimum external LLVM to 12
With this change, we'll have stable support for LLVM 12 and 13.
For reference, the previous increase to LLVM 10 was #83387,
and this replaces the pending increase to LLVM 11 in #90062.
r? `@nagisa` `@nikic`
Rollup of 5 pull requests
Successful merges:
- #85833 (Scrape code examples from examples/ directory for Rustdoc)
- #88041 (Make all proc-macro back-compat lints deny-by-default)
- #89829 (Consider types appearing in const expressions to be invariant)
- #90168 (Reset qualifs when a storage of a local ends)
- #90198 (Add caveat about changing parallelism and function call overhead)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
This fixes warning when building Rust and running tests:
```
warning: library kind `static-nobundle` has been superseded by specifying `-bundle` on library kind `static`. Try `static:-bundle`
warning: `rustc_llvm` (lib) generated 2 warnings (1 duplicate)
```
Reset qualifs when a storage of a local ends
Reset qualifs when a storage of a local ends to ensure that the local qualifs
are affected by the state from previous loop iterations only if the local is
kept alive.
The change should be forward compatible with a stricter handling of indirect
assignments, since storage dead invalidates all existing pointers to the local.
Consider types appearing in const expressions to be invariant
This is an approach to fix#80977.
Currently, a type parameter which is only used in a constant expression is considered bivariant and will trigger error E0392 *"parameter T is never used"*.
Here is a short example:
```rust
pub trait Foo {
const N: usize;
}
struct Bar<T: Foo>([u8; T::N])
where [(); T::N]:;
```
([playgound](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2015&gist=b51a272853f75925e72efc1597478aa5))
While it is possible to silence this error by adding a `PhantomData<T>` field, I think the better solution would be to make `T` invariant.
This would be analogous to the invariance constraints added for associated types.
However, I'm quite new to the compiler and unsure whether this is the right approach.
r? ``@varkor`` (since you authored #60058)
Make all proc-macro back-compat lints deny-by-default
The affected crates have had plenty of time to update.
By keeping these as lints rather than making them hard errors,
we ensure that downstream crates will still be able to compile,
even if they transitive depend on broken versions of the affected
crates.
This should hopefully discourage anyone from writing any
new code which relies on the backwards-compatibility behavior.
Implement coherence checks for negative trait impls
The main purpose of this PR is to be able to [move Error trait to core](https://github.com/rust-lang/project-error-handling/issues/3).
This feature is necessary to handle the following from impl on box.
```rust
impl From<&str> for Box<dyn Error> { ... }
```
Without having negative traits affect coherence moving the error trait into `core` and moving that `From` impl to `alloc` will cause the from impl to no longer compiler because of a potential future incompatibility. The compiler indicates that `&str` _could_ introduce an `Error` impl in the future, and thus prevents the `From` impl in `alloc` that would cause overlap with `From<E: Error> for Box<dyn Error>`. Adding `impl !Error for &str {}` with the negative trait coherence feature will disable this error by encoding a stability guarantee that `&str` will never implement `Error`, making the `From` impl compile.
We would have this in `alloc`:
```rust
impl From<&str> for Box<dyn Error> {} // A
impl<E> From<E> for Box<dyn Error> where E: Error {} // B
```
and this in `core`:
```rust
trait Error {}
impl !Error for &str {}
```
r? `@nikomatsakis`
This PR was built on top of `@yaahc` PR #85764.
Language team proposal: to https://github.com/rust-lang/lang-team/issues/96
to ensure that the local qualifs are affected by the state from previous
loop iterations only if the local is kept alive.
The change should be forward compatible with a stricter handling of
indirect assignments, since storage dead invalidates all existing
pointers to the local.
Make RSplit<T, P>: Clone not require T: Clone
This addresses a TODO comment. The behavior of `#[derive(Clone)]` *does* result in a `T: Clone` requirement. Playground example:
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=a8b1a9581ff8893baf401d624a53d35b
Add a manual `Clone` implementation, mirroring `Split` and `SplitInclusive`.
`(R)?SplitN(Mut)?` don't have any `Clone` implementations, but I'll leave that for its own pull request.
Add edition configuration to compiletest
This allows the compiletest configuration to set a default edition that can still be overridden with header annotations. Doing this will make it far easier for clippy to get our tests to the newest edition.
r? ```@Manishearth```
Implement -Z location-detail flag
This PR implements the `-Z location-detail` flag as described in https://github.com/rust-lang/rfcs/pull/2091 .
`-Z location-detail=val` controls what location details are tracked when using `caller_location`. This allows users to control what location details are printed as part of panic messages, by allowing them to exclude any combination of filenames, line numbers, and column numbers. This option is intended to provide users with a way to mitigate the size impact of `#[track_caller]`.
Some measurements of the savings of this approach on an embedded binary can be found here: https://github.com/rust-lang/rust/issues/70579#issuecomment-942556822 .
Closes#70580 (unless people want to leave that open as a place for discussion of further improvements).
This is my first real PR to rust, so any help correcting mistakes / understanding side effects / improving my tests is appreciated :)
I have one question: RFC 2091 specified this as a debugging option (I think that is what -Z implies?). Does that mean this can never be stabilized without a separate MCP? If so, do I need to submit an MCP now, or is the initial RFC specifying this option sufficient for this to be merged as is, and then an MCP would be needed for eventual stabilization?
add feature flag for `type_changing_struct_update`
This implements the PR0 part of the mentoring notes within #86618.
overrides the previous inactive #86646 pr.
r? ```@nikomatsakis```
Report fatal lexer errors in `--cfg` command line arguments
Fixes#89358. The erroneous behavior was apparently introduced by `@Mark-Simulacrum` in a678e31911; the idea is to silence individual parser errors and instead emit one catch-all error message after parsing. However, for the example in #89358, a fatal lexer error is created here:
edebf77e00/compiler/rustc_parse/src/lexer/mod.rs (L340-L349)
This fatal error aborts the compilation, and so the call to `new_parser_from_source_str()` never returns and the catch-all error message is never emitted. I have therefore changed the `SilentEmitter` to silence only non-fatal errors; with my changes, for the rustc invocation described in #89358:
```sh
rustc --cfg "abc\""
```
I get the following output:
```
error[E0765]: unterminated double quote string
|
= note: this error occurred on the command line: `--cfg=abc"`
```
Make new symbol mangling scheme default for compiler itself.
As suggest in https://github.com/rust-lang/rust/pull/89917#issuecomment-945888574, this PR enables the new symbol mangling scheme for the compiler itself. The standard library is still compiled using the legacy mangling scheme so that the new symbol format does not show up in user code (yet).
r? `@Mark-Simulacrum`
My change to use `Type::def_id()` (formerly `Type::def_id_full()`) in
more places caused some docs to show up that used to be missed by
rustdoc. Those docs contained unescaped square brackets, which triggered
linkcheck errors. This commit escapes the square brackets and adds this
particular instance to the linkcheck exception list.
It should be preferred over `def_id_no_primitives()`, so it should have
a shorter name. I also put it before `def_id_no_primitives()` so that it
shows up first in the docs.
The old name was confusing because it's easy to assume that using
`def_id()` is fine, but in some situations it's incorrect. In general,
`def_id_full()` should be preferred, so `def_id_full()` should have a
shorter name. That will happen in the next commit.
Now that it's only implemented for `Type`, using inherent methods
instead means that imports are no longer necessary. Also, `GetDefId` is
only meant to be used with `Type`, so it shouldn't be a trait.
Add some tests for const_generics_defaults
I think this covers some of the stuff required for stabilisation report, some of these tests are probably covering stuff we already have but it can't hurt to have more :)
r? ````@lcnr````
Fix const qualification when executed after promotion
The const qualification was so far performed before the promotion and
the implementation assumed that it will never encounter a promoted.
With `const_precise_live_drops` feature, checking for live drops is
delayed until after drop elaboration, which in turn runs after
promotion. so the assumption is no longer true. When evaluating
`NeedsNonConstDrop` it is now possible to encounter promoteds.
Use type base qualification for the promoted. It is a sound
approximation in general, and in the specific case of promoteds and
`NeedsNonConstDrop` it is precise.
Fixes#89938.
Update E0637 description to mention `&` w/o an explicit lifetime name
Deal with https://github.com/rust-lang/rust/issues/89824#issuecomment-941598647. Another solution would be splitting the error code into two as (I think) it's a bit unclear to users why they have the same error code.
Don't mark for loop iter expression as desugared
We typically don't mark spans of lowered things as desugared. This helps Clippy rightly discern when code is (not) from expansion. This was discovered by ``@flip1995`` at https://github.com/rust-lang/rust-clippy/pull/7789#issuecomment-939289501.
This addresses a TODO comment. The behavior of #[derive(Clone)]
*does* result in a T: Clone requirement.
Add a manual Clone implementation, matching Split and SplitInclusive.
Add test for line-number setting
The first commit updates the version of the package to be able to have multi-line commands (which looks much nicer for this test).
r? ````@jsha````
config: add the option to enable LLVM tests
I'm working on some LLVM patches in concert with a Rust patch, and it's
helping me quite a bit to have this as an option. It doesn't seem that
hard, so I figured I'd formalize it in x.py and send it upstream.
Add test for debug logging during incremental compilation
Debug logging during incremental compilation had been broken for some
time, until #89343 fixed it (among other things). Add a test so this is
less likely to break without being noticed. This test is nearly a copy
of the `src/test/ui/rustc-rust-log.rs` test, but tests debug logging in
the incremental compliation code paths.
rustdoc: Box some fields of `GenericParamDefKind` to reduce size
This change shrinks `GenericParamDef` from 120 to 56 bytes. `GenericParamDef` is
used a lot, so the extra indirection should hopefully be worth the size savings.
r? `@ghost`
Erase late-bound regions before computing vtable debuginfo name.
Fixes#90019.
The `msvc_enum_fallback()` for computing enum type names needs to access the memory layout of niche enums in order to determine the type name. `compute_debuginfo_vtable_name()` did not properly erase regions before computing type names which made memory layout computation ICE when encountering un-erased regions.
r? `@wesleywiser`
I think this code is getting L0, not L1 cache size, if I'm reading the Intel manual right. (I might not be.) Either way, the code comment and the printed message should match, whichever way is right. :)
Remove border-bottom from most docblocks.
Headings in the top-doc docblock still get a border-bottom due to a rule
that covers all h2, h3, and h4. Method docblocks are generally h5, and
so don't get a border-bottom anymore.
This fixes a problem where a sub-sub-heading within a method would have
a line that went all the way across the page, creating a division that
made that sub-sub-heading look much more important than it really is.
Fixes#90033
Demo at https://jacob.hoffman-andrews.com/rust/less-rule/std/string/struct.String.html
r? ``@GuillaumeGomez``
Update cargo
6 commits in c7957a74bdcf3b11e7154c1a9401735f23ebd484..7fbbf4e8f23e3c24b8afff541dcb17e53eb5ff88
2021-10-11 20:17:07 +0000 to 2021-10-19 02:16:48 +0000
- Make future-incompat-report output more user-friendly (rust-lang/cargo#9953)
- Fix fetching git repos after a force push. (rust-lang/cargo#9979)
- Add rustc-link-args to doctest build (rust-lang/cargo#9916)
- Add the start of a basic benchmarking suite. (rust-lang/cargo#9955)
- Use forms for issue templates. (rust-lang/cargo#9970)
- Add rust_metadata to SerializedPackage (rust-lang/cargo#9967)
Fix wrong niche calculation when 2+ niches are placed at the start
When the niche is at the start, existing code incorrectly uses 1 instead of count for subtraction.
Fix#90038
`@rustbot` label: T-compiler
