about summary refs log tree commit diff
path: root/src/librustc_data_structures
AgeCommit message (Collapse)AuthorLines
2020-04-22Rollup merge of #71369 - ctaggart:wasm32_profiling, r=ecstatic-morseDylan DPC-31/+42
allow wasm32 compilation of librustc_data_structures/profiling.rs I'm trying to use rustfmt from a wasm app. I ran into this compilation problem https://github.com/rust-lang/rustfmt/issues/4132 and after investigating, it looked like just adjusting a few cfg's. I based it on how measureme added support in https://github.com/rust-lang/measureme/pull/43. My testing on my macbook was just that librustc_data_structures builds now with both: - cargo build - cargo build --target wasm32-unknown-unknown
2020-04-22remove some extra }Cameron Taggart-30/+28
2020-04-22suggested rearrangement of the cfg if statementsCameron Taggart-32/+30
Co-Authored-By: ecstatic-morse <ecstaticmorse@gmail.com>
2020-04-21accept cfg_if suggestionCameron Taggart-17/+7
Co-Authored-By: bjorn3 <bjorn3@users.noreply.github.com>
2020-04-21use cfg_if! and use FileSerializationSink for wasiCameron Taggart-38/+56
2020-04-21sccs are computed in dependency orderNiko Matsakis-0/+5
We don't need the `scc_dependency_order` vector, `all_sccs` is already in dependency order.
2020-04-20./x.py fmtCameron Taggart-6/+6
2020-04-20allow wasm32 compilation of librustc_data_structures/profiling.rsCameron Taggart-4/+11
2020-04-20Remove unused ToHex/FromHex traitShotaro Yamada-2/+0
2020-04-18Move `MapInPlace` to rustc_data_structuresYuki Okushi-0/+109
2020-04-16rustc_target::abi: add Primitive variant to FieldsShape.Ana-Maria Mihalache-0/+6
2020-04-11Depend on libc from crates.ioLuca Barbieri-2/+1
2020-04-09Use tri-color search for unconditional recursion lintDylan MacKenzie-3/+10
2020-04-05Stop importing int/float modules in librustc_*Linus Färnstrand-2/+0
2020-03-30rustc -> rustc_middle part 1Mazdak Farrokhzad-1/+1
2020-03-27Auto merge of #69916 - oli-obk:mir_bless, r=eddybbors-2/+2
Enable blessing of mir opt tests cc @rust-lang/wg-mir-opt cc @RalfJung Long overdue, but now you can finally just add a ```rust // EMIT_MIR rustc.function_name.MirPassName.before.mir ``` (or `after.mir` since most of the time you want to know the MIR after a pass). A `--bless` invocation will automatically create the files for you. I suggest we do this for all mir opt tests that have all of the MIR in their source anyway If you use `rustc.function.MirPass.diff` you only get the diff that the MIR pass causes on the MIR. Fixes #67865
2020-03-26Enable `--bless`ing of MIR dumpsOliver Scherer-2/+2
2020-03-26Upgrade rustc and bootstrap dependenciesMateusz Mikuła-2/+2
2020-03-23Rollup merge of #70269 - matthiaskrgr:clippy_closures, r=Dylan-DPCMazdak Farrokhzad-1/+1
remove redundant closures (clippy::redundant_closure)
2020-03-22remove redundant closures (clippy::redundant_closure)Matthias Krüger-1/+1
2020-03-21Return NonZeroU64 from ThreadId::as_u64.Thomas Bächler-2/+2
As discussed in #67939, this allows turning Option<ThreadId> into Option<NonZeroU64> which can then be stored inside an AtomicU64.
2020-03-20remove redundant returns (clippy::needless_return)Matthias Krüger-2/+2
2020-03-15Bump the bootstrap compilerJonas Schievink-39/+0
2020-03-15Rollup merge of #69967 - mark-i-m:rinfctx, r=matthewjasperDylan DPC-0/+64
Remove a few `Rc`s from RegionInferenceCtxt fixes https://github.com/rust-lang/rust/issues/55853 r? @matthewjasper
2020-03-13update rustdocs for frozenMark Mansi-1/+7
2020-03-13move frozen to rustc_data_structuresMark Mansi-0/+58
2020-03-12remove lifetimes that can be elided (clippy::needless_lifetimes)Matthias Krüger-2/+2
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.