Instead of tracking the "cause" of each bit that gets added, try to
recover that by walking outlives relationships. This is currently
imprecise, since it ignores the "point" where the outlives relationship
is incurred -- but that's ok, since we're about to stop considering that
overall in a later commit. This does seem to affect one error message
negatively, I didn't dig *too* hard to find out why.
Refactor auto trait handling in librustdoc to be accessible from librustc.
These commits transfer some of the functionality introduced in https://github.com/rust-lang/rust/pull/47833 to librustc with the intention of making the tools to work with auto traits accessible to third-party code, for example [rust-semverver](https://github.com/rust-lang-nursery/rust-semverver).
Some rough edges remain, and I'm certain some of the FIXMEs introduced will need some discussion, most notably the fairly ugly overall approach to pull out the core logic into librustc, which was previously fairly tightly coupled with various bits and bobs from librustdoc.
cc @Aaron1011
Rollup of 11 pull requests
Successful merges:
- #49988 (Mention Result<!, E> in never docs.)
- #50148 (turn `ManuallyDrop::new` into a constant function)
- #50456 (Update the Cargo submodule)
- #50460 (Make `String::new()` const)
- #50464 (Remove some transmutes)
- #50505 (Added regression function match value test)
- #50511 (Add some explanations for #[must_use])
- #50525 (Optimize string handling in lit_token().)
- #50527 (Cleanup a `use` in a raw_vec test)
- #50539 (Add more logarithm constants)
- #49523 (Update RELEASES.md for 1.26.0)
Failed merges:
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%.
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
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
Use ManuallyDrop instead of Option in BinaryHeap Hole implementation
The Option is always Some until drop, where it becomes None. Make this more explicit and avoid unwraps by using ManuallyDrop.
This change should be performance-neutral as LLVM already optimizes the unwraps away in the inlined code. However I've seen this pattern copied from here to other crates where it is not optimized away, so I think it would be good to change it.
