about summary refs log tree commit diff
path: root/compiler/rustc_data_structures/src/sync.rs
AgeCommit message (Collapse)AuthorLines
2024-11-12Delete the `cfg(not(parallel))` serial compilerNoratrieb-237/+45
Since it's inception a long time ago, the parallel compiler and its cfgs have been a maintenance burden. This was a necessary evil the allow iteration while not degrading performance because of synchronization overhead. But this time is over. Thanks to the amazing work by the parallel working group (and the dyn sync crimes), the parallel compiler has now been fast enough to be shipped by default in nightly for quite a while now. Stable and beta have still been on the serial compiler, because they can't use `-Zthreads` anyways. But this is quite suboptimal: - the maintenance burden still sucks - we're not testing the serial compiler in nightly Because of these reasons, it's time to end it. The serial compiler has served us well in the years since it was split from the parallel one, but it's over now. Let the knight slay one head of the two-headed dragon!
2024-09-26Use `&raw` in the compilerJosh Stone-1/+1
Like #130865 did for the standard library, we can use `&raw` in the compiler now that stage0 supports it. Also like the other issue, I did not make any doc or test changes at this time.
2024-07-29Reformat `use` declarations.Nicholas Nethercote-2/+2
The previous commit updated `rustfmt.toml` appropriately. This commit is the outcome of running `x fmt --all` with the new formatting options.
2024-07-01rustc_data_structures: fix wrong markdown syntaxMichael Howell-2/+2
This didn't produce working footnote links. The unportable markdown lint warned about it.
2024-06-28rustc_data_structures: Explicitly check for 64-bit atomics supportJohn Paul Adrian Glaubitz-4/+3
Instead of keeping a list of architectures which have native support for 64-bit atomics, just use #[cfg(target_has_atomic = "64")] and its inverted counterpart to determine whether we need to use portable AtomicU64 on the target architecture.
2024-06-24rustc_data_structures: Use portable AtomicU64 on 32-bit SPARCJohn Paul Adrian Glaubitz-3/+3
While at it, order the list of architectures alphabetically.
2024-05-01Mark more entries in rustc_data_structures as no_inline for docsMark Rousskov-0/+6
This is a workaround for #122758, but it's not clear why 1.79 requires a more extensive amount of no_inline than the previous release. Seems like there's something relatively subtle happening here.
2024-03-20collector: recursively traverse 'mentioned' items to evaluate their constantsRalf Jung-3/+6
2024-02-24compiler: use `addr_of!`Pavel Grigorenko-1/+1
2024-01-18Remove `OneThread`John Kåre Alsaker-56/+0
2024-01-06don't reexport atomic::ordering via rustc_data_structures, use std importklensy-5/+2
2023-11-06use portable AtomicU64 for powerPC and MIPSSparrowLii-1/+9
2023-10-23Auto merge of #116849 - oli-obk:error_shenanigans, r=cjgillotbors-1/+1
Avoid a `track_errors` by bubbling up most errors from `check_well_formed` I believe `track_errors` is mostly papering over issues that a sufficiently convoluted query graph can hit. I made this change, while the actual change I want to do is to stop bailing out early on errors, and instead use this new `ErrorGuaranteed` to invoke `check_well_formed` for individual items before doing all the `typeck` logic on them. This works towards resolving https://github.com/rust-lang/rust/issues/97477 and various other ICEs, as well as allowing us to use parallel rustc more (which is currently rather limited/bottlenecked due to the very sequential nature in which we do `rustc_hir_analysis::check_crate`) cc `@SparrowLii` `@Zoxc` for the new `try_par_for_each_in` function
2023-10-20Avoid a `track_errors` by bubbling up most errors from `check_well_formed`Oli Scherer-1/+1
2023-10-19Initiate the inner usage of `cfg_match`Caio-3/+4
2023-09-11Rollup merge of #115548 - Zoxc:parallel-extract, r=wesleywiserMatthias Krüger-171/+5
Extract parallel operations in `rustc_data_structures::sync` into a new `parallel` submodule This extracts parallel operations in `rustc_data_structures::sync` into a new `parallel` submodule. This cuts down on the size of the large `cfg_if!` in `sync` and makes it easier to compare between serial and parallel variants.
2023-09-08Remove the `LockMode` enum and `dispatch`John Kåre Alsaker-1/+1
2023-09-08Refactor `Lock` implementationJohn Kåre Alsaker-2/+1
2023-09-06Extract parallel operations in `rustc_data_structures::sync` into a new ↵John Kåre Alsaker-171/+5
`parallel` submodule
2023-09-02Rename `Freeze` to `FreezeLock`John Kåre Alsaker-1/+1
2023-09-02Add `Freeze` type and use it to store `Definitions`John Kåre Alsaker-0/+3
2023-09-01Use `OnceLock` for `SingleCache`John Kåre Alsaker-2/+2
2023-08-30Use a `parallel_guard` function to handle the parallel guardJohn Kåre Alsaker-60/+55
2023-08-30Use `Mutex` to avoid issue with conditional locksJohn Kåre Alsaker-4/+3
2023-08-30Add `ParallelGuard` type to handle unwinding in parallel sectionsJohn Kåre Alsaker-121/+68
2023-08-30Make parallel! an expressionJohn Kåre Alsaker-2/+2
2023-08-30Use conditional synchronization for LockJohn Kåre Alsaker-86/+19
2023-05-25rustc_data_structures: sync and atomic consistencyMichael Howell-6/+6
Co-authored-by: @lukas-code
2023-05-25rustc_metadata: specialize private_dep flag with `fetch_and`Michael Howell-13/+4
2023-05-25rustc_metadata: use configurable AtomicBool for privateness flagMichael Howell-0/+14
This switches to using a `Cell` for single-threaded rustc.
2023-05-16Remove `MetadataRef` type aliasMaybe Waffle-3/+0
2023-05-16Merge `MetadataRef` type aliasesMaybe Waffle-4/+3
2023-05-06correct literals for dyn thread safeSparrowLii-12/+12
2023-05-06rename relative names in `sync`SparrowLii-17/+22
2023-05-06fix `parallel!`SparrowLii-0/+7
2023-05-06fix some nitsSparrowLii-13/+12
2023-05-06introduce `DynSend` and `DynSync` auto traitSparrowLii-38/+195
2023-04-16Move the WorkerLocal type from the rustc-rayon fork into rustc_data_structuresJohn Kåre Alsaker-29/+7
2023-04-08Auto merge of #109971 - WaffleLapkin:yeet_ownership, r=Nilstriebbors-26/+7
Yeet `owning_ref` Based on the discussions from https://github.com/rust-lang/rust/pull/109948 This replaces `owning_ref` with a far simpler & safer abstraction. Fixes #109974
2023-04-05Yeet `owning_ref`Maybe Waffle-18/+0
Turns out - `owning_ref` is unsound due to `Box` aliasing stuff - `rustc` doesn't need 99% of the `owning_ref` API - `rustc` can use a far simpler abstraction that is `OwnedSlice`
2023-04-05Use `OwnedSlice` instead of `owning_ref`Maybe Waffle-3/+3
2023-04-05Implement `OwnedSlice`Maybe Waffle-5/+4
2023-04-04Use a simpler atomic operation than the `compare_exchange` hammerOli Scherer-0/+8
2023-04-04Add a usize-indexed append-only-vecOli Scherer-1/+1
2023-04-04Remove a fishy Clone implOli Scherer-8/+0
2023-03-30Remove `RwLock::clone_guard`.Nicholas Nethercote-12/+0
It's unused.
2023-03-30Improve the `rustc_data_structures::sync` module doc comment.Nicholas Nethercote-14/+39
Also, `MTRef<'a, T>` is a typedef for a reference to a `T`, but in practice it's only used (and useful) in combination with `MTLock`, i.e. `MTRef<'a, MTLock<T>>`. So this commit changes it to be a typedef for a reference to an `MTLock<T>`, and renames it as `MTLockRef`. I think this clarifies things, because I found `MTRef` quite puzzling at first.
2023-02-21Use a lock-free datastructure for `source_span`Oli Scherer-0/+4
2023-02-03Disallow impl autotrait for trait objectDavid Tolnay-2/+2
2022-12-10compiler: remove unnecessary imports and qualified pathsKaDiWa-1/+1
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-01-15 13:17:04 +0000