Enum cargo::core::SourceKind
source · pub enum SourceKind {
Git(GitReference),
Path,
Registry,
SparseRegistry,
LocalRegistry,
Directory,
}
Expand description
The possible kinds of code source.
Variants§
Git(GitReference)
A git repository.
Path
A local path.
Registry
A remote registry.
SparseRegistry
A sparse registry.
LocalRegistry
A local filesystem-based registry.
Directory
A directory-based registry.
Implementations§
Trait Implementations§
source§impl Clone for SourceKind
impl Clone for SourceKind
source§fn clone(&self) -> SourceKind
fn clone(&self) -> SourceKind
1.0.0 · source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source
. Read moresource§impl Debug for SourceKind
impl Debug for SourceKind
source§impl Hash for SourceKind
impl Hash for SourceKind
source§impl Ord for SourceKind
impl Ord for SourceKind
Note that this is specifically not derived on SourceKind
although the
implementation here is very similar to what it might look like if it were
otherwise derived.
The reason for this is somewhat obtuse. First of all the hash value of
SourceKind
makes its way into ~/.cargo/registry/index/github.com-XXXX
which means that changes to the hash means that all Rust users need to
redownload the crates.io index and all their crates. If possible we strive
to not change this to make this redownloading behavior happen as little as
possible. How is this connected to Ord
you might ask? That’s a good
question!
Since the beginning of time SourceKind
has had #[derive(Hash)]
. It for
the longest time also derived the Ord
and PartialOrd
traits. In #8522,
however, the implementation of Ord
changed. This handwritten implementation
forgot to sync itself with the originally derived implementation, namely
placing git dependencies as sorted after all other dependencies instead of
first as before.
This regression in #8522 (Rust 1.47) went unnoticed. When we switched back
to a derived implementation in #9133 (Rust 1.52 beta) we only then ironically
saw an issue (#9334). In #9334 it was observed that stable Rust at the time
(1.51) was sorting git dependencies last, whereas Rust 1.52 beta would sort
git dependencies first. This is because the PartialOrd
implementation in
1.51 used #8522, the buggy implementation, which put git deps last. In 1.52
it was (unknowingly) restored to the pre-1.47 behavior with git dependencies
first.
Because the breakage was only witnessed after the original breakage, this trait implementation is preserving the “broken” behavior. Put a different way:
- Rust pre-1.47 sorted git deps first.
- Rust 1.47 to Rust 1.51 sorted git deps last, a breaking change (#8522) that was never noticed.
- Rust 1.52 restored the pre-1.47 behavior (#9133, without knowing it did so), and breakage was witnessed by actual users due to difference with 1.51.
- Rust 1.52 (the source as it lives now) was fixed to match the 1.47-1.51 behavior (#9383), which is now considered intentionally breaking from the pre-1.47 behavior.
Note that this was all discovered when Rust 1.53 was in nightly and 1.52 was in beta. #9133 was in both beta and nightly at the time of discovery. For 1.52 #9383 reverted #9133, meaning 1.52 is the same as 1.51. On nightly (1.53) #9397 was created to fix the regression introduced by #9133 relative to the current stable (1.51).
That’s all a long winded way of saying “it’s weird that git deps hash first
and are sorted last, but it’s the way it is right now”. The author of this
comment chose to handwrite the Ord
implementation instead of the Hash
implementation, but it’s only required that at most one of them is
hand-written because the other can be derived. Perhaps one day in
the future someone can figure out how to remove this behavior.
source§fn cmp(&self, other: &SourceKind) -> Ordering
fn cmp(&self, other: &SourceKind) -> Ordering
1.21.0 · source§fn max(self, other: Self) -> Selfwhere
Self: Sized,
fn max(self, other: Self) -> Selfwhere
Self: Sized,
source§impl PartialEq for SourceKind
impl PartialEq for SourceKind
source§impl PartialOrd for SourceKind
impl PartialOrd for SourceKind
Forwards to Ord
impl Eq for SourceKind
impl StructuralPartialEq for SourceKind
Auto Trait Implementations§
impl Freeze for SourceKind
impl RefUnwindSafe for SourceKind
impl Send for SourceKind
impl Sync for SourceKind
impl Unpin for SourceKind
impl UnwindSafe for SourceKind
Blanket Implementations§
source§impl<T> BorrowMut<T> for Twhere
T: ?Sized,
impl<T> BorrowMut<T> for Twhere
T: ?Sized,
source§fn borrow_mut(&mut self) -> &mut T
fn borrow_mut(&mut self) -> &mut T
source§impl<T> CloneToUninit for Twhere
T: Clone,
impl<T> CloneToUninit for Twhere
T: Clone,
source§unsafe fn clone_to_uninit(&self, dst: *mut T)
unsafe fn clone_to_uninit(&self, dst: *mut T)
clone_to_uninit
)§impl<Q, K> Comparable<K> for Q
impl<Q, K> Comparable<K> for Q
§impl<Q, K> Equivalent<K> for Q
impl<Q, K> Equivalent<K> for Q
§fn equivalent(&self, key: &K) -> bool
fn equivalent(&self, key: &K) -> bool
§impl<Q, K> Equivalent<K> for Q
impl<Q, K> Equivalent<K> for Q
§fn equivalent(&self, key: &K) -> bool
fn equivalent(&self, key: &K) -> bool
key
and return true
if they are equal.§impl<T> Instrument for T
impl<T> Instrument for T
§fn instrument(self, span: Span) -> Instrumented<Self>
fn instrument(self, span: Span) -> Instrumented<Self>
§fn in_current_span(self) -> Instrumented<Self>
fn in_current_span(self) -> Instrumented<Self>
§impl<T> Pointable for T
impl<T> Pointable for T
§impl<T> WithSubscriber for T
impl<T> WithSubscriber for T
§fn with_subscriber<S>(self, subscriber: S) -> WithDispatch<Self>where
S: Into<Dispatch>,
fn with_subscriber<S>(self, subscriber: S) -> WithDispatch<Self>where
S: Into<Dispatch>,
§fn with_current_subscriber(self) -> WithDispatch<Self>
fn with_current_subscriber(self) -> WithDispatch<Self>
Layout§
Note: Most layout information is completely unstable and may even differ between compilations. The only exception is types with certain repr(...)
attributes. Please see the Rust Reference's “Type Layout” chapter for details on type layout guarantees.
Size: 32 bytes
Size for each variant:
Git
: 32 bytesPath
: 0 bytesRegistry
: 0 bytesSparseRegistry
: 0 bytesLocalRegistry
: 0 bytesDirectory
: 0 bytes