Micro-optimize the heck out of LEB128 reading and writing.
This commit makes the following writing improvements:
- Removes the unnecessary `write_to_vec` function.
- Reduces the number of conditions per loop from 2 to 1.
- Avoids a mask and a shift on the final byte.
And the following reading improvements:
- Removes an unnecessary type annotation.
- Fixes a dangerous unchecked slice access. Imagine a slice `[0x80]` --
the current code will read past the end of the slice some number of
bytes. The bounds check at the end will subsequently trigger, unless
something bad (like a crash) happens first. The cost of doing bounds
check in the loop body is negligible.
- Avoids a mask on the final byte.
And the following improvements for both reading and writing:
- Changes `for` to `loop` for the loops, avoiding an unnecessary
condition on each iteration. This also removes the need for
`leb128_size`.
All of these changes give significant perf wins, up to 5%.
r? @michaelwoerister
This commit makes the following writing improvements:
- Removes the unnecessary `write_to_vec` function.
- Reduces the number of conditions per loop from 2 to 1.
- Avoids a mask and a shift on the final byte.
And the following reading improvements:
- Removes an unnecessary type annotation.
- Fixes a dangerous unchecked slice access. Imagine a slice `[0x80]` --
the current code will read past the end of the slice some number of
bytes. The bounds check at the end will subsequently trigger, unless
something bad (like a crash) happens first. The cost of doing bounds
check in the loop body is negligible.
- Avoids a mask on the final byte.
And the following improvements for both reading and writing:
- Changes `for` to `loop` for the loops, avoiding an unnecessary
condition on each iteration. This also removes the need for
`leb128_size`.
All of these changes give significant perf wins, up to 5%.
`description` has been documented as soft-deprecated since 1.27.0 (17
months ago). There is no longer any reason to call it or implement it.
This commit:
- adds #[rustc_deprecated(since = "1.41.0")] to Error::description;
- moves description (and cause, which is also deprecated) below the
source and backtrace methods in the Error trait;
- reduces documentation of description and cause to take up much less
vertical real estate in rustdocs, while preserving the example that
shows how to render errors without needing to call description;
- removes the description function of all *currently unstable* Error
impls in the standard library;
- marks #[allow(deprecated)] the description function of all *stable*
Error impls in the standard library;
- replaces miscellaneous uses of description in example code and the
compiler.
Stabilize the type_name intrinsic in core::any
Stabilize `type_name` in `core::any`.
Closesrust-lang/rfcs#1428
FCP completed over there.
`RELEASES.md`: Prefer T-libs for categorization.
Now that procedural macros no longer link transitively to libsyntax,
this shouldn't be needed any more! This commit is an experiment in
removing all dynamic libraries from rustc except for librustc_driver
itself. Let's see how far we can get with that!
The errors are either:
- The meta-variable used in the right-hand side is not bound (or defined) in the
left-hand side.
- The meta-variable used in the right-hand side does not repeat with the same
kleene operator as its binder in the left-hand side. Either it does not repeat
enough, or it uses a different operator somewhere.
This change should have no semantic impact.
Replaced linear token counting macros with optimized implementation
There are currently two distinct token-counting macros in the source. Both implement the trivial algorithm, with linear complexity. They may or may not be adequate for their use case, but considering that other people are probably going to copy and paste them whenever they need a token-counting macro, I replaced them with an optimized implementation with logarithmic complexity.
Cosmetic improvements to doc comments
This has been factored out from https://github.com/rust-lang/rust/pull/58036 to only include changes to documentation comments (throughout the rustc codebase).
r? @steveklabnik
Once you're happy with this, maybe we could get it through with r=1, so it doesn't constantly get invalidated? (I'm not sure this will be an issue, but just in case...) Anyway, thanks for your advice so far!
