Commit Graph

52164 Commits

Author SHA1 Message Date
bors
9afa5a13cc Auto merge of #32273 - alexcrichton:fix-time-sub, r=aturon
std: Fix overflow when subtracting Instant

This code was currently only exercised on OSX, but this applies the same method
of subtraction used on Linux which doesn't have the same overflow issues.

Note that this currently includes no tests, but that's because this is only
visible with debug assertions enabled. Soon, however, I'll enable debug
assertions on all auto builds on the bots so we should get testing for this.

Closes #32268
2016-03-16 02:58:35 -07:00
Oliver Schneider
7a2c50f951 don't assume the rhs of a bitshift is of any particular type 2016-03-16 10:54:00 +01:00
Jeffrey Seyfried
b3c626547c Fix fallout in tests 2016-03-16 08:52:33 +00:00
Jeffrey Seyfried
65ec4dfe61 Improve diagnostics for duplicate names 2016-03-16 08:52:31 +00:00
bors
3317cc9d75 Auto merge of #32266 - alexcrichton:fix-mingw-rustbuild-again, r=brson
rustbuild: Fix LLVM compile on MinGW

The LLVM change [1] in #32239 unfortunately broke the LLVM build on MinGW, so
this LLVM submodule update brings in one more fix [2] which should hopefully
remedy that.

Once this lands we should be able to immediately start gating on this to prevent
it from happening again.

[1]: https://github.com/rust-lang/llvm/commit/be89e4b5
[2]: https://github.com/rust-lang/llvm/commit/3dcd2c84
2016-03-15 23:49:06 -07:00
Steven Fackler
50fda1eead Update rpass tests for panic hooks 2016-03-15 20:51:48 -07:00
Steven Fackler
157e1bc681 Make set_hook take a Box<Fn>
Otherwise there's no good way of re-registering a hook you got out of
take_hook.
2016-03-15 20:51:48 -07:00
Steven Fackler
159eae8b8b Rename panic handlers to panic hook 2016-03-15 20:51:48 -07:00
Stu Black
2ddba6f361 Use issue number from rust-lang/rust, not rust-lang/rfcs. 2016-03-15 23:48:15 -04:00
Jorge Aparicio
34a44b5911 update compiler-rt submodule
fixes #32194
2016-03-15 22:32:38 -05:00
bors
0986d645b9 Auto merge of #32236 - alexcrichton:better-compile-intrinsics, r=arielb1
rustc: Improve compile time of platform intrinsics

This commit improves the compile time of `rustc_platform_intrinsics` from 23s to
3.6s if compiling with `-O` and from 77s to 17s if compiling with `-O -g`. The
compiled rlib size also drops from 3.1M to 1.2M.

The wins here were gained by removing the destructors associated with `Type` by
removing the internal `Box` and `Vec` indirections. These destructors meant that
a lot of landing pads and extra code were generated to manage the runtime
representations. Instead everything can basically be statically computed and
shoved into rodata, so all we need is a giant string compare to lookup what's
what.

Closes #28273
2016-03-15 19:41:01 -07:00
Alex Crichton
87ede2da54 rustc: Improve compile time of platform intrinsics
This commit improves the compile time of `rustc_platform_intrinsics` from 23s to
3.6s if compiling with `-O` and from 77s to 17s if compiling with `-O -g`. The
compiled rlib size also drops from 3.1M to 1.2M.

The wins here were gained by removing the destructors associated with `Type` by
removing the internal `Box` and `Vec` indirections. These destructors meant that
a lot of landing pads and extra code were generated to manage the runtime
representations. Instead everything can basically be statically computed and
shoved into rodata, so all we need is a giant string compare to lookup what's
what.

Closes #28273
2016-03-15 17:32:34 -07:00
Alex Crichton
0943b1668d std: Fix overflow when subtracting Instant
This code was currently only exercised on OSX, but this applies the same method
of subtraction used on Linux which doesn't have the same overflow issues.

Note that this currently includes no tests, but that's because this is only
visible with debug assertions enabled. Soon, however, I'll enable debug
assertions on all auto builds on the bots so we should get testing for this.

Closes #32268
2016-03-15 15:19:11 -07:00
bors
c66d2380a8 Auto merge of #31838 - aochagavia:trans, r=nrc
Refactor rustc_trans::save to allow other backends than CSV

r? @nrc

Things done:
* Moved `(.*)Data` structs to an own module, so they can be imported easily (`use data::*`).
* Created a `Dump` trait with callbacks for dumping items.
* Refactored `DumpCsvVisitor` to use an implementor of `Dump` instead of dumping as CSV. Renamed it to `DumpVisitor`.
* Created a `DumpCsv` struct that implements `Dump` and serializes items as CSV.

I tried to extract some of the logic contained in `FmtStr` and `Recorder`, such as normalization of ids (I put it in `DumpVisitor`). I think it makes sense to provide the same information to other implementors of `Dump`, instead of normalizing only for `DumpCsv`. However, there is still some logic related to spans implemented only for `DumpCsv`. I just thought it would be better to merge this as soon as possible, since there are so much changes, and fix this afterwards.
2016-03-15 15:03:00 -07:00
Adolfo Ochagavía
67395d816f Refactor rustc_trans::save
Move rustc_trans::*Data to own module
Add new data to rustc_trans::save
Create a Dump trait implemented by structs that dump save analysis data
Split dump_csv into a DumpVisitor and a CsvDumper
2016-03-15 22:50:18 +01:00
Alex Crichton
41e184c7b6 rustbuild: Fix LLVM compile on MinGW
The LLVM change [1] in #32239 unfortunately broke the LLVM build on MinGW, so
this LLVM submodule update brings in one more fix [2] which should hopefully
remedy that.

Once this lands we should be able to immediately start gating on this to prevent
it from happening again.

[1]: https://github.com/rust-lang/llvm/commit/be89e4b5
[2]: https://github.com/rust-lang/llvm/commit/3dcd2c84
2016-03-15 14:07:55 -07:00
Corey Farwell
6ed7846257 Add comment about opt-in nature of compiletest note/help messages.
The opt-in functionality was proposed and discussed in
https://github.com/rust-lang/rust/issues/21195
2016-03-15 16:33:59 -04:00
bors
74dfc1ddd9 Auto merge of #31887 - SimonSapin:quiet-test, r=alexcrichton
Shorter output for `rustc --test` binaries.

Until now, a program created with `rustc --test` prints at least one line per test. This can be very verbose, especially with [data-driven tests](https://internals.rust-lang.org/t/test-and-external-test-harnesses/3145) when hundreds or thousands of tests is not rare.

This changes the default output to one character per test (except metrics and benchmarks results which have additional data to show):

```
     Running target/debug/wpt-75c594dc1e6e6187

running 314 tests
..............................................................................
..............................................................................
..............................................................................
..............................................................................
..
test result: ok. 314 passed; 0 failed; 0 ignored; 0 measured
```

<s>The previous behavior is available by passing `--verbose` to the test program. Maybe `cargo test --verbose` could be changed to do that?</s> **Edit:** the default is now unchanged, `-q` or `--quiet` enables the new output.
2016-03-15 12:58:49 -07:00
Richo Healey
178b28099f syntax: impl ToTokens for P<ast::ImplItem> 2016-03-15 19:50:11 +01:00
Simon Sapin
d23fd711eb Add a test for --quiet in test harness. 2016-03-15 17:59:01 +01:00
Simon Sapin
bbb45c41df Shorter output for rustc --test binaries.
A program created with `rustc --test` prints at least one line per test.
This can be very verbose, especially with [data-driven tests](
https://internals.rust-lang.org/t/test-and-external-test-harnesses/3145)
when hundreds or thousands of tests is not rare.

This adds a `-q` or `--quiet` option that changes the output
to one character instead of one line per test
(except metrics and benchmarks results which have additional data to
show):

```
     Running target/debug/wpt-75c594dc1e6e6187

running 314 tests
..............................................................................
..............................................................................
..............................................................................
..............................................................................
..
test result: ok. 314 passed; 0 failed; 0 ignored; 0 measured
```

This is a breaking change since the `test::TestOpts` struct
now has one more field.
2016-03-15 17:59:01 +01:00
bors
1efa752ea6 Auto merge of #32251 - durka:derive-2810, r=alexcrichton
derive: clean up hygiene

derive: clean up hygiene

Fixes #2810.

Spawned from #32139.

r? @alexcrichton
2016-03-15 09:45:57 -07:00
Tang Chenglong
94ee40a5d4 FreeBSD has already supported Cargo
Both Packages and Ports of FreeBSD have Cargo in present.
2016-03-16 00:15:40 +08:00
bors
f9121e87a6 Auto merge of #32250 - durka:derive-31574, r=alexcrichton
derive: use intrinsics::unreachable over unreachable!()

derive: use intrinsics::unreachable over unreachable!()

Fixes #31574.

Spawned from #32139.

r? @alexcrichton
2016-03-15 06:51:30 -07:00
bors
483fc715c6 Auto merge of #32239 - alexcrichton:fix-cross-to-freebsd, r=brson
rustbuild: Fix cross compiling to FreeBSD

This commit fixes our support for cross compiling a compiler to run on FreeBSD.
Over the weekend I managed to get a cross compiler from Linux to FreeBSD [1]
which I hope to soon use to start producing FreeBSD nightly compilers. With the
`make dist` support added in #32237 we should be able to produce standard
rustc/rust-std packages for FreeBSD through a new slave with this cross compiler.

Currently, however, we don't "Just Work" when cross compiling FreeBSD and a
number of changes were required (part of this PR). They include:

* A few build fixes were needed in LLVM. Our own branch has been rebased on the
  actual 3.8 release and I applied one extra commit [2] which contains two fixes:

  1. The LLVM CMake build system passes the `-Wl,-z,defs` flag on many
     platforms, but *not* when `CMAKE_SYSTEM_NAME` is "FreeBSD". Unfortunately
     this doesn't take into account when we're cross compiling, and as predicted
     the build will fail if `-Wl,-z,defs` is passed (see [3] for more info). To
     fix this we test `TARGET_TRIPLE` instead of the `CMAKE_SYSTEM_NAME` which
     is what we're compiling for which fixes the problem.
  2. The `PATH_MAX` constant is apparently defined in a different location than
     many other Unix systems, so a file which required this just needed some
     help to keep compiling.

* Support for compiling compiler-rt with CMake has been added to rustbuild. It
  looks like it just emulates Linux in what it compiles as it didn't seem to
  naturally produce anything else... At least the architecture is right, so
  seems good for now at least!

[1]: https://github.com/alexcrichton/port-of-rust/blob/master/prebuilt/freebsd/Dockerfile
[2]: https://github.com/rust-lang/llvm/commit/be89e4b5
[3]: https://bugs.webkit.org/show_bug.cgi?id=138420
2016-03-15 03:21:40 -07:00
bors
4db8b5bfdf Auto merge of #32238 - frewsxcv:compiletest, r=alexcrichton
Utilize `Option::cloned` over explicit `clone` usage.
2016-03-15 00:10:29 -07:00
Alex Crichton
4124466197 std: Fix inheriting stdin on status()
This regression was accidentally introduced in #31618, and it's just flipping a
boolean!

Closes #32254
2016-03-14 22:46:42 -07:00
bors
34b95a3c6a Auto merge of #32206 - alexcrichton:fix-windows-rustbuild, r=brson
Fix Windows rustbuild

These commits fix the rustbuild Windows bots, namely:

* The 32-bit build of LLVM was failing because libraries weren't being linked. This was in turn caused by the build script for `rustc_llvm` erroneously detecting that it was cross compiling when it actually wasn't.
* Tools of the build were compiled against the wrong libraries, so running them would fail on Windows as rpath didn't exist and `PATH` was wrong.
* Some linkchecker fixes for Windows paths had to be applied as well.
2016-03-14 21:09:37 -07:00
bors
9ca75619dc Auto merge of #30652 - aturon:specialization, r=nikomatsakis
Implement RFC 1210: impl specialization

This PR implements [impl specialization](https://github.com/rust-lang/rfcs/pull/1210),
carefully following the proposal laid out in the RFC.

The implementation covers the bulk of the RFC. The remaining gaps I know of are:

- no checking for lifetime-dependent specialization (a soundness hole);
- no `default impl` yet;
- no support for `default` with associated consts;

I plan to cover these gaps in follow-up PRs, as per @nikomatsakis's preference.

The basic strategy is to build up a *specialization graph* during
coherence checking. Insertion into the graph locates the right place
to put an impl in the specialization hierarchy; if there is no right
place (due to partial overlap but no containment), you get an overlap
error. Specialization is consulted when selecting an impl (of course),
and the graph is consulted when propagating defaults down the
specialization hierarchy.

You might expect that the specialization graph would be used during
selection -- i.e., when actually performing specialization. This is
not done for two reasons:

- It's merely an optimization: given a set of candidates that apply,
  we can determine the most specialized one by comparing them directly
  for specialization, rather than consulting the graph. Given that we
  also cache the results of selection, the benefit of this
  optimization is questionable.

- To build the specialization graph in the first place, we need to use
  selection (because we need to determine whether one impl specializes
  another). Dealing with this reentrancy would require some additional
  mode switch for selection. Given that there seems to be no strong
  reason to use the graph anyway, we stick with a simpler approach in
  selection, and use the graph only for propagating default
  implementations.

Trait impl selection can succeed even when multiple impls can apply,
as long as they are part of the same specialization family. In that
case, it returns a *single* impl on success -- this is the most
specialized impl *known* to apply. However, if there are any inference
variables in play, the returned impl may not be the actual impl we
will use at trans time. Thus, we take special care to avoid projecting
associated types unless either (1) the associated type does not use
`default` and thus cannot be overridden or (2) all input types are
known concretely.

r? @nikomatsakis
2016-03-14 17:55:41 -07:00
Alex Crichton
155735aa51 rustbuild: Fix cross compiling to FreeBSD
This commit fixes our support for cross compiling a compiler to run on FreeBSD.
Over the weekend I managed to get a cross compiler from Linux to FreeBSD [1]
which I hope to soon use to start producing FreeBSD nightly compilers. With the
`make dist` support added in #32237 we should be able to produce standard
rustc/rust-std packages for FreeBSD through a new slave with this cross compiler.

Currently, however, we don't "Just Work" when cross compiling FreeBSD and a
number of changes were required (part of this PR). They include:

* A few build fixes were needed in LLVM. Our own branch has been rebased on the
  actual 3.8 release and I applied one extra commit [2] which contains two fixes:

  1. The LLVM CMake build system passes the `-Wl,-z,defs` flag on many
     platforms, but *not* when `CMAKE_SYSTEM_NAME` is "FreeBSD". Unfortunately
     this doesn't take into account when we're cross compiling, and as predicted
     the build will fail if `-Wl,-z,defs` is passed (see [3] for more info). To
     fix this we test `TARGET_TRIPLE` instead of the `CMAKE_SYSTEM_NAME` which
     is what we're compiling for which fixes the problem.
  2. The `PATH_MAX` constant is apparently defined in a different location than
     many other Unix systems, so a file which required this just needed some
     help to keep compiling.

* Support for compiling compiler-rt with CMake has been added to rustbuild. It
  looks like it just emulates Linux in what it compiles as it didn't seem to
  naturally produce anything else... At least the architecture is right, so
  seems good for now at least!

[1]: https://github.com/alexcrichton/port-of-rust/blob/master/prebuilt/freebsd/Dockerfile
[2]: https://github.com/rust-lang/llvm/commit/be89e4b5
[3]: https://bugs.webkit.org/show_bug.cgi?id=138420
2016-03-14 15:07:36 -07:00
Aaron Turon
6562eeb053 Add pretty printer output for default 2016-03-14 15:05:16 -07:00
Aaron Turon
dc45d924b6 Adjust error code 2016-03-14 15:05:15 -07:00
Aaron Turon
c4f78ad7bf Parse fail test fixes 2016-03-14 15:05:15 -07:00
Aaron Turon
e5753b4605 Fixes after rebase 2016-03-14 15:05:15 -07:00
Aaron Turon
e36620dd9c Introduce ICE when the topmost projection restriction kicks in, as per issue #32205 2016-03-14 15:05:15 -07:00
Aaron Turon
d80189d305 Test fixes, added README for tests 2016-03-14 15:05:14 -07:00
Aaron Turon
326201657a Move tests to dedicated subdirectories 2016-03-14 15:05:14 -07:00
Aaron Turon
35437c7cf6 Fixes after a rebase 2016-03-14 15:05:14 -07:00
Aaron Turon
8f0e73ef55 Address review comments 2016-03-14 15:05:13 -07:00
Aaron Turon
9bcfdb7b9c Move projection_mode to InferContext rather than SelectionContext to reduce chance of bugs 2016-03-14 15:05:13 -07:00
Aaron Turon
386f8eefc0 Forbid cross-polarity specializations 2016-03-14 15:04:41 -07:00
Aaron Turon
2651f8c147 Add regression tests from initial implementation review 2016-03-14 15:04:41 -07:00
Aaron Turon
1726c1b54a Add some debugging output for specialization graph assembly 2016-03-14 15:04:40 -07:00
Aaron Turon
eaf2f90956 Refactor core specialization and subst translation code to avoid
danger of inference variables floating around without their inference
context.

The main insight here is that, when we are translating substitutions
between two impls, *we already know that the more specific impl holds*,
so we do not need to add its obligations to the parameter
environment. Instead, we can just thread through the inference context
we used to show select the more specific impl in the first place.
2016-03-14 15:04:40 -07:00
Aaron Turon
8f20cbf030 Add more commentary for subst translation 2016-03-14 15:04:40 -07:00
Aaron Turon
940adda2ae Move specialization graph walks to iterators; make associated type
projection sensitive to "mode" (most importantly, trans vs middle).

This commit introduces several pieces of iteration infrastructure in the
specialization graph data structure, as well as various helpers for
finding the definition of a given item, given its kind and name.

In addition, associated type projection is now *mode-sensitive*, with
three possible modes:

- **Topmost**. This means that projection is only possible if there is a
    non-`default` definition of the associated type directly on the
    selected impl. This mode is a bit of a hack: it's used during early
    coherence checking before we have built the specialization
    graph (and therefore before we can walk up the specialization
    parents to find other definitions). Eventually, this should be
    replaced with a less "staged" construction of the specialization
    graph.

- **AnyFinal**. Projection succeeds for any non-`default` associated
    type definition, even if it is defined by a parent impl. Used
    throughout typechecking.

- **Any**. Projection always succeeds. Used by trans.

The lasting distinction here is between `AnyFinal` and `Any` -- we wish
to treat `default` associated types opaquely for typechecking purposes.

In addition to the above, the commit includes a few other minor review fixes.
2016-03-14 15:04:40 -07:00
Aaron Turon
462c83e272 Address basic nits from initial review 2016-03-14 15:04:39 -07:00
Aaron Turon
9734406a5f Assorted fixed after rebasing 2016-03-14 15:04:39 -07:00
Aaron Turon
c1df41e776 Add some basic comments about how specialization fits into the rest of the trait machinery 2016-03-14 15:04:39 -07:00
Aaron Turon
ed8d059d8d Adjust tests for feature gate, and add tests for the gate itself 2016-03-14 15:04:38 -07:00