| Age | Commit message (Collapse) | Author | Lines |
|
|
|
- Sort dependencies and features sections.
- Add `tidy` markers to the sorted sections so they stay sorted.
- Remove empty `[lib`] sections.
- Remove "See more keys..." comments.
Excluded files:
- rustc_codegen_{cranelift,gcc}, because they're external.
- rustc_lexer, because it has external use.
- stable_mir, because it has external use.
|
|
|
|
|
|
The new version was already added to the tree as an indirect dependency
in #113046, but now our direct dependents are using it too.
|
|
Introduce `DynSend` and `DynSync` auto trait for parallel compiler
part of parallel-rustc #101566
This PR introduces `DynSend / DynSync` trait and `FromDyn / IntoDyn` structure in rustc_data_structure::marker. `FromDyn` can dynamically check data structures for thread safety when switching to parallel environments (such as calling `par_for_each_in`). This happens only when `-Z threads > 1` so it doesn't affect single-threaded mode's compile efficiency.
r? `@cjgillot`
|
|
|
|
|
|
|
|
This avoids `rustc_data_structures` depending on `serde_json` which
allows it to be compiled much earlier, unlocking most of rustc.
|
|
|
|
|
|
|
|
time-passes`
|
|
|
|
- only borrow the refcell once per loop
- avoid complex matches to reduce branch paths in the hot loop
- use a by-ref fast path that avoids mutations at the expense of having false negatives
|
|
To get the small performance improvements from
https://github.com/rust-lang/ena/pull/43.
|
|
Use a lock-free datastructure for source_span
follow up to the perf regression in https://github.com/rust-lang/rust/pull/105462
The main regression is likely the CStore, but let's evaluate the perf impact of this on its own
|
|
|
|
Because 0.2.10 added supports for `ThinVec::splice`, and 0.2.12 is the
latest release.
|
|
|
|
This helps with `*-windows-gnullvm` targets
|
|
|
|
|
|
`rustc_data_structures::thin_vec::ThinVec` looks like this:
```
pub struct ThinVec<T>(Option<Box<Vec<T>>>);
```
It's just a zero word if the vector is empty, but requires two
allocations if it is non-empty. So it's only usable in cases where the
vector is empty most of the time.
This commit removes it in favour of `thin_vec::ThinVec`, which is also
word-sized, but stores the length and capacity in the same allocation as
the elements. It's good in a wider variety of situation, e.g. in enum
variants where the vector is usually/always non-empty.
The commit also:
- Sorts some `Cargo.toml` dependency lists, to make additions easier.
- Sorts some `use` item lists, to make additions easier.
- Changes `clean_trait_ref_with_bindings` to take a
`ThinVec<TypeBinding>` rather than a `&[TypeBinding]`, because this
avoid some unnecessary allocations.
|
|
This removes the last dependencies on hashbrown 0.11.
|
|
This pulls in https://github.com/servo/rust-smallvec/pull/282, which
gives some small wins for rustc.
|
|
|
|
feature gives change of builded crates: 238 -> 224.
|
|
|
|
Update `indexmap` to 1.8.0.
Bless test
|
|
|
|
|
|
|
|
|
|
|
|
Since RFC 3052 soft deprecated the authors field anyway, hiding it from
crates.io, docs.rs, and making Cargo not add it by default, and it is
not generally up to date/useful information, we should remove it from
crates in this repo.
|
|
rustc_data_structures has a dependency on crossbeam-utils but never uses
it. It appears to have originally had this dependency in order to set
the "nightly" feature; however, its other dependencies use a different
version of crossbeam-utils, so this doesn't actually affect anything.
Furthermore, in current crossbeam-utils, the "nightly" feature has
become a no-op.
|
|
|
|
don't enable parking_lot nightly features
Having the compiler itself depend on external libraries that use nightly features can lead to "fun" bootstrap situations. Within the rustc repo we use `cfg(bootstrap)` to resolve those, but that is not a reasonable option for external dependencies.
So I propose we stop enabling the "nightly" feature of `parking_lot` here. In my experiments, this then indeed leads to the feature not being enabled (i.e., nothing else enables it), and everything still builds. However, this means parking_lot's `RwLock` will no longer have hardware lock elision for readers -- I hope that is okay to lose in exchange for less bootstrap brain twisting. ;)
Cc `@Amanieu`
|
|
|
|
|
|
|
|
With the arrival of min const generics, many alt-vec libraries have
updated to use it in some way and arrayvec is no exception. Use the
latest with minor refactoring.
Also, rustc_workspace_hack is the only user of smallvec 0.6 in the
entire tree, so drop it.
|
|
This wrapper implements StableAddress and falls back to directly reading
the file on wasm32
|
|
This pulls in rust-lang/rustc-rayon#8 to fix #81425. (h/t @ammaraskar)
That revealed weak constraints on `rustc_arena::DropArena`, because its
`DropType` was holding type-erased raw pointers to generic `T`. We can
implement `Send` for `DropType` (under `cfg(parallel_compiler)`) by
requiring all `T: Send` before they're type-erased.
|
|
This version adds the ability to use `rdpmc` hardware-based performance
counters instead of wall-clock time for measuring duration. This also
introduces a dependency on the `perf-event-open-sys` crate on Linux
which is used when using hardware counters.
|
|
|
|
|
|
cache types during normalization
partially fixes #75992
reduces the following test from 14 to 3 seconds locally.
cc `@Mark-Simulacrum` would it make sense to add that test to `perf`?
```rust
#![recursion_limit="2048"]
#![type_length_limit="112457564"]
pub async fn h0(v: &String, x: &u64) { println!("{} {}", v, x) }
pub async fn h1(v: &String, x: &u64) { h0(v, x).await }
pub async fn h2(v: &String, x: &u64) { h1(v, x).await }
pub async fn h3(v: &String, x: &u64) { h2(v, x).await }
pub async fn h4(v: &String, x: &u64) { h3(v, x).await }
pub async fn h5(v: &String, x: &u64) { h4(v, x).await }
pub async fn h6(v: &String, x: &u64) { h5(v, x).await }
pub async fn h7(v: &String, x: &u64) { h6(v, x).await }
pub async fn h8(v: &String, x: &u64) { h7(v, x).await }
pub async fn h9(v: &String, x: &u64) { h8(v, x).await }
pub async fn h10(v: &String, x: &u64) { h9(v, x).await }
pub async fn h11(v: &String, x: &u64) { h10(v, x).await }
pub async fn h12(v: &String, x: &u64) { h11(v, x).await }
pub async fn h13(v: &String, x: &u64) { h12(v, x).await }
pub async fn h14(v: &String, x: &u64) { h13(v, x).await }
pub async fn h15(v: &String, x: &u64) { h14(v, x).await }
pub async fn h16(v: &String, x: &u64) { h15(v, x).await }
pub async fn h17(v: &String, x: &u64) { h16(v, x).await }
pub async fn h18(v: &String, x: &u64) { h17(v, x).await }
pub async fn h19(v: &String, x: &u64) { h18(v, x).await }
macro_rules! async_recursive {
(29, $inner:expr) => { async { async_recursive!(28, $inner) }.await };
(28, $inner:expr) => { async { async_recursive!(27, $inner) }.await };
(27, $inner:expr) => { async { async_recursive!(26, $inner) }.await };
(26, $inner:expr) => { async { async_recursive!(25, $inner) }.await };
(25, $inner:expr) => { async { async_recursive!(24, $inner) }.await };
(24, $inner:expr) => { async { async_recursive!(23, $inner) }.await };
(23, $inner:expr) => { async { async_recursive!(22, $inner) }.await };
(22, $inner:expr) => { async { async_recursive!(21, $inner) }.await };
(21, $inner:expr) => { async { async_recursive!(20, $inner) }.await };
(20, $inner:expr) => { async { async_recursive!(19, $inner) }.await };
(19, $inner:expr) => { async { async_recursive!(18, $inner) }.await };
(18, $inner:expr) => { async { async_recursive!(17, $inner) }.await };
(17, $inner:expr) => { async { async_recursive!(16, $inner) }.await };
(16, $inner:expr) => { async { async_recursive!(15, $inner) }.await };
(15, $inner:expr) => { async { async_recursive!(14, $inner) }.await };
(14, $inner:expr) => { async { async_recursive!(13, $inner) }.await };
(13, $inner:expr) => { async { async_recursive!(12, $inner) }.await };
(12, $inner:expr) => { async { async_recursive!(11, $inner) }.await };
(11, $inner:expr) => { async { async_recursive!(10, $inner) }.await };
(10, $inner:expr) => { async { async_recursive!(9, $inner) }.await };
(9, $inner:expr) => { async { async_recursive!(8, $inner) }.await };
(8, $inner:expr) => { async { async_recursive!(7, $inner) }.await };
(7, $inner:expr) => { async { async_recursive!(6, $inner) }.await };
(6, $inner:expr) => { async { async_recursive!(5, $inner) }.await };
(5, $inner:expr) => { async { async_recursive!(4, $inner) }.await };
(4, $inner:expr) => { async { async_recursive!(3, $inner) }.await };
(3, $inner:expr) => { async { async_recursive!(2, $inner) }.await };
(2, $inner:expr) => { async { async_recursive!(1, $inner) }.await };
(1, $inner:expr) => { async { async_recursive!(0, $inner) }.await };
(0, $inner:expr) => { async { h19(&String::from("owo"), &0).await; $inner }.await };
}
async fn f() {
async_recursive!(14, println!("hello"));
}
fn main() {
let _ = f();
}
```
r? `@eddyb` requires a perf run.
|