Specialize equality for [T] and comparison for [u8] to use memcmp when possible
Specialize equality for [T] and comparison for [u8] to use memcmp when possible
Where T is a type that can be compared for equality bytewise, we can use
memcmp. We can also use memcmp for PartialOrd, Ord for [u8].
Use specialization to call memcmp in PartialEq for slices for certain element types. This PR does not change the user visible API since the implementation uses an intermediate trait. See commit messages for more information.
The memcmp signature was changed from `*const i8` to `*const u8` which is in line with how the memcmp function is defined in C (taking const void * arguments, interpreting the values as unsigned bytes for purposes of the comparison).
Lay groundwork for RFC 1422 and improve `PrivateItemsInPublicInterfacesVisitor`
This PR lays groundwork for RFC 1422 (cc #32409) and improves `PrivateItemsInPublicInterfacesVisitor`. More specifically, it
- Refactors away `hir::Visibility::inherit_from`, the semantics of which are obsolete.
- Makes `hir::Visibility` non-`Copy` so that we will be able to add new variants to represent `pub(restricted)` (for example, `Visibility::Restricted(Path)`).
- Adds a new `Copy` type `ty::Visibility` that represents a visibility value, i.e. a characterization of where an item is accessible. This is able to represent `pub(restricted)` visibilities.
- Improves `PrivateItemsInPublicInterfacesVisitor` so that it checks for items in an interface that are less visible than the interface. This fixes#30079 but doesn't change any other behavior.
r? @nikomatsakis
Suggest adding a where-clause when that can help
Suggest adding a where-clause when there is an unmet trait-bound that can be satisfied if some type can implement it.
r? @nikomatsakis
Fix LLVM assert when handling bad intrinsic monomorphizations
Passing an invalid type to certain intrinsics would trigger an LLVM assert even though the invalid type was caught by the compiler.
r? @eddyb
Remove error description of `move`
(1) `x` can be used in main() after the call to spawn(). Because the variables follow normal move semantics, though the keyword `move` is used, and i32 implements `Copy`.
(2) I remove this sentence because the previous sentence gives the referrence to `move closures`, and more description of `move` may be redundant.
Minor doc fixes in "Crates and Modules" and "Lifetimes" chapters
These commits fix a couple of (minor) issues in the _Crates and Modules_ and the _Lifetimes_ chapters of the book.
r? @steveklabnik
Mention that it's not actually a data race
The example can't cause a data race since different indices are accesed.
(perhaps we should use an example where i iterates twice?)
r? @steveklabnik
The AST part of https://github.com/rust-lang/rust/pull/31937
Unlike HIR, AST still uses `Option` for field names because parser can't know field indexes reliably due to constructions like
```
struct S(#[cfg(false)] u8, u8); // The index of the second field changes from 1 during parsing to 0 after expansion.
```
and I wouldn't like to put the burden of renaming fields on expansion passes and syntax extensions.
plugin-[breaking-change] cc https://github.com/rust-lang/rust/issues/31645
r? @Manishearth
[breaking-batch] Add support for `pub(restricted)` syntax in the AST
This PR allows the AST to represent the `pub(restricted)` syntax from RFC 1422 (cc #32409).
More specifically, it makes `ast::Visibility` non-`Copy` and adds two new variants, `Visibility::Crate` for `pub(crate)` and `Visitibility::Restricted { path: P<Path>, id: NodeId }` for `pub(path)`.
plugin-[breaking-change] cc #31645
r? @pnkfelix
