Include rmeta candidates in "multiple matching crates" error
Only dylib and rlib candidates were included in the error. I think the
reason is that at the time this error was originally implemented, rmeta
crate sources were represented different from dylib and rlib sources.
I wrote up more detailed analysis in [this comment][1].
The new version of the code is also a bit easier to read and should be
more robust to future changes since it uses `CrateSources::paths()`.
I also changed the code to sort the candidates to make the output deterministic;
added full stderr tests for the error; and added a long error code explanation.
[1]: https://github.com/rust-lang/rust/pull/88675#issuecomment-935282436
cc `@Mark-Simulacrum` `@jyn514`
Previously, there was no way to actually get binaries in
`build/$TARGET/stage1/bin` without building the standard library. This
makes it possible to build just the compiler. This can be useful when
the standard library isn't actually necessary for trying out your tests
(e.g. a bug that can be reproduced with only a `no_core` crate).
avoid suggesting the same name
sort candidates
fix a message
use `opt_def_id` instead of `def_id`
move `find_similarly_named_module_or_crate` to rustc_resolve/src/diagnostics.rs
Update cargo
7 commits in d56b42c549dbb7e7d0f712c51b39400260d114d4..c7957a74bdcf3b11e7154c1a9401735f23ebd484
2021-09-27 13:44:18 +0000 to 2021-10-11 20:17:07 +0000
- Add some more information to verbose version. (rust-lang/cargo#9968)
- Skip all `cargo fix` that tends to write to registry cache. (rust-lang/cargo#9938)
- Stabilize named profiles (rust-lang/cargo#9943)
- Update git2 (rust-lang/cargo#9963)
- Distinguish lockfile version req from normal dep in resolver error message (rust-lang/cargo#9847)
- nit: Allocated slightly bigger vec than needed (rust-lang/cargo#9954)
- Add shell completion for shorthand commands (rust-lang/cargo#9951)
Fix: non_exhaustive_omitted_patterns by filtering unstable and doc hidden variants
Fixes: #89042
Now that #86809 has been merged there are cases (std::io::ErrorKind) where unstable feature gated variants were included in warning/error messages when the feature was not turned on. This filters those variants out of the return of `SplitWildcard::new`.
Variants marked `doc(hidden)` are filtered out of the witnesses list in `Usefulness::apply_constructor`.
Probably worth a perf run 🤷 since this area can be sensitive.
The test is copied from `src/test/ui/crate-loading/crateresolve1.rs` and
its auxiliary tests. I added it to the `compile_fail` code example check
exemption list since it's hard if not impossible to reproduce this error
in a standalone code example.
Only dylib and rlib candidates were included in the error. I think the
reason is that at the time this error was originally implemented, rmeta
crate sources were represented different from dylib and rlib sources.
I wrote up more detailed analysis in [this comment][1].
The new version of the code is also a bit easier to read and should be
more robust to future changes since it uses `CrateSources::paths()`.
[1]: https://github.com/rust-lang/rust/pull/88675#issuecomment-935282436
`**node_modules` in a .gitignore is the same than
`*node_modules` or `*****node_modules`.
It matches every file whose name ends with `node_modules`,
including `not_node_modules`.
The intent here was obviously to have `**/node_modules`
which is the same than just `node_modules`.
fix minor spelling error in Poll::ready docs
Fixes minor spelling error in the proposed `Poll::ready` docs. Not that my opinion matters, but +1 on the original PR (#89651), it reads much nicer to me than the `ready!` macro.
Add #[must_use] to is_condition tests
I threw in `std::path::Path::has_root` for funsies.
A continuation of #89718.
Parent issue: #89692
r? ```@joshtriplett```
Add #[must_use] to non-mutating verb methods
These are methods that could be misconstrued to mutate their input, similar to #89694. I gave each one a different custom message.
I wrote that `upgrade` and `downgrade` don't modify the input pointers. Logically they don't, but technically they do...
Parent issue: #89692
r? ```@joshtriplett```
Remove built-in query cache_hit tracking
This was already only enabled in debug_assertions builds. Generally, it seems
like most use cases that would use this could also use the -Zself-profile flag
which also tracks cache hits (in all builds), and so the extra cfg's and such
are not really necessary.
This is largely just a small cleanup though, which primarily is intended to make
other changes easier by avoiding the need to deal with this field.
Add test cases for unstable variants
Add test cases for doc hidden variants
Move is_doc_hidden to method on TyCtxt
Add unstable variants test to reachable-patterns ui test
Rename reachable-patterns -> omitted-patterns
Add #[must_use] to From::from and Into::into
Risk of churn: **High**
Magic 8-Ball says: **Outlook not so good**
I figured I'd put this out there. If we don't do it now maybe we save it for a rainy day.
Parent issue: #89692
r? `@joshtriplett`
Speedup int log10 branchless
This is achieved with a branchless bit-twiddling implementation of the case x < 100_000, and using this as building block.
Benchmark on an Intel i7-8700K (Coffee Lake):
```
name old ns/iter new ns/iter diff ns/iter diff % speedup
num::int_log::u8_log10_predictable 165 169 4 2.42% x 0.98
num::int_log::u8_log10_random 438 423 -15 -3.42% x 1.04
num::int_log::u8_log10_random_small 438 423 -15 -3.42% x 1.04
num::int_log::u16_log10_predictable 633 417 -216 -34.12% x 1.52
num::int_log::u16_log10_random 908 471 -437 -48.13% x 1.93
num::int_log::u16_log10_random_small 945 471 -474 -50.16% x 2.01
num::int_log::u32_log10_predictable 1,496 1,340 -156 -10.43% x 1.12
num::int_log::u32_log10_random 1,076 873 -203 -18.87% x 1.23
num::int_log::u32_log10_random_small 1,145 874 -271 -23.67% x 1.31
num::int_log::u64_log10_predictable 4,005 3,171 -834 -20.82% x 1.26
num::int_log::u64_log10_random 1,247 1,021 -226 -18.12% x 1.22
num::int_log::u64_log10_random_small 1,265 921 -344 -27.19% x 1.37
num::int_log::u128_log10_predictable 39,667 39,579 -88 -0.22% x 1.00
num::int_log::u128_log10_random 6,456 6,696 240 3.72% x 0.96
num::int_log::u128_log10_random_small 4,108 3,903 -205 -4.99% x 1.05
```
Benchmark on an M1 Mac Mini:
```
name old ns/iter new ns/iter diff ns/iter diff % speedup
num::int_log::u8_log10_predictable 143 130 -13 -9.09% x 1.10
num::int_log::u8_log10_random 375 325 -50 -13.33% x 1.15
num::int_log::u8_log10_random_small 376 325 -51 -13.56% x 1.16
num::int_log::u16_log10_predictable 500 322 -178 -35.60% x 1.55
num::int_log::u16_log10_random 794 405 -389 -48.99% x 1.96
num::int_log::u16_log10_random_small 1,035 405 -630 -60.87% x 2.56
num::int_log::u32_log10_predictable 1,144 894 -250 -21.85% x 1.28
num::int_log::u32_log10_random 832 786 -46 -5.53% x 1.06
num::int_log::u32_log10_random_small 832 787 -45 -5.41% x 1.06
num::int_log::u64_log10_predictable 2,681 2,057 -624 -23.27% x 1.30
num::int_log::u64_log10_random 1,015 806 -209 -20.59% x 1.26
num::int_log::u64_log10_random_small 1,004 795 -209 -20.82% x 1.26
num::int_log::u128_log10_predictable 56,825 56,526 -299 -0.53% x 1.01
num::int_log::u128_log10_random 9,056 8,861 -195 -2.15% x 1.02
num::int_log::u128_log10_random_small 1,528 1,527 -1 -0.07% x 1.00
```
The 128 bit case remains ridiculously slow because llvm fails to optimize division by a constant 128-bit value to multiplications. This could be worked around but it seems preferable to fix this in llvm.
From u32 up, table lookup (like suggested [here](https://github.com/rust-lang/rust/issues/70887#issuecomment-881099813)) is still faster, but requires a hardware `leading_zeros` to be viable, and might clog up the cache.
