Correctly get source for metatdata-only crate type
Closes#40535
However, I'm not sure how to approach writing a regression test since I'm still working on a reduced test case from the code that caused the ICE in the first place. It's not enough to have an unknown `extern crate` in a metadata crate, it depends on a few extra arguments but I'm not sure which yet.
Also replaced the `unwrap()` with a more informative `expect()`.
r? @jseyfried
Introduce HirId, a replacement for ast::NodeId after lowering to HIR
This is the first step towards implementing #40303. This PR introduces the `HirId` type and generates a `HirId` for everything that would be assigned one (i.e. stuff in the HIR), but the HIR data types still use `NodeId` for now. Changing that is a big refactoring that I want to do in a separate PR.
A `HirId` uniquely identifies a node in the HIR of the current crate. It is composed of the `owner`, which is the `DefIndex` of the directly enclosing `hir::Item`, `hir::TraitItem`, or `hir::ImplItem` (i.e. the closest "item-like"), and the `local_id` which is unique within the given owner.
This PR is also running a number of consistency checks for the generated `HirId`s:
- Does `NodeId` in the HIR have a corresponding `HirId`?
- Is the `owner` part of each `HirId` consistent with its position in the HIR?
- Do the numerical values of the `local_id` part all lie within a dense range of integers?
cc @rust-lang/compiler
r? @eddyb or @nikomatsakis
Teach rustc --emit=mir
I'm opening this PR to discuss:
1. Is this a good idea?
1. Is this a good implementation?
I'm sure people will have opinions on both points!
This spawned from https://github.com/rust-lang/rust/issues/31847#issuecomment-279179057, so I figured a prototype implementation could help provide a seed to talk about.
Nit: LLVM & Clang latest version is 4.0
Small nit: since latest Clang version is 4.0 it's nice to reflect this in the documentation.
Also, I couldn't find anything, but there might be any hard-coded check that Clang version matches "3.X" anywhere in the build system; if there is one, it'd be great to bump that one too.
str: Make docs consistently punctuated
Every so slightly pointless one character PR, but this was driving me nuts while reading the docs a moment ago (all the [other public structs](https://doc.rust-lang.org/std/str/index.html#structs) have descriptions that end in a full-stop).
Make the filenames of .stamp files generated by compiletest shorter
Otherwise we run into filename length limitations on some file systems. See https://bugs.launchpad.net/ecryptfs/+bug/344878 for an example where we only can have ~145 characters for filenames.
r? @alexcrichton
appveyor: Use Ninja to build LLVM on MinGW
I have a suspicion that MinGW's make is the cause of #40546 rather than anything
else, but that's purely a suspicion without any facts to back it up. In any case
we'll eventually be moving the MSVC build over to Ninja in order to leverage
sccache regardless, so this commit simply jumpstarts that process by downloading
Ninja for use by MinGW anyway.
I'm not sure if this closes#40546 for real, but this is my current best shot at
closing it out, so...
Closes#40546
Forbid conflicts between macros 1.0 exports and macros 2.0 exports
This PR forbids for conflicts between `#[macro_export]`/`#[macro_reexport]` macro exports and `pub use` macro exports. For example,
```rust
// crate A:
pub use macros::foo;
//^ This is allowed today, will be forbidden by this PR.
// crate B:
extern crate A; // This triggers a confusing error today.
use A::foo; // This could refer to refer to either macro export in crate A.
```
r? @nrc
HirId has a more stable representation than NodeId, meaning that
modifications to one item don't influence (part of) the IDs within
other items. The other part is a DefIndex for which there already
is a way of stable hashing and persistence.
This commit introduces the HirId type and generates a HirId for
every NodeId during HIR lowering, but the resulting values are
not yet used anywhere, except in consistency checks.
I have a suspicion that MinGW's make is the cause of #40546 rather than anything
else, but that's purely a suspicion without any facts to back it up. In any case
we'll eventually be moving the MSVC build over to Ninja in order to leverage
sccache regardless, so this commit simply jumpstarts that process by downloading
Ninja for use by MinGW anyway.
I'm not sure if this closes#40546 for real, but this is my current best shot at
closing it out, so...
Closes#40546
Implement feature sort_unstable
Tracking issue for the feature: #40585
This is essentially integration of [pdqsort](https://github.com/stjepang/pdqsort) into libcore.
There's plenty of unsafe blocks to review. The heart of pdqsort is `fn partition_in_blocks` and is probably the most challenging function to understand. It requires some patience, but let me know if you find it too difficult - comments could always be improved.
#### Changes
* Added `sort_unstable` feature.
* Tweaked insertion sort constants for stable sort. Sorting integers is now up to 5% slower, but sorting big elements is much faster (in particular, `sort_large_big_random` is 35% faster). The old constants were highly optimized for sorting integers, so overall the configuration is more balanced now. A minor regression in case of integers is forgivable as we recently had performance improvements (#39538) that completely make up for it.
* Removed some uninteresting sort benchmarks.
* Added a new sort benchmark for string sorting.
#### Benchmarks
The following table compares stable and unstable sorting:
```
name stable ns/iter unstable ns/iter diff ns/iter diff %
slice::sort_large_ascending 7,240 (11049 MB/s) 7,380 (10840 MB/s) 140 1.93%
slice::sort_large_big_random 1,454,138 (880 MB/s) 910,269 (1406 MB/s) -543,869 -37.40%
slice::sort_large_descending 13,450 (5947 MB/s) 10,895 (7342 MB/s) -2,555 -19.00%
slice::sort_large_mostly_ascending 204,041 (392 MB/s) 88,639 (902 MB/s) -115,402 -56.56%
slice::sort_large_mostly_descending 217,109 (368 MB/s) 99,009 (808 MB/s) -118,100 -54.40%
slice::sort_large_random 477,257 (167 MB/s) 346,028 (231 MB/s) -131,229 -27.50%
slice::sort_large_random_expensive 21,670,537 (3 MB/s) 22,710,238 (3 MB/s) 1,039,701 4.80%
slice::sort_large_strings 6,284,499 (38 MB/s) 6,410,896 (37 MB/s) 126,397 2.01%
slice::sort_medium_random 3,515 (227 MB/s) 3,327 (240 MB/s) -188 -5.35%
slice::sort_small_ascending 42 (1904 MB/s) 41 (1951 MB/s) -1 -2.38%
slice::sort_small_big_random 503 (2544 MB/s) 514 (2490 MB/s) 11 2.19%
slice::sort_small_descending 72 (1111 MB/s) 69 (1159 MB/s) -3 -4.17%
slice::sort_small_random 369 (216 MB/s) 367 (217 MB/s) -2 -0.54%
```
Interesting cases:
* Expensive comparison function and string sorting - it's a really close race, but timsort performs a slightly smaller number of comparisons. This is a natural difference of bottom-up merging versus top-down partitioning.
* `large_descending` - unstable sort is faster, but both sorts should have equivalent performance. Both just check whether the slice is descending and if so, they reverse it. I blame LLVM for the discrepancy.
r? @alexcrichton
