| Age | Commit message (Collapse) | Author | Lines |
|
Unfortunately the `parking_lot` crate enables the `synchapi` feature of the
`winapi` crate which activates a dependency on `libsynchronization.a`. The MinGW
version of `libsynchronization.a` pulls in a dependency
`api-ms-core-synch-l1-2-0.dll` which causes rustc to not work on Windows 7
(tracked in #49438)
The `parking_lot` crate is not currently used in the compiler unless parallel
queries are enabled. This feature is not enabled by default and not used at all
in the beta/stable compilers. As a result the dependency in this commit was
removed and the CI build which checks parallel queries was disabled.
This isn't a great long-term solution but should hopefully be enough of a patch
for beta to buy us some more time to figure this out.
|
|
Implement some trivial size_hints for various iterators
This also implements ExactSizeIterator where applicable.
Addresses most of the Iterator traits mentioned in #23708.
I intend to do more, but I don't want to make the PR too large.
|
|
These unstable items are deprecated:
* The `std::collections::range::RangeArgument` reexport
* The `std::collections::range` module.
|
|
The stable reexport `std::collections::Bound` is now deprecated.
Another deprecated reexport could be added in `alloc`,
but that crate is unstable.
|
|
|
|
|
|
|
|
|
|
|
|
Misc changes from my parallel rustc branch
r? @michaelwoerister
|
|
Add 12 num::NonZero* types for primitive integers, deprecate core::nonzero
RFC: https://github.com/rust-lang/rfcs/pull/2307
Tracking issue: ~~https://github.com/rust-lang/rust/issues/27730~~ https://github.com/rust-lang/rust/issues/49137
Fixes https://github.com/rust-lang/rust/issues/27730
|
|
This also implements ExactSizeIterator where applicable.
Addresses most of the Iterator traits mentioned in #23708.
|
|
Fixes #47326
|
|
|
|
|
|
|
|
|
|
Remove some unnecessary IdxSet methods
This replaces `IdxSet:: reset_to_empty` with `IdxSet:: clear`, and `IdxSet::elems`/`IdxSet::each_bit` with `IdxSet::iter`. Based on some [comments on #rustc](https://botbot.me/mozilla/rustc/2018-01-23/?msg=96063396).
r? @pnkfelix
|
|
|
|
|
|
Move REGISTERED_DIAGNOSTICS to a ParseSess field
r? @michaelwoerister
|
|
Replace iterator structures with `impl Trait`.
Two commits:
* Replace iterator structures with `impl Trait`.
* Run rustfmt on `src/librustc_data_structures/graph/mod.rs`.
|
|
|
|
|
|
|
|
|
|
update-cargo
|
|
|
|
|
|
|
|
|
|
|
|
Make TransitiveRelation thread safe. Avoid locking by using get_mut in some cases
r? @nikomatsakis
|
|
|
|
These modules were replaced with re-exports from ena
|
|
The ena version has an improved interface. I suspect
`librustc_data_structures` should start migrating out to crates.io in
general.
|
|
cases.
|
|
rustc_data_structures: add missing #[inline].
r? @nikomatsakis
|
|
|
|
|
|
Fixes #48170
|
|
|
|
|
|
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
|
|
|
|
Remove unused data structures
Cleanup; as far as I can tell the compiler no longer uses these.
|
|
|
|
|
|
Fixes #47602
|
|
|