| Age | Commit message (Collapse) | Author | Lines |
|
|
|
The repeated cloning of the result in `inherent_impls` queries has quite
an impact on crates with many inherent trait implementations.
|
|
|
|
|
|
Improve a few cases of collecting to an FxHash(Map/Set)
Either use `collect` or procure specified capacity when possible.
|
|
|
|
|
|
|
|
Lots of annoying boilerplate.
|
|
Prefer unwrap_or_else to unwrap_or in case of function calls/allocations
The contents of `unwrap_or` are evaluated eagerly, so it's not a good pick in case of function calls and allocations. This PR also changes a few `unwrap_or`s with `unwrap_or_default`.
An added bonus is that in some cases this change also reveals if the object it's called on is an `Option` or a `Result` (based on whether the closure takes an argument).
|
|
|
|
|
|
|
|
Replace `ParamEnv` with a new type in chalk context.
I left a few FIXMEs.
r? @nikomatsakis
|
|
Deduplicate some code and compile-time values around vtables
r? @RalfJung
|
|
|
|
|
|
|
|
|
|
`Result` really sounds like the rustc result type
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This seemed like a good way to kick the tires on the
elided-lifetimes-in-paths lint (#52069)—seems to work! This was also
pretty tedious—it sure would be nice if `cargo fix` worked on this
codebase (#53896)!
|
|
Before this two macros with same name would be indistinguishable inside a
`FileName`. This caused a bug in incremental compilation (see #53097) since
two different macros would map out to the same `StableFilemapId`.
Fixes #53097.
|
|
Currently we have two files implementing bitsets (and 2D bit matrices).
This commit combines them into one, taking the best features from each.
This involves renaming a lot of things. The high level changes are as
follows.
- bitvec.rs --> bit_set.rs
- indexed_set.rs --> (removed)
- BitArray + IdxSet --> BitSet (merged, see below)
- BitVector --> GrowableBitSet
- {,Sparse,Hybrid}IdxSet --> {,Sparse,Hybrid}BitSet
- BitMatrix --> BitMatrix
- SparseBitMatrix --> SparseBitMatrix
The changes within the bitset types themselves are as follows.
```
OLD OLD NEW
BitArray<C> IdxSet<T> BitSet<T>
-------- ------ ------
grow - grow
new - (remove)
new_empty new_empty new_empty
new_filled new_filled new_filled
- to_hybrid to_hybrid
clear clear clear
set_up_to set_up_to set_up_to
clear_above - clear_above
count - count
contains(T) contains(&T) contains(T)
contains_all - superset
is_empty - is_empty
insert(T) add(&T) insert(T)
insert_all - insert_all()
remove(T) remove(&T) remove(T)
words words words
words_mut words_mut words_mut
- overwrite overwrite
merge union union
- subtract subtract
- intersect intersect
iter iter iter
```
In general, when choosing names I went with:
- names that are more obvious (e.g. `BitSet` over `IdxSet`).
- names that are more like the Rust libraries (e.g. `T` over `C`,
`insert` over `add`);
- names that are more set-like (e.g. `union` over `merge`, `superset`
over `contains_all`, `domain_size` over `num_bits`).
Also, using `T` for index arguments seems more sensible than `&T` --
even though the latter is standard in Rust collection types -- because
indices are always copyable. It also results in fewer `&` and `*`
sigils in practice.
|
|
|
|
Add forever unstable attribute to allow specifying arbitrary scalar ranges
r? @eddyb for the first commit and @nikomatsakis for the second one
|
|
|
|
This reverts commit d02a5ffaed9c395ae62ee12d0f4e04946c62edb1.
|
|
|
|
|
|
fixes the *first* false positive reported in #53964
|
|
Enable ThinLTO with incremental compilation.
This is an updated version of #52309. This PR allows `rustc` to use (local) ThinLTO and incremental compilation at the same time. In theory this should allow for getting compile-time improvements for small changes while keeping the runtime performance of the generated code roughly the same as when compiling non-incrementally.
The difference to #52309 is that this version also caches the pre-LTO version of LLVM bitcode. This allows for another layer of caching:
1. if the module itself has changed, we have to re-codegen and re-optimize.
2. if the module itself has not changed, but a module it imported from during ThinLTO has, we don't need to re-codegen and don't need to re-run the first optimization phase. Only the second (i.e. ThinLTO-) optimization phase is re-run.
3. if neither the module itself nor any of its imports have changed then we can re-use the final, post-ThinLTO version of the module. (We might have to load its pre-ThinLTO version though so it's available for other modules to import from)
|
|
|
|
|
|
Replace usages of 'bad_style' with 'nonstandard_style'.
`bad_style` is being deprecated in favor of `nonstandard_style`:
- https://github.com/rust-lang/rust/issues/41646
|
|
`bad_style` is being deprecated in favor of `nonstandard_style`:
- https://github.com/rust-lang/rust/issues/41646
|
|
|
|
Merge `IdxSet` and `IdxSetBuf`
Because it simplifies things.
@r? nikomatsakis
|
|
* Value gets renamed to Operand, so that now interpret::{Place, Operand} are the
"dynamic" versions of mir::{Place, Operand}.
* Operand and Place share the data for their "stuff is in memory"-base in a new
type, MemPlace. This also makes it possible to give some more precise types
in other areas. Both Operand and MemPlace have methods available to project
into fields (and other kinds of projections) without causing further
allocations.
* The type for "a Scalar or a ScalarPair" is called Value, and again used to
give some more precise types.
* All of these have versions with an attached layout, so that we can more often
drag the layout along instead of recomputing it. This lets us get rid of
`PlaceExtra::Downcast`. MPlaceTy and PlaceTy can only be constructed
in place.rs, making sure the layout is handled properly.
(The same should eventually be done for ValTy and OpTy.)
* All the high-level functions to write typed memory take a Place, and live in
place.rs. All the high-level typed functions to read typed memory take an
Operand, and live in operands.rs.
|
|
Fix typos found by codespell.
|
|
Now that the `Buf` vs. non-`Buf` distinction has been removed, it makes
sense to drop the `Buf` suffix and use the shorter names everywhere.
|
|
|
|
|
|
|