The previous behaviour ignored slice lengths above a certain length
because it could not do otherwise. We now have VarLenSlice however, that
can represent the ignored lengths to make the algorithm more consistent.
This does not change the correctness of the algorithm, but makes it
easier to reason about.
As a nice side-effect, exhaustiveness errors have improved: they now
capture all missing lengths instead of only the shortest.
Note that where we previously ran `max_slice_len` with input having not
only matrix.heads() but also v.head(). Now we run it on matrix.heads()
only, but also take into account the currently processed constructor.
This preserves behavior since `pat_constructors` returns only one
constructor in the case that is of interest for us.
This improves error messages by indicating when slices above a certain
lengths have not been matched. Previously, we would only report examples
of such lengths, but of course never all of them.
If item.span is part of a macro invocation, this has several downstream
implications. To name two that were found while working on this:
- The dead-code error gets annotated with a "in this macro invocation"
- Some errors get canceled if they refer to remote crates
Ideally, we should annotate item.ident.span with the same macro info,
but this is a larger change (see: #66095), so for now we just fall
back to the old behavior if this item was generated by a macro.
I use span.macro_backtrace().len() to detect if it's part of a macro,
because that (among other things) is what is used by the code which
adds the "in this macro invocation" annotations mentioned above.
clean highlightSourceLines code
This is the first part of https://github.com/rust-lang/rust/issues/66046. Now that I've splitted the hashchange stuff and the source code lines highlighting, I'll be able to fix the whole issue once and for all.
r? @kinnison
Don't double-count `simd_shuffle` promotion candidates
Resolves#66016.
The `#[rustc_args_required_const]` attribute was added to `simd_shuffle*` in rust-lang/stdarch#825. This caused `promote_consts` to double-count its second argument when recording promotion candidates, which caused the promotion candidate compatibility check to fail.
Once `stdarch` is updated in-tree to include rust-lang/stdarch#825, all special logic around `simd_shuffle` can and should be removed.
Allow specifying LLVM's MCTargetOptions::ABIName in target specification files
This addresses #65024, as it allows RISC-V target specification files to set `"llvm-abiname": "lp64d"`.
Other languages (read: C) usually expose this codegen parameter under a compiler argument like `-mabi=<XYZ>`.
Improve MaybeUninit::get_{ref,mut} documentation
As mentioned in https://github.com/rust-lang/rust/issues/63568#issuecomment-544106668, `MaybeUninit`'s `get_{ref,mut}` documentation is lacking, so this PR attempts to fix that.
That being said, and as @RalfJung mentions in that thread,
> In particular, we should clarify that all the UB rules for these methods equally apply when calling the raw ptr methods and creating a reference manually.
these other docs also need to be improved, which I can do in this PR ~~(hence the `[WIP]`)~~.
Finally, since all these documentations are related to clearly establishing when dealing with uninitialized memory which patterns are known to be sound and which patterns are currently UB (that is, until, if ever, the rules around references to unintialized integers get relaxed, this documentation will treat them as UB, and advise against such patterns (_e.g._, it is not possible to use uninitialized buffers with the `Read` API)), I think that adding even more examples to the main documentation of `MaybeUninit` inherent definition wouldn't hurt either.
___
- [Rendered](http://dreamy-ritchie-99d637.netlify.com/core/mem/union.maybeuninit#method.get_ref)
Rollup of 10 pull requests
Successful merges:
- #65136 (Update codegen option documentation.)
- #65574 (docs: improve disclaimer regarding LinkedList)
- #65720 (Add FFI bindings for LLVM's Module::getInstructionCount())
- #65905 ([doc] fixes for unix/vxworks `OpenOptionsExt::mode`)
- #65962 (Fix logic in example.)
- #66019 (Improved std::iter::Chain documentation)
- #66038 (doc(str): show example of chars().count() under len())
- #66042 (Suggest correct code when encountering an incorrect trait bound referencing the current trait)
- #66073 (Do not needlessly write-lock)
- #66096 (Add a failing UI test for multiple loops of all kinds in a `const`)
Failed merges:
r? @ghost
Add a failing UI test for multiple loops of all kinds in a `const`
This simply demonstrates the current behavior and ensures we don't allow anything by accident.
The new const checker will be able to improve the diagnostics here. While working on it, I didn't see very many tests with non-`while` loops in a `const`, and there were no tests with multiple loops.
Suggest correct code when encountering an incorrect trait bound referencing the current trait
Fixes#65985 and also improves the suggestion for code like this:
```
trait Grab {
type Value;
fn grab(&self) -> Grab::Value;
}
```
To suggest `<Self as Grab>::Value`.
I wasn't sure which of the syntax versions is better (`<Self as ..>::` vs `Self::`), so I used the former simply because it was less change to the existing code.
r? @estebank
doc(str): show example of chars().count() under len()
the docs are great at explaining that .len() isn't like in other
languages but stops short of explaining how to get the character length.
Improved std::iter::Chain documentation
Replaces `strings two iterators` by `links two iterators` in `std::iter::Chain` documentation.
I didn't find any meaning of `strings` which can be evaluated as `links` or `joins`.
I don't think that `std::iter:Chain` works as a stringer or plays billiards. (https://www.lexico.com/en/definition/string).
Add FFI bindings for LLVM's Module::getInstructionCount()
Just to make it usable for profiling and such inside
rustc itself. It was vaguely useful in
https://wiki.alopex.li/WhereRustcSpendsItsTime and I figured
I might as well upstream it; I may or may not ever get around
to doing more with it (hopefully I will), but it may be useful
for others.
