Commit Graph

51316 Commits

Author SHA1 Message Date
Richo Healey
178b28099f syntax: impl ToTokens for P<ast::ImplItem> 2016-03-15 19:50:11 +01: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
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
Aaron Turon
e816910398 Add feature gate 2016-03-14 15:04:38 -07:00
Aaron Turon
9f16c2ce59 Adjust coherence test to reflect that only the orphan rule prevents you from adding *generalizing* impls 2016-03-14 15:04:38 -07:00
Aaron Turon
7976e36544 Adjust test for new overlap message on default trait impls 2016-03-14 15:04:38 -07:00
Aaron Turon
d8160799b5 Adjust overlap-related tests to account for cosmetic changes to error reporting behavior 2016-03-14 15:04:37 -07:00
Aaron Turon
a3825827b7 Add tests for specialization on associated types 2016-03-14 15:04:37 -07:00
Aaron Turon
b7e5112e88 Implement default associated type inheritance.
This commit leverages the specialization graph infrastructure to allow
specializing trait implementations to leave off associated types for
which their parents have provided defaults.

It also modifies the type projection code to avoid projecting associated
types unless either (1) all input types are fully known or (2) the
available associated type is "final", i.e. not marked `default`.
This restriction is required for soundness, due to examples like:

```rust
trait Foo {
    type Assoc;
}

impl<T> Foo for T {
    default type Assoc = ();
}

impl Foo for u8 {
    type Assoc = String;
}

fn generic<T>() -> <T as Foo>::Assoc {
    () //~ ERROR
}

fn main() {
    let s: String = generic::<u8>();
    println!("{}", s); // bad news
}
```
2016-03-14 15:04:37 -07:00
Aaron Turon
5dedbdaea4 Check for proper use of default keyword in specializing impls. 2016-03-14 15:04:36 -07:00
Aaron Turon
1077ff2dec Add basic specialization tests, including for default item
inheritance. Updates some of the coherence tests as well.
2016-03-14 15:04:36 -07:00
Aaron Turon
7e42a78016 Implement default method inheritance.
This commit leverages the specialization graph infrastructure to allow
specializing trait implementations to leave off methods for which their
parents have provided defaults.

It does not yet check that the `default` keyword is appropriately used
in such cases.
2016-03-14 15:04:36 -07:00
Aaron Turon
957ee5ce34 Add subst helper for inheriting FnSpace from another subst 2016-03-14 15:04:35 -07:00
Aaron Turon
1f34086e94 Initial incorporation of specialization:
- Rewrites the overlap checker to instead build up a specialization
  graph, checking for overlap errors in the process.

- Use the specialization order during impl selection.

This commit does not yet handle associated types correctly, and assumes
that all items are `default` and are overridden.
2016-03-14 15:04:35 -07:00
Aaron Turon
c5849e4dff Add specialization module.
The module contains a few important components:

- The `specialize` function, which determines whether one impl is a
  specialization of another.

- The `SpecializationGraph`, a per-trait graph recording the
  specialization tree. The main purpose of the graph is to allow
  traversals upwards (to less specialized impls) for discovering
  un-overridden defaults, and for ensuring that overridden items are
  allowed to be overridden.
2016-03-14 15:04:34 -07:00
Aaron Turon
45f4bf112a Refactor impl_trait_ref_and_oblig, making it generally available as a utility 2016-03-14 15:04:34 -07:00
Aaron Turon
991f32a6ca Hook default keyword into metadata and carry data through to typeck 2016-03-14 15:04:34 -07:00
Aaron Turon
8fe63e2342 Add default as contextual keyword, and parse it for impl items. 2016-03-14 15:04:33 -07:00
Aaron Turon
659ba09b2d Remove useless vector accumulation in type_vars_for_defs 2016-03-14 15:04:33 -07:00
Aaron Turon
736603424e Fix existing comment typo. 2016-03-14 15:04:33 -07:00
Alex Crichton
158b854fb7 linkchecker: Fix path checks on Windows 2016-03-14 14:56:49 -07:00
Alex Crichton
8cd1c17d90 rustbuild: Refactor stage arguments away
The facet of a stage is rarely relevant when running a tool or building
something, it's all a question of what stage the *compiler* is built in. We've
already got a nice handy `Compiler` structure to carry this information, so
let's use it!

This refactors the signature of the `Build::cargo` function two ways:

1. The `stage` argument is removed, this was just duplicated with the `compiler`
   argument's stage field.
2. The `target` argument is now required. This was a bug where if the `--target`
   flag isn't passed then the snapshot stage0 compiler is always used, so we
   won't pick up any changes.

Much of the other changes in this commit are just propagating these decisions
outwards. For example many of the `Step` variants no longer have a stage
argument as they're baked into the compiler.
2016-03-14 14:56:49 -07:00
Alex Crichton
4a917e050d rustbuild: Use tool_cmd() instead of tool()
This sets up the dynamic loader path for dylibs required, so should fix the MSVC
build right now.
2016-03-14 14:56:49 -07:00
Alex Crichton
6ccf03c843 rustbuild: Fix 32-bit Windows build
Unfortunately on i686-pc-windows-gnu LLVM's answer to `--host-target` is
`x86_64-pc-windows-gnu` even though we're building in a 32-bit shell as well as
compiling 32-bit libraries. For now use Cargo's `HOST` environment variable to
determine whether we're doing a cross compilation or not.
2016-03-14 14:56:48 -07:00
bors
6d215fe04c Auto merge of #32169 - mitaa:anon-tip, r=nrc
Allow custom filenames for anonymous inputs

This came out of #29253 but doesn't fix it.

I thought it might be worth merging on its own nonetheless.
2016-03-14 14:44:55 -07:00
Alex Burka
a09a41928f derive: emit intrinsics::unreachable for impls on empty enums
fixes #31574
2016-03-14 16:47:04 -04:00