Rollup merge of #32748 - aturon:simplified-spec, r=nikomatsakis
Reinstate fast_reject for overlap checking
The initial implementation of specialization did not use the
`fast_reject` mechanism when checking for overlap, which caused a
serious performance regression in some cases.
This commit modifies the specialization graph to use simplified types
for fast rejection when possible, and along the way refactors the logic
for building the specialization graph.
Rollup merge of #32699 - bluss:slice-memcmp, r=alexcrichton
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).
Rollup merge of #32674 - jseyfried:1422_groundwork, r=nikomatsakis
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.
Steve Klabnik [Wed, 6 Apr 2016 19:12:08 +0000 (12:12 -0700)]
Rollup merge of #32679 - tclfs:patch-1, r=steveklabnik
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.
Rollup merge of #32682 - petrochenkov:field3, r=Manishearth
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
Auto merge of #32688 - jseyfried:ast_groundwork_for_1422, r=pnkfelix
[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)`.
Auto merge of #32415 - alexcrichton:android-signal, r=alexcrichton
std: Fix linking against `signal` on Android
Currently the minimum supported Android version of the standard library is
API level 18 (android-18). Back in those days [1] the `signal` function was
just an inline wrapper around `bsd_signal`, but starting in API level
android-20 the `signal` symbols was introduced [2]. Finally, in android-21
the API `bsd_signal` was removed [3].
Basically this means that if we want to be binary compatible with multiple
Android releases (oldest being 18 and newest being 21) then we need to check
for both symbols and not actually link against either.
This was first discovered in rust-lang/libc#236 with a fix proposed in
rust-lang/libc#237. I suspect that we'll want to accept rust-lang/libc#237 so
Rust crates at large continue to be compatible with newer releases of Android
and crates, like the standard library, that want to opt into older support can
continue to do so via similar means.
Varun Vats [Thu, 31 Mar 2016 02:11:06 +0000 (21:11 -0500)]
Doc fix: list all module files Rust looks for.
1. In the English/Japanese phrases example in the "Multiple File
Crates" section of the "Crates and Modules" chapter, there are a total
of 8 module files that Rust looks for, while only four were
listed. This commit lists all 8 explicitly.
2. Title case fix.
The initial implementation of specialization did not use the
`fast_reject` mechanism when checking for overlap, which caused a
serious performance regression in some cases.
This commit modifies the specialization graph to use simplified types
for fast rejection when possible, and along the way refactors the logic
for building the specialization graph.
trans: don't declare symbols that were already imported.
Fixes #32740 by checking for a declaration before attempting a new one.
Before, `LLVMGetOrInsertFunction` was called for a existing import, but with a different type.
The returned value was a cast function pointer instead of a declaration, and we gave this
value to `llvm::SetFunctionCallConv` & friends , which triggered an LLVM assertion.
Specialize equality for [T] and comparison for [u8]
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] and by
extension &str.
This is an improvement for example for the comparison [u8] == [u8] that
used to emit a loop that compared the slices byte by byte.
One worry here could be that this introduces function calls to memcmp
in contexts where it should really inline the comparison or even
optimize it out, but llvm takes care of recognizing memcmp specifically.
Rollup merge of #32678 - mitaa:rdoc-stripped, r=alexcrichton
rustdoc: make rustdoc less pass-aware
Instead of hardcoding knowledge about the strip-private pass into the
rendering process we represent (some) stripped items as `ItemEnum::StrippedItem`.
Rustdoc will, for example, generate redirect pages for public items
contained in private modules which have been re-exported to somewhere
externally reachable - this will now not only work for the `strip-private`
pass, but for other passes as well, such as the `strip-hidden` pass.
Rollup merge of #32596 - soltanmm:lazy, r=nikomatsakis
Plumb obligations through librustc/infer
Like #32542, but more like #31867.
TODO before merge: make an issue for the propagation of obligations through... uh, everywhere... then replace the `#????`s with the actual issue number.
Auto merge of #29463 - jseyfried:master, r=nikomatsakis
Remove implicit binder from `FnSpace` in `VecPerParamSpace` (fixes #20526)
This removes the implicit binder from `FnSpace` in `VecPerParamSpace` so that `Binder<T>` is the only region binder (as described in issue #20526), and refactors away `enter_region_binder` and `exit_region_binder` from `TypeFolder`.
Alex Crichton [Mon, 21 Mar 2016 23:54:53 +0000 (16:54 -0700)]
std: Fix linking against `signal` on Android
Currently the minimum supported Android version of the standard library is
API level 18 (android-18). Back in those days [1] the `signal` function was
just an inline wrapper around `bsd_signal`, but starting in API level
android-20 the `signal` symbols was introduced [2]. Finally, in android-21
the API `bsd_signal` was removed [3].
Basically this means that if we want to be binary compatible with multiple
Android releases (oldest being 18 and newest being 21) then we need to check
for both symbols and not actually link against either.
This was first discovered in rust-lang/libc#236 with a fix proposed in
rust-lang/libc#237. I suspect that we'll want to accept rust-lang/libc#237 so
Rust crates at large continue to be compatible with newer releases of Android
and crates, like the standard library, that want to opt into older support can
continue to do so via similar means.
Auto merge of #32328 - jseyfried:coherence, r=nikomatsakis
resolve: Improve import failure detection and lay groundwork for RFC 1422
This PR improves import failure detection and lays some groundwork for RFC 1422.
More specifically, it
- Avoids recomputing the resolution of an import directive's module path.
- Refactors code in `resolve_imports` that does not scale to the arbitrarily many levels of visibility that will be required by RFC 1422.
- Replaces `ModuleS`'s fields `public_glob_count`, `private_glob_count`, and `resolved_globs` with a list of glob import directives `globs`.
- Replaces `NameResolution`'s fields `pub_outstanding_references` and `outstanding_references` with a field `single_imports` of a newly defined type `SingleImports`.
- Improves import failure detection by detecting cycles that include single imports (currently, only cycles of globs are detected). This fixes #32119.
Auto merge of #32647 - Amanieu:checked_atomic_intrinsics, r=eddyb
Only allow using the atomic intrinsics on integer types
Using these with non-integer types results in LLVM asserts. Atomic operations on non-integer types will require values be transmuted into an integer type of suitable size.
This doesn't affect the standard library since `AtomicBool` and `AtomicPtr` currently use `usize` for atomic operations.
Niko Matsakis [Tue, 29 Mar 2016 20:33:50 +0000 (16:33 -0400)]
fix corner case around top of stack
When deciding on a coinductive match, we were examining the new
obligation and the backtrace, but not the *current* obligation that goes
in between the two. Refactoring the code to just have the cycle given
as input also made things a lot simpler.
Auto merge of #32644 - oli-obk:check_all_constants_early, r=nrc
check constants even if they are not used in the current crate
For now this is just a `warn`-by-default lint. I suggest to make it a `deny`-by-default lint in the next release cycle (so no dependencies break), and then in another release cycle move to an error.