Add some explanations for #[must_use]
`#[must_use]` can be given a string argument which is shown whilst warning for things.
We should add a string argument to most of the user-exposed ones.
I added these for everything but the operators, mostly because I'm not sure what to write there or if we need anything there.
Add more logarithm constants
Right now, we have `ln(2)` and `ln(10)`, but only `log2(e)` and `log10(e)`. This also adds `log2(10)` and `log10(2)` for consistency.
Optimize string handling in lit_token().
In the common case, the string value in a string literal Token is the
same as the string value in a string literal LitKind. (The exception is
when escapes or \r are involved.) This patch takes advantage of that to
avoid calling str_lit() and re-interning the string in that case. This
speeds up incremental builds for a few of the rustc-benchmarks, the best
by 3%.
Benchmarks that got a speedup of 1% or more:
```
coercions
avg: -1.1% min: -3.5% max: 0.4%
regex-check
avg: -1.2% min: -1.5% max: -0.6%
futures-check
avg: -0.9% min: -1.4% max: -0.3%
futures
avg: -0.8% min: -1.3% max: -0.3%
futures-opt
avg: -0.7% min: -1.2% max: -0.1%
regex
avg: -0.5% min: -1.2% max: -0.1%
regex-opt
avg: -0.5% min: -1.1% max: -0.1%
hyper-check
avg: -0.7% min: -1.0% max: -0.3%
```
In the common case, the string value in a string literal Token is the
same as the string value in a string literal LitKind. (The exception is
when escapes or \r are involved.) This patch takes advantage of that to
avoid calling str_lit() and re-interning the string in that case. This
speeds up incremental builds for a few of the rustc-benchmarks, the best
by 3%.
Also remove some unnecessary debug_assert! when creating the shared
root, since the root should be stored in the rodata and thus be
impossible to accidentally modify.
lint: deny incoherent_fundamental_impls by default
Warn the ecosystem of the pending intent-to-disallow in #49799.
There are 4 ICEs on my machine, look unrelated (having happened before in https://github.com/rust-lang/rust/issues/49146#issuecomment-384473523)
```rust
thread 'main' panicked at 'assertion failed: position <= slice.len()', libserialize/leb128.rs:97:1
```
```
[run-pass] run-pass/allocator/xcrate-use2.rs
[run-pass] run-pass/issue-12133-3.rs
[run-pass] run-pass/issue-32518.rs
[run-pass] run-pass/trait-default-method-xc-2.rs
```
r? @nikomatsakis
This splits into_slices() into into_key_slice() and into_val_slice(). While the
extra calls would get optimized out, this is a useful semantic change since we
call keys() while iterating, and we don't want to construct and out-of-bounds
val() pointer in the process if we happen to be pointing to the shared static
root.
This also paves the way for doing the alignment handling conditional differently
for the keys and values.
This gives a pointer to that static empty node instead of allocating
a new node, and then whenever inserting makes sure that the root
isn't that empty node.
This way we can safely statically allocate a LeafNode to use as the
placeholder before allocating, and any type accessing it will be able to
access the metadata at the same offset.
idiom lints for removing `extern crate`
Based off of https://github.com/rust-lang/rust/pull/49789
This contains two lints:
- One that suggests replacing pub extern crates with pub use, and removing non-pub extern crates entirely
- One that suggests rewriting `use modulename::...::cratename::foo` as `cratename::foo`
The latter is a bit tricky to emit suggestions for; for one this involves splicing spans (never a good idea), and it also won't be able to correctly
handle `use module::{cratename, foo}` and use-trees. I'm not sure how to proceed here. Currently it doesn't suggest anything at all.
Perhaps we can go the other way and suggest removal of all extern crates _except_ those used through modules (stash node ids somewhere) and suggest replacing those with `<visibility> use`?
r? @nikomatsakis
fixes https://github.com/rust-lang/rust/issues/48719
