This PR adds a `UnificationTable` to the `TypeVariableTable` type which
is used store information about variable equality instead of just
storing them in a vector for later processing. By using a
`UnificationTable` equality relations can be resolved in O(n) (for all
realistic values of n) rather than O(n!) which can give massive
speedups in certain cases (see combine as an example).
Link to combine: https://github.com/Marwes/combine
bors [Mon, 7 Mar 2016 04:25:27 +0000 (04:25 +0000)]
Auto merge of #32066 - ruud-v-a:fma, r=alexcrichton
This adds support for fused multiply-add and multiply-subtract vector intrinsics for 128 and 256-bit vectors of `f32` and `f64`. These correspond to the intrinsics [listed here](https://software.intel.com/en-us/node/523929) except for the `_ss` and `_sd` variants. The intrinsics added are:
bors [Mon, 7 Mar 2016 02:28:09 +0000 (02:28 +0000)]
Auto merge of #32064 - bluss:str-slice-panic, r=alexcrichton
Fix panic on string slicing error to truncate the string
The string may be arbitrarily long, but we want to limit the panic
message to a reasonable length. Truncate the string if it is too long
(simply to char boundary).
Also add details to the start <= end message. I think it's ok to flesh
out the code here, since it's in a cold function.
bors [Mon, 7 Mar 2016 00:30:09 +0000 (00:30 +0000)]
Auto merge of #32061 - infinity0:master, r=alexcrichton
Adding -Wno-error is more reliable and simple than trying to modify existing
flags. We've been using this in Debian already for the past few releases.
Making this change also encourages future maintainers towards "best practises".
Also take the opportunity to use the same method at all places in the file.
bors [Sun, 6 Mar 2016 15:10:44 +0000 (15:10 +0000)]
Auto merge of #32048 - bluss:overloaded-assign-op, r=eddyb
Do not trigger unused_assignments for overloaded AssignOps
If `v` were a type with some kind of indirection, so that `v += 1` would
have an effect even if `v` were not used anymore, the unused_assignments lint
would mark a false positive.
This exempts overloaded (non-primitive) assign ops from being treated as
assignments (they are method calls).
The previous compile-fail tests that ensure x += 1 can trigger for
primitive types continue to pass. Added a representative test for the
"view" indirection.
bors [Sun, 6 Mar 2016 07:16:41 +0000 (07:16 +0000)]
Auto merge of #30884 - durka:inclusive-ranges, r=aturon
This PR implements [RFC 1192](https://github.com/rust-lang/rfcs/blob/master/text/1192-inclusive-ranges.md), which is triple-dot syntax for inclusive range expressions. The new stuff is behind two feature gates (one for the syntax and one for the std::ops types). This replaces the deprecated functionality in std::iter. Along the way I simplified the desugaring for all ranges.
This is my first contribution to rust which changes more than one character outside of a test or comment, so please review carefully! Some of the individual commit messages have more of my notes. Also thanks for putting up with my dumb questions in #rust-internals.
- For implementing `std::ops::RangeInclusive`, I took @Stebalien's suggestion from https://github.com/rust-lang/rfcs/pull/1192#issuecomment-137864421. It seemed to me to make the implementation easier and increase type safety. If that stands, the RFC should be amended to avoid confusion.
- I also kind of like @glaebhoerl's [idea](https://github.com/rust-lang/rfcs/pull/1254#issuecomment-147815299), which is unified inclusive/exclusive range syntax something like `x>..=y`. We can experiment with this while everything is behind a feature gate.
- There are a couple of FIXMEs left (see the last commit). I didn't know what to do about `RangeArgument` and I haven't added `Index` impls yet. Those should be discussed/finished before merging.
cc @Gankro since you [complained](https://www.reddit.com/r/rust/comments/3xkfro/what_happened_to_inclusive_ranges/cy5j0yq)
cc #27777 #30877 rust-lang/rust#1192 rust-lang/rfcs#1254
relevant to #28237 (tracking issue)
bors [Sun, 6 Mar 2016 02:29:34 +0000 (02:29 +0000)]
Auto merge of #31920 - jseyfried:fix_spurious_privacy_error, r=nikomatsakis
This PR allows using methods from traits that are visible but are defined in an inaccessible module (fixes #18241). For example,
```rust
mod foo {
pub use foo::bar::Tr;
mod bar { // This module is inaccessible from `g`
pub trait Tr { fn f(&self) {} }
}
}
fn g<T: foo::Tr>(t: T) {
t.f(); // Currently, this is a privacy error even though `foo::Tr` is visible
}
```
After this PR, it will continue to be a privacy error to use a method from a trait that is not visible. This can happen when a public trait inherits from a private trait (in violation of the `public_in_private` lint) -- see @petrochenkov's example in #28504.
r? @nikomatsakis
bors [Sat, 5 Mar 2016 23:44:51 +0000 (23:44 +0000)]
Auto merge of #31889 - alexcrichton:update-jemalloc-again, r=nikomatsakis
Now that https://github.com/jemalloc/jemalloc/commit/767d85061a6fb88ec977bbcd9b429a43aff391e6 is upstream, the relevant deadlocking issue which prompted our downgrade has been resolved. As a result, there's no known issue to *not* upgrade! This also re-enables jemalloc for the pc-windows-gnu target as known issues with that have also been fixed.
bors [Sat, 5 Mar 2016 20:11:37 +0000 (20:11 +0000)]
Auto merge of #31726 - jseyfried:improve_import_resolution, r=nikomatsakis
This PR improves the import resolution algorithm.
First, it records that an import succeeded or failed for one namespace (by calling `decrement_outstanding_references_for` and `try_define_child` if successful) even if it is still indeterminate in the other namespace, fixing #31444.
Second, it starts importing bindings from globs as soon as the glob path is determined.
It maintains links from imported modules to their importers so that when a resolution becomes successful in an imported module, a corresponding binding will be added to the importer module.
It also maintains links from importer modules to imported modules so that we can determine if an undefined name is indeterminate or failing by recursively checking this in the imported modules.
This allows, for example:
```rust
mod foo {
pub mod baz {}
pub use bar::baz::*;
}
mod bar {
pub use foo::*;
}
```
It also allows cycles of pub glob imports, although by to the current shadowing rules, the only way for such a cycle to compile is if each participating module defines no names. Incidentally, this PR lays the groundwork for more permissive feature-gated shadowing rules.
Finally, this PR encapsulates almost all implementation details of import resolution in `resolve_imports` (some of which used to be in `lib.rs`) and refactors reexport recording, shadowed trait collecting, some duplicate checking, and the `private_in_public` lint out of the core import resolution algorithm and into a post-processing pass in `resolve_imports`.
Ulrik Sverdrup [Sat, 5 Mar 2016 17:09:14 +0000 (18:09 +0100)]
Fix panic on string slicing error to truncate the string
The string may be arbitrarily long, but we want to limit the panic
message to a reasonable length. Truncate the string if it is too long
(simply to char boundary).
Also add details to the start <= end message. I think it's ok to flesh
out the code here, since it's in a cold function.
The file it generates had been modified, but instead the generator
should have been modified, and the file regenerated. This merges the
modifications into the template in the generator.
The intrinsics there are listed under AVX2, but in the Intel Intrinsic
Guide they are part of the "FMA" technology, and LLVM puts them under
FMA, not AVX2.
Angus Lees [Sun, 24 Jan 2016 10:07:47 +0000 (21:07 +1100)]
More reliable and consistent method of cancelling -Werror*
Adding -Wno-error is more reliable and simple than trying to modify existing
flags. We've been using this in Debian already for the past few releases.
Making this change also encourages future maintainers towards "best practises".
Also take the opportunity to use the same method at all places in the file.
Ulrik Sverdrup [Fri, 4 Mar 2016 20:01:59 +0000 (21:01 +0100)]
Do not trigger unused_assignments for overloaded AssignOps
If `v` were a type with some kind of indirection, so that `v += 1` would
have an effect even if `v` were not used anymore, the unused_assignments lint
would mark a false positive.
This exempts overloaded (non-primitive) assign ops from being treated as
assignments (they are method calls).
The previous compile-fail tests that ensure x += 1 can trigger for
primitive types continue to pass. Added a representative test for the
"view" indirection.
Alex Crichton [Thu, 25 Feb 2016 17:51:45 +0000 (09:51 -0800)]
test: Clean up alloc_jemalloc usage in tests
Right now there's just a smattering of `// ignore-foo` platforms which is ever
expanding as new ones are added. Instead switch to only running these tests on
Linux/OSX and then use a guaranteed-to-work but not-as-well-tested alternative
on other platforms.
bors [Fri, 4 Mar 2016 13:47:02 +0000 (13:47 +0000)]
Auto merge of #32022 - gohyda:master, r=alexcrichton
- Empty `.sidebar .location` caused "grey line" on top of the documentation page (under 700px) fixed.
- `.sidebar .location` appearance improvement in responsive mode.
bors [Fri, 4 Mar 2016 06:55:11 +0000 (06:55 +0000)]
Auto merge of #32006 - jseyfried:fix_expanded_mod_path, r=nikomatsakis
This PR changes the search paths for macro-expanded non-inline modules so that they match ordinary non-inline modules (fixes #31624). This is a [breaking-change].
Right now, the search paths for a macro-expanded non-inline module are computed as if the module were declared in the top level of the file in which the macro was defined.
For example, consider `./foo/mod.rs`:
```rust
mod inconsequential { // moving the macro outside this module wouldn't change anything
macro_rules! mod_decl {
($i:ident) => { mod $i; }
}
}
```
and `./lib.rs`:
```rust
mod foo;
mod bar {
mod_decl!(baz);
//^ Now, rustc expects `./foo/baz.rs` (or `./foo/baz/mod.rs`)
//| After this PR, rustc will expect `./bar/baz.rs` (or `./bar/baz/mod.rs`)
}
```
r? @alexcrichton
bors [Thu, 3 Mar 2016 17:41:13 +0000 (17:41 +0000)]
Auto merge of #32007 - nikomatsakis:compiletest-incremental, r=alexcrichton
This PR extends compiletest to support **test revisions** and with a preliminary **incremental testing harness**. run-pass, compile-fail, and run-fail tests may be tagged with
```
// revisions: a b c d
```
This will cause the test to be re-run four times with `--cfg {a,b,c,d}` in turn. This means you can write very closely related things using `cfg`. You can also configure the headers/expected-errors by writing `//[foo] header: value` or `//[foo]~ ERROR bar`, where `foo` is the name of your revision. See the changes to `coherence-cow.rs` as a proof of concept.
The main point of this work is to support the incremental testing harness. This PR contains an initial, unused version. The code that uses it will land later. The incremental testing harness compiles each revision in turn, and requires that the revisions have particular names (e.g., `rpass2`, `cfail3`), which tell it whether a particular revision is expected to compile or not.
Two questions:
- Is there compiletest documentation anywhere I can update?
- Should I hold off on landing the incremental testing harness until I have the code to exercise it? (That will come in a separate PR, still fixing a few details)
r? @alexcrichton
cc @rust-lang/compiler <-- new testing capabilities
Andrea Canciani [Thu, 3 Mar 2016 09:06:09 +0000 (10:06 +0100)]
Hide gated cfg attributes from the output of `--print cfg`
Gated cfg attributes are not available on the stable and beta release
channels, therefore they should not be presented to users of those
channels in order to avoid confusion.
bors [Thu, 3 Mar 2016 08:35:51 +0000 (08:35 +0000)]
Auto merge of #32012 - bluss:more-drop-in-place, r=alexcrichton
Use `drop_in_place` in Vec and VecDeque
We can use drop_in_place's DST capabilities directly in Vec::drop and similarly in VecDeque::drop. I verfied this has the same effect as the previous `needs_drop` code; `drop_in_place` it itself an intrinsic.
The VecDeque replacement should be more efficient too, even in release mode (slice iteration makes a more efficient loop than the deque iterator).
bors [Thu, 3 Mar 2016 02:21:28 +0000 (02:21 +0000)]
Auto merge of #31824 - jseyfried:privacy_in_resolve, r=nikomatsakis
This PR privacy checks paths as they are resolved instead of in `librustc_privacy` (fixes #12334 and fixes #31779). This removes the need for the `LastPrivate` system introduced in PR #9735, the limitations of which cause #31779.
This PR also reports privacy violations in paths to intra- and inter-crate items the same way -- it always reports the first inaccessible segment of the path.
Since it fixes #31779, this is a [breaking-change]. For example, the following code would break:
```rust
mod foo {
pub use foo::bar::S;
mod bar { // `bar` should be private to `foo`
pub struct S;
}
}
impl foo::S {
fn f() {}
}
fn main() {
foo::bar::S::f(); // This is now a privacy error
}
```
Andrea Canciani [Wed, 2 Mar 2016 21:07:03 +0000 (22:07 +0100)]
Build the same configuration when compiling and for `--print cfg`
The configuration returned by `config::build_configuration` needs to
be modified with `target_features::add_configuration` in order to also
contain the target features. This is already done for the
configuration used when compiling and when creating the documentation,
but was missing in the `cfg` printing code.
Ulrik Sverdrup [Wed, 2 Mar 2016 16:54:43 +0000 (17:54 +0100)]
Use ptr::drop_in_place in VecDeque::drop
Just like for Vec. This should benefit both non-optimized and optimized
performance. Non-optimized since the intrinsic drop_in_place is easily
removed, and optimized because iterating the slices is more efficient
than using the VecDeque iterators.
projects / rust.git / log