summary refs log tree commit diff
path: root/src/librustc_data_structures
AgeCommit message (Collapse)AuthorLines
2020-03-06fix various typosMatthias Krüger-3/+3
2020-02-28use is_empty() instead of len() == x to determine if structs are empty.Matthias Krüger-1/+1
2020-02-27Rollup merge of #69500 - cuviper:par_for_each_in-item, r=Mark-SimulacrumYuki Okushi-8/+2
Simplify the signature of par_for_each_in Given `T: IntoIterator`/`IntoParallelIterator`, `T::Item` is unambiguous, so we don't need the explicit trait casting.
2020-02-26Simplify the signature of par_for_each_inJosh Stone-8/+2
Given `T: IntoIterator`/`IntoParallelIterator`, `T::Item` is unambiguous, so we don't need the explicit trait casting.
2020-02-26clarify operator precedenceMatthias Krüger-1/+1
2020-02-24remove redundant clones in librustc_mir_build and librustc_data_structuresMatthias Krüger-2/+2
2020-02-22Auto merge of #69332 - nnethercote:revert-u8to64_le-changes, r=michaelwoeristerbors-12/+43
Revert `u8to64_le` changes from #68914. `SipHasher128`'s `u8to64_le` function was simplified in #68914. Unfortunately, the new version is slower, because it introduces `memcpy` calls with non-statically-known lengths. This commit reverts the change, and adds an explanatory comment (which is also added to `libcore/hash/sip.rs`). This barely affects `SipHasher128`'s speed because it doesn't use `u8to64_le` much, but it does result in `SipHasher128` once again being consistent with `libcore/hash/sip.rs`. r? @michaelwoerister
2020-02-21Revert `u8to64_le` changes from #68914.Nicholas Nethercote-12/+43
`SipHasher128`'s `u8to64_le` function was simplified in #68914. Unfortunately, the new version is slower, because it introduces `memcpy` calls with non-statically-known lengths. This commit reverts the change, and adds an explanatory comment (which is also added to `libcore/hash/sip.rs`). This barely affects `SipHasher128`'s speed because it doesn't use `u8to64_le` much, but it does result in `SipHasher128` once again being consistent with `libcore/hash/sip.rs`.
2020-02-20Auto merge of #69072 - ecstatic-morse:associated-items, r=petrochenkovbors-1/+249
O(log n) lookup of associated items by name Resolves #68957, in which compile time is quadratic in the number of associated items. This PR makes name lookup use binary search instead of a linear scan to improve its asymptotic performance. As a result, the pathological case from that issue now runs in 8 seconds on my local machine, as opposed to many minutes on the current stable. Currently, method resolution must do a linear scan through all associated items of a type to find one with a certain name. This PR changes the result of the `associated_items` query to a data structure that preserves the definition order of associated items (which is used, e.g., for the layout of trait object vtables) while adding an index of those items sorted by (unhygienic) name. When doing name lookup, we first find all items with the same `Symbol` using binary search, then run hygienic comparison to find the one we are looking for. Ideally, this would be implemented using an insertion-order preserving, hash-based multi-map, but one is not readily available. Someone who is more familiar with identifier hygiene could probably make this better by auditing the uses of the `AssociatedItems` interface. My goal was to preserve the current behavior exactly, even if it seemed strange (I left at least one FIXME to this effect). For example, some places use comparison with `ident.modern()` and some places use `tcx.hygienic_eq` which requires the `DefId` of the containing `impl`. I don't know whether those approaches are equivalent or which one should be preferred.
2020-02-19Implement an insertion-order preserving, efficient multi-mapDylan MacKenzie-1/+249
2020-02-19Tune inliningJohn Kåre Alsaker-3/+7
2020-02-15Rollup merge of #68475 - Aaron1011:fix/forest-caching, r=nikomatsakisYuki Okushi-15/+20
Use a `ParamEnvAnd<Predicate>` for caching in `ObligationForest` Previously, we used a plain `Predicate` to cache results (e.g. successes and failures) in ObligationForest. However, fulfillment depends on the precise `ParamEnv` used, so this is unsound in general. This commit changes the impl of `ForestObligation` for `PendingPredicateObligation` to use `ParamEnvAnd<Predicate>` instead of `Predicate` for the associated type. The associated type and method are renamed from 'predicate' to 'cache_key' to reflect the fact that type is no longer just a predicate.
2020-02-14Auto merge of #68693 - Zoxc:query-no-arc, r=michaelwoeristerbors-2/+11
Construct query job latches on-demand r? @michaelwoerister
2020-02-13add selfprofiling for new llvm passmanagerAndreas Jonson-0/+11
2020-02-12Rollup merge of #68914 - nnethercote:speed-up-SipHasher128, r=michaelwoeristerDylan DPC-80/+84
Speed up `SipHasher128`. The current code in `SipHasher128::short_write` is inefficient. It uses `u8to64_le` (which is complex and slow) to extract just the right number of bytes of the input into a u64 and pad the result with zeroes. It then left-shifts that value in order to bitwise-OR it with `self.tail`. For example, imagine we have a u32 input `0xIIHH_GGFF` and only need three bytes to fill up `self.tail`. The current code uses `u8to64_le` to construct `0x0000_0000_00HH_GGFF`, which is just `0xIIHH_GGFF` with the `0xII` removed and zero-extended to a u64. The code then left-shifts that value by five bytes -- discarding the `0x00` byte that replaced the `0xII` byte! -- to give `0xHHGG_FF00_0000_0000`. It then then ORs that value with `self.tail`. There's a much simpler way to do it: zero-extend to u64 first, then left shift. E.g. `0xIIHH_GGFF` is zero-extended to `0x0000_0000_IIHH_GGFF`, and then left-shifted to `0xHHGG_FF00_0000_0000`. We don't have to take time to exclude the unneeded `0xII` byte, because it just gets shifted out anyway! It also avoids multiple occurrences of `unsafe`. There's a similar story with the setting of `self.tail` at the method's end. The current code uses `u8to64_le` to extract the remaining part of the input, but the same effect can be achieved more quickly with a right shift on the zero-extended input. This commit changes `SipHasher128` to use the simpler shift-based approach. The code is also smaller, which means that `short_write` is now inlined where previously it wasn't, which makes things faster again. This gives big speed-ups for all incremental builds, especially "baseline" incremental builds. r? @michaelwoerister
2020-02-12Use a counter instead of pointers to the stackJohn Kåre Alsaker-2/+11
2020-02-12Improve `u8to64_le`.Nicholas Nethercote-41/+12
This makes it faster and also changes it to a safe function. (Thanks to Michael Woerister for the suggestion.) `load_int_le!` is also no longer necessary.
2020-02-11Move macro enum_from_u32 to rustc_data_structures.Camille GILLOT-0/+38
2020-02-11Rollup merge of #66498 - bjorn3:less_feature_flags, r=Dylan-DPCDylan DPC-3/+0
Remove unused feature gates I think many of the remaining unstable things can be easily be replaced with stable things. I have kept the `#![feature(nll)]` even though it is only necessary in `libstd`, to make regressions of it harder.
2020-02-10self-profile: Support arguments for generic_activities.Michael Woerister-34/+73
2020-02-10Speed up `SipHasher128`.Nicholas Nethercote-39/+72
The current code in `SipHasher128::short_write` is inefficient. It uses `u8to64_le` (which is complex and slow) to extract just the right number of bytes of the input into a u64 and pad the result with zeroes. It then left-shifts that value in order to bitwise-OR it with `self.tail`. For example, imagine we have a u32 input 0xIIHH_GGFF and only need three bytes to fill up `self.tail`. The current code uses `u8to64_le` to construct 0x0000_0000_00HH_GGFF, which is just 0xIIHH_GGFF with the 0xII removed and zero-extended to a u64. The code then left-shifts that value by five bytes -- discarding the 0x00 byte that replaced the 0xII byte! -- to give 0xHHGG_FF00_0000_0000. It then then ORs that value with self.tail. There's a much simpler way to do it: zero-extend to u64 first, then left shift. E.g. 0xIIHH_GGFF is zero-extended to 0x0000_0000_IIHH_GGFF, and then left-shifted to 0xHHGG_FF00_0000_0000. We don't have to take time to exclude the unneeded 0xII byte, because it just gets shifted out anyway! It also avoids multiple occurrences of `unsafe`. There's a similar story with the setting of `self.tail` at the method's end. The current code uses `u8to64_le` to extract the remaining part of the input, but the same effect can be achieved more quickly with a right shift on the zero-extended input. All that works on little-endian. It doesn't work for big-endian, but we can just do a `to_le` before calling `short_write` and then it works. This commit changes `SipHasher128` to use the simpler shift-based approach. The code is also smaller, which means that `short_write` is now inlined where previously it wasn't, which makes things faster again. This gives big speed-ups for all incremental builds, especially "baseline" incremental builds.
2020-02-06Rollup merge of #68524 - jonas-schievink:generator-resume-arguments, r=ZoxcDylan DPC-0/+39
Generator Resume Arguments cc https://github.com/rust-lang/rust/issues/43122 and https://github.com/rust-lang/rust/issues/56974 Blockers: * [x] Fix miscompilation when resume argument is live across a yield point (https://github.com/rust-lang/rust/pull/68524#issuecomment-578459069) * [x] Fix 10% compile time regression in `await-call-tree` benchmarks (https://github.com/rust-lang/rust/pull/68524#issuecomment-578487162) * [x] Fix remaining 1-3% regression (https://github.com/rust-lang/rust/pull/68524#issuecomment-579566255) - resolved (https://github.com/rust-lang/rust/pull/68524#issuecomment-581144901) * [x] Make dropck rules account for resume arguments (https://github.com/rust-lang/rust/pull/68524#issuecomment-578541137) Follow-up work: * Change async/await desugaring to make use of this feature * Rewrite [`box_region.rs`](https://github.com/rust-lang/rust/blob/3d8778d767f0dde6fe2bc9459f21ead8e124d8cb/src/librustc_data_structures/box_region.rs) to use resume arguments (this shows up in profiles too)
2020-02-06Remove `RefCell` usage from `ObligationForest`.Nicholas Nethercote-5/+5
It's not needed.
2020-02-04Remove unused feature gates from librustc_data_structuresbjorn3-3/+0
2020-02-02Fix bootstrap rustc buildJonas Schievink-0/+39
2020-02-01Use BufWriterShotaro Yamada-1/+2
2020-01-24[self-profiler] Clean up `EventFilter`Wesley Wiser-7/+3
2020-01-24[self-profiler] Use `ThreadId::as_u64()` instead of transmuteWesley Wiser-7/+3
2020-01-23unused-parens: implement for block return valuesTyler Lanphear-1/+1
2020-01-22Use a `ParamEnvAnd<Predicate>` for caching in `ObligationForest`Aaron Hill-15/+20
Previously, we used a plain `Predicate` to cache results (e.g. successes and failures) in ObligationForest. However, fulfillment depends on the precise `ParamEnv` used, so this is unsound in general. This commit changes the impl of `ForestObligation` for `PendingPredicateObligation` to use `ParamEnvAnd<Predicate>` instead of `Predicate` for the associated type. The associated type and method are renamed from 'predicate' to 'cache_key' to reflect the fact that type is no longer just a predicate.
2020-01-17Rollup merge of #68278 - wesleywiser:doc_query_key_recording, r=michaelwoeristerDylan DPC-0/+2
[self-profiler] Add example to `-Z help` to turn on query key recording Also add the `default` option so that it's easy to add query key recording to the default. r? @michaelwoerister
2020-01-17Rollup merge of #67791 - Zoxc:lift-interning, r=eddybDylan DPC-0/+14
Implement Lift using interners instead of in_arena r? @eddyb cc @cjgillot
2020-01-17[self-profiler] Add example to `-Z help` to turn on query key recordingWesley Wiser-0/+2
Also add the `default` option so that it's easy to add query key recording to the default.
2020-01-15Rollup merge of #68141 - euclio:replace-bindings-with-winapi, r=alexcrichtonYuki Okushi-67/+19
use winapi for non-stdlib Windows bindings
2020-01-12Rollup merge of #67948 - llogiq:gallop, r=Mark-SimulacrumMazdak Farrokhzad-20/+40
Galloping search for binary_search_util This is unlikely to improve perf much unless for synthetic benchmarks, but I figure it likely won't hurt either.
2020-01-11use winapi for non-stdlib Windows bindingsAndy Russell-67/+19
2020-01-12Galloping search for binary_search_utilAndre Bogus-20/+40
2020-01-11Lift using interners instead of in_arenaJohn Kåre Alsaker-0/+14
2020-01-11Rollup merge of #68043 - Zoxc:missing-timers, r=wesleywiserMazdak Farrokhzad-0/+6
Add some missing timers Based on https://github.com/rust-lang/rust/pull/67988 r? @wesleywiser
2020-01-10Fix some rebasing fallout.Michael Woerister-3/+6
2020-01-10Update measureme to 0.7.1 in order to fix compilation error on big-endian ↵Michael Woerister-1/+1
platforms.
2020-01-10Run 'x.py fmt'.Michael Woerister-22/+7
2020-01-10self-profile: Fix issue with handling query blocking.Michael Woerister-0/+1
2020-01-10Initial support for recording query keys in self-profiling data.Michael Woerister-9/+39
2020-01-10self-profile: Switch to new approach for event_id generation that enables ↵Michael Woerister-32/+161
query-invocation-specific event_ids.
2020-01-10Rollup merge of #67922 - Centril:lowering-cleanup, r=petrochenkovMazdak Farrokhzad-0/+11
rustc_ast_lowering: misc cleanup & rustc dep reductions - The first two commits do some code simplification. - The next three do some file splitting (getting `lib.rs` below the 3kloc tidy lint). - The remaining commits reduce the number of `rustc::` imports. This works towards making lowering independent of the `rustc` crate. r? @oli-obk cc @Zoxc
2020-01-09Label unmarked timeJohn Kåre Alsaker-0/+6
2020-01-09{rustc::util -> rustc_data_structures}::capturesMazdak Farrokhzad-0/+11
2020-01-09More commentsJohn Kåre Alsaker-2/+6
2020-01-09Change -Z time event naming scheme and make them generic activitiesJohn Kåre Alsaker-92/+47
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-28 21:23:53 +0000