Commit Graph

2125 Commits

Author SHA1 Message Date
Michael Woerister
bd1ce91249 Add rustc_data_structures to rustc_driver dependencies. 2016-10-30 19:14:18 -04:00
bors
5db21c3af6 Auto merge of #37387 - raphlinus:fuchsia_aarch64, r=alexcrichton
Support for aarch64 architecture on Fuchsia

This patch adds support for the aarch64-unknown-fuchsia target. Also
updates src/liblibc submodule to include required libc change.
2016-10-29 00:28:39 -07:00
Nick Cameron
15821caee9 Split up libproc_macro_plugin
Separate the plugin code from non-plugin code to break a potential cycle in crates.

This will allow us to merge the new libproc_macro_tokens into libproc_macro.
2016-10-28 12:17:17 +13:00
Raph Levien
c4651dba5f Support for aarch64 architecture on Fuchsia
This patch adds support for the aarch64-unknown-fuchsia target. Also
updates src/liblibc submodule to include required libc change.
2016-10-24 16:58:35 -07:00
bors
3caf63cc00 Auto merge of #37313 - raphlinus:fuchsia, r=alexcrichton
Add Fuchsia support

Adds support for the x86_64-unknown-fuchsia target, which covers the
Fuchsia operating system.
2016-10-24 13:31:29 -07:00
Alex Crichton
174838f7f9 mk: Filter debuginfo=1 from test flags
Fixes tests with `--enable-debuginfo-lines`.
2016-10-23 10:20:48 -07:00
Raph Levien
76bac5d33e Add Fuchsia support
Adds support for the x86_64-unknown-fuchsia target, which covers the
Fuchsia operating system.
2016-10-22 07:08:06 -07:00
bors
e4708273b5 Auto merge of #37280 - alexcrichton:debuginfo, r=brson
Enable line number debuginfo in releases

This commit enables by default passing the `-C debuginfo=1` argument to the
compiler for the stable, beta, and nightly release channels. A new configure
option was also added, `--enable-debuginfo-lines`, to enable this behavior in
developer builds as well.

Closes #36452
2016-10-20 22:34:29 -07:00
Alex Crichton
803576c17e Enable line number debuginfo in releases
This commit enables by default passing the `-C debuginfo=1` argument to the
compiler for the stable, beta, and nightly release channels. A new configure
option was also added, `--enable-debuginfo-lines`, to enable this behavior in
developer builds as well.

Closes #36452
2016-10-19 10:08:05 -07:00
Josh Stone
81d97957a7 Detect local-rebuild by just the MAJOR.MINOR version
A new point-release shouldn't change any language semantics, so a local
stage0 that matches MAJOR.MINOR version should still be considered a
local-rebuild as far as `--cfg stageN` features go.

e.g. `1.14.0` should be considered a local-rebuild for any `1.14.X`.

(Bootstrap keys used to be an issue too, until #37265.)
2016-10-19 08:21:00 -07:00
Eduard-Mihai Burtescu
988831319e Rollup merge of #37265 - brson:bootstrap, r=alexcrichton
Allow bootstrapping without a key. Fixes #36548

This will make it easier for packagers to bootstrap rustc when they happen
to have a bootstrap compiler with a slightly different version number.

It's not ok for anything other than the build system to set this environment variable.

r? @alexcrichton
2016-10-19 08:00:04 +03:00
Brian Anderson
d3c5905772 Allow bootstrapping without a key. Fixes #36548
This will make it easier for packagers to bootstrap rustc when they happen
to have a bootstrap compiler with a slightly different version number.

It's not ok for anything other than the build system to set this environment variable.
2016-10-19 01:23:01 +00:00
Alex Crichton
06d173adb7 Add AppVeyor configuration to the repo
We hope to move to AppVeyor in the near future off of Buildbot + EC2. This adds
an `appveyor.yml` configuration file which is ready to run builds on the auto
branch. This is also accompanied with a few minor fixes to the build system and
such to accomodate AppVeyor.

The intention is that we're not switching over to AppVeyor entirely just yet,
but rather we'll watch the builds for a week or so. If everything checks out
then we'll start gating on AppVeyor instead of Buildbot!
2016-10-14 20:33:20 -07:00
Alex Crichton
2148bdfcc7 rustc: Rename rustc_macro to proc_macro
This commit blanket renames the `rustc_macro` infrastructure to `proc_macro`,
which reflects the general consensus of #35900. A follow up PR to Cargo will be
required to purge the `rustc-macro` name as well.
2016-10-06 11:07:23 -07:00
Brian Anderson
b8b50f0eda Preliminary wasm32 support 2016-09-30 14:02:45 -07:00
Jan-Erik Rediger
cb3f5799f4 Make the jsbackend an optional component 2016-09-30 14:02:41 -07:00
Brian Anderson
22cb68e625 Bump version to 1.14 2016-09-27 12:22:06 -07:00
Niels Sascha Reedijk
01fecb9f8f Haiku: add support for building on Haiku
* Hand rebased from Niels original work on 1.9.0
2016-09-25 11:15:18 -05:00
Niels Sascha Reedijk
1a6fc8b7b8 Add support for the Haiku operating system on x86 and x86_64 machines
* Hand rebased from Niels original work on 1.9.0
2016-09-25 11:12:23 -05:00
Eduard Burtescu
0863012fb9 Remove librbml and the RBML-tagged auto-encoder/decoder. 2016-09-20 20:08:01 +03:00
bors
2c2552b712 Auto merge of #36445 - infinity0:master, r=brson
mk: add a all-no-docs target to build everything except docs

This makes things slightly more efficient for Debian's auto-builders where the
docs can be built on just one architecture, and distributed to users of all
other architectures as well.
2016-09-20 01:24:54 -07:00
bors
a36e069288 Auto merge of #36213 - josephDunne:dist_version, r=brson
Add rustc version info (git hash + date) to dist tarball

a fix for #32444
2016-09-15 20:48:58 -07:00
Ximin Luo
332ba1286e mk: add a all-no-docs target to build everything except docs
This makes things slightly more efficient for Debian's auto-builders where the
docs can be built on just one architecture, and distributed to users of all
other architectures as well.
2016-09-13 10:09:36 +02:00
Jorge Aparicio
e5d0bb12ec no emutls for you, windows 2016-09-12 21:22:15 -07:00
Jorge Aparicio
e6da837e99 it's libcompiler-rt.lib on windows 2016-09-12 21:22:15 -07:00
Jorge Aparicio
3fd5fdd8d3 crate-ify compiler-rt into compiler-builtins
libcompiler-rt.a is dead, long live libcompiler-builtins.rlib

This commit moves the logic that used to build libcompiler-rt.a into a
compiler-builtins crate on top of the core crate and below the std crate.
This new crate still compiles the compiler-rt instrinsics using gcc-rs
but produces an .rlib instead of a static library.

Also, with this commit rustc no longer passes -lcompiler-rt to the
linker. This effectively makes the "no-compiler-rt" field of target
specifications a no-op. Users of `no_std` will have to explicitly add
the compiler-builtins crate to their crate dependency graph *if* they
need the compiler-rt intrinsics. Users of the `std` have to do nothing
extra as the std crate depends on compiler-builtins.

Finally, this a step towards lazy compilation of std with Cargo as the
compiler-rt intrinsics can now be built by Cargo instead of having to
be supplied by the user by some other method.

closes #34400
2016-09-12 21:22:15 -07:00
bors
00ce2c0ffa Auto merge of #36360 - orbea:docdir, r=alexcrichton
Allow setting --docdir

This will allow setting `--docdir` during configure, this is useful because not all linux distributions install documentation to `/usr/share/doc`.  For example in Slackware documentation is installed to `/usr/doc/$PRGNAM-$VERSION` and `/usr/share/doc` is a symlink to `/usr/doc`.

To use this `./configure --docdir=/usr/doc/$PRGNAM-$VERSION` can be used.
2016-09-12 01:33:40 -07:00
Ulrich Weigand
19b84088d7 Add s390x support
This adds support for building the Rust compiler and standard
library for s390x-linux, allowing a full cross-bootstrap sequence
to complete.  This includes:

- Makefile/configure changes to allow native s390x builds
- Full Rust compiler support for the s390x C ABI
  (only the non-vector ABI is supported at this point)
- Port of the standard library to s390x
- Update the liblibc submodule to a version including s390x support
- Testsuite fixes to allow clean "make check" on s390x

Caveats:

- Resets base cpu to "z10" to bring support in sync with the default
  behaviour of other compilers on the platforms.  (Usually, upstream
  supports all older processors; a distribution build may then chose
  to require a more recent base version.)  (Also, using zEC12 causes
  failures in the valgrind tests since valgrind doesn't fully support
  this CPU yet.)

- z13 vector ABI is not yet supported.  To ensure compatible code
  generation, the -vector feature is passed to LLVM.  Note that this
  means that even when compiling for z13, no vector instructions
  will be used.  In the future, support for the vector ABI should be
  added (this will require common code support for different ABIs
  that need different data_layout strings on the same platform).

- Two test cases are (temporarily) ignored on s390x to allow passing
  the test suite.  The underlying issues still need to be fixed:
  * debuginfo/simd.rs fails because of incorrect debug information.
    This seems to be a LLVM bug (also seen with C code).
  * run-pass/union/union-basic.rs simply seems to be incorrect for
    all big-endian platforms.

Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
2016-09-09 22:28:19 +01:00
orbea
5e9149d73f Allow setting --docdir 2016-09-08 23:18:20 -07:00
Joseph Dunne
72da8b82c1 Add rustc version info (git hash + date) to dist tarball
fixes #32444
2016-09-03 13:34:21 +01:00
bors
a029ea343f Auto merge of #35957 - alexcrichton:macros-1.1, r=nrc
rustc: Implement custom derive (macros 1.1)

This commit is an implementation of [RFC 1681] which adds support to the
compiler for first-class user-define custom `#[derive]` modes with a far more
stable API than plugins have today.

[RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md

The main features added by this commit are:

* A new `rustc-macro` crate-type. This crate type represents one which will
  provide custom `derive` implementations and perhaps eventually flower into the
  implementation of macros 2.0 as well.

* A new `rustc_macro` crate in the standard distribution. This crate will
  provide the runtime interface between macro crates and the compiler. The API
  here is particularly conservative right now but has quite a bit of room to
  expand into any manner of APIs required by macro authors.

* The ability to load new derive modes through the `#[macro_use]` annotations on
  other crates.

All support added here is gated behind the `rustc_macro` feature gate, both for
the library support (the `rustc_macro` crate) as well as the language features.

There are a few minor differences from the implementation outlined in the RFC,
such as the `rustc_macro` crate being available as a dylib and all symbols are
`dlsym`'d directly instead of having a shim compiled. These should only affect
the implementation, however, not the public interface.

This commit also ended up touching a lot of code related to `#[derive]`, making
a few notable changes:

* Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't
  sure how to keep this behavior and *not* expose it to custom derive.

* Derive attributes no longer have access to unstable features by default, they
  have to opt in on a granular level.

* The `derive(Copy,Clone)` optimization is now done through another "obscure
  attribute" which is just intended to ferry along in the compiler that such an
  optimization is possible. The `derive(PartialEq,Eq)` optimization was also
  updated to do something similar.

---

One part of this PR which needs to be improved before stabilizing are the errors
and exact interfaces here. The error messages are relatively poor quality and
there are surprising spects of this such as `#[derive(PartialEq, Eq, MyTrait)]`
not working by default. The custom attributes added by the compiler end up
becoming unstable again when going through a custom impl.

Hopefully though this is enough to start allowing experimentation on crates.io!
2016-09-03 00:11:18 -07:00
Jonathan Turner
b9996909ac Rollup merge of #36198 - alexcrichton:fix-travis, r=brson
test: Add a min-llvm-version directive

We've got tests which require a particular version of LLVM to run as they're
testing bug fixes. Our build system, however, supports multiple LLVM versions,
so we can't run these tests on all LLVM versions.

This adds a new `min-llvm-version` directive for tests so they can opt out of
being run on older versions of LLVM. This then namely applies that logic to the
`issue-36023.rs` test case and...

Closes #36138
2016-09-02 15:28:52 -07:00
Alex Crichton
ecc6c39e87 rustc: Implement custom derive (macros 1.1)
This commit is an implementation of [RFC 1681] which adds support to the
compiler for first-class user-define custom `#[derive]` modes with a far more
stable API than plugins have today.

[RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md

The main features added by this commit are:

* A new `rustc-macro` crate-type. This crate type represents one which will
  provide custom `derive` implementations and perhaps eventually flower into the
  implementation of macros 2.0 as well.

* A new `rustc_macro` crate in the standard distribution. This crate will
  provide the runtime interface between macro crates and the compiler. The API
  here is particularly conservative right now but has quite a bit of room to
  expand into any manner of APIs required by macro authors.

* The ability to load new derive modes through the `#[macro_use]` annotations on
  other crates.

All support added here is gated behind the `rustc_macro` feature gate, both for
the library support (the `rustc_macro` crate) as well as the language features.

There are a few minor differences from the implementation outlined in the RFC,
such as the `rustc_macro` crate being available as a dylib and all symbols are
`dlsym`'d directly instead of having a shim compiled. These should only affect
the implementation, however, not the public interface.

This commit also ended up touching a lot of code related to `#[derive]`, making
a few notable changes:

* Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't
  sure how to keep this behavior and *not* expose it to custom derive.

* Derive attributes no longer have access to unstable features by default, they
  have to opt in on a granular level.

* The `derive(Copy,Clone)` optimization is now done through another "obscure
  attribute" which is just intended to ferry along in the compiler that such an
  optimization is possible. The `derive(PartialEq,Eq)` optimization was also
  updated to do something similar.

---

One part of this PR which needs to be improved before stabilizing are the errors
and exact interfaces here. The error messages are relatively poor quality and
there are surprising spects of this such as `#[derive(PartialEq, Eq, MyTrait)]`
not working by default. The custom attributes added by the compiler end up
becoming unstable again when going through a custom impl.

Hopefully though this is enough to start allowing experimentation on crates.io!

syntax-[breaking-change]
2016-09-02 12:52:56 -07:00
bors
689c6c48ec Auto merge of #36024 - japaric:mips64, r=alexcrichton
add mips64-gnu and mips64el-gnu targets

With this commit one can build no_core (and probably no_std as well)
Rust programs for these targets. It's not yet possible to cross compile
std for these targets because rust-lang/libc doesn't know about the
mips64 architecture.

These targets have been tested by cross compiling the "smallest hello"
program (see code below) and then running it under QEMU.

``` rust

extern {
    fn puts(_: *const u8);
}

fn start(_: isize, _: *const *const u8) -> isize {
    unsafe {
        let msg = b"Hello, world!\0";
        puts(msg as *const _ as *const u8);
    }
    0
}

trait Copy {}

trait Sized {}
```

cc #36015
r? @alexcrichton
cc @brson

The cabi stuff is likely wrong. I just copied cabi_mips source and changed some `4`s to `8`s and `32`s to `64`s. It was enough to get libc's `puts` to work but I'd like someone familiar with this module to check it.
2016-09-02 03:01:48 -07:00
Alex Crichton
96283fc083 test: Add a min-llvm-version directive
We've got tests which require a particular version of LLVM to run as they're
testing bug fixes. Our build system, however, supports multiple LLVM versions,
so we can't run these tests on all LLVM versions.

This adds a new `min-llvm-version` directive for tests so they can opt out of
being run on older versions of LLVM. This then namely applies that logic to the
`issue-36023.rs` test case and...

Closes #36138
2016-09-01 16:14:17 -07:00
bors
2c01bb8851 Auto merge of #35718 - michaelwoerister:incr-comp-dir-locking, r=alexcrichton
Implement synchronization scheme for incr. comp. directory

This PR implements a copy-on-write-based synchronization scheme for the incremental compilation cache directory. For technical details, see the documentation at the beginning of `rustc_incremental/persist/fs.rs`.

The PR contains unit tests for some functions but for testing whether the scheme properly handles races, a more elaborate test setup would be needed. It would probably involve a small tool that allows to manipulate the incremental compilation directory in a controlled way and then letting a compiler instance run against directories in different states. I don't know if it's worth the trouble of adding another test category to `compiletest`, but I'd be happy to do so.

Fixes #32754
Fixes #34957
2016-08-31 12:56:15 -07:00
Michael Woerister
6ef8198406 Move flock.rs from librustdoc to librustc_data_structures. 2016-08-29 14:27:40 -04:00
Jorge Aparicio
15d8dfb6a0 build llvm with systemz backend enabled, and link to related libraries
when building rust against system llvm

closes #36077
2016-08-28 13:18:28 -05:00
bors
78a0838756 Auto merge of #36028 - japaric:s390x, r=alexcrichton
initial support for s390x

A new target, `s390x-unknown-linux-gnu`, has been added to the compiler
and can be used to build no_core/no_std Rust programs.

Known limitations:

- librustc_trans/cabi_s390x.rs is missing. This means no support for
  `extern "C" fn`.
- No support for this arch in libc. This means std can't be cross
  compiled for this target.

r? @alexcrichton

This time I couldn't test running a binary cross compiled to this target under QEMU because the qemu-s390x that ships with Ubuntu 16.04 SIGABRTs with every s390x binary I run it with.

Change in binary size of `librustc_llvm.so`:

Without this commit (stage1): 41895736 bytes
With this commit (stage1): 42899016 bytes

~2.4% increase
2016-08-28 00:36:16 -07:00
Jorge Aparicio
027eab2f87 initial support for s390x
A new target, `s390x-unknown-linux-gnu`, has been added to the compiler
and can be used to build no_core/no_std Rust programs.

Known limitations:

- librustc_trans/cabi_s390x.rs is missing. This means no support for
  `extern "C" fn`.
- No support for this arch in libc. This means std can be cross compiled
  for this target.
2016-08-26 21:05:50 -05:00
Jorge Aparicio
6a5bdb78f1 add mips64-gnu and mips64el-gnu targets
With this commit one can build no_core (and probably no_std as well)
Rust programs for these targets. It's not yet possible to cross compile
std for these targets because rust-lang/libc doesn't know about the
mips64 architecture.

These targets have been tested by cross compiling the "smallest hello"
program (see code below) and then running it under QEMU.

``` rust
#![feature(start)]
#![feature(lang_items)]
#![feature(no_core)]
#![no_core]

#[link(name = "c")]
extern {
    fn puts(_: *const u8);
}

#[start]
fn start(_: isize, _: *const *const u8) -> isize {
    unsafe {
        let msg = b"Hello, world!\0";
        puts(msg as *const _ as *const u8);
    }
    0
}

#[lang = "copy"]
trait Copy {}

#[lang = "sized"]
trait Sized {}
```
2016-08-26 17:17:03 -05:00
Steve Klabnik
57719e2d73 Also remove build steps for style 2016-08-25 15:22:57 -04:00
Eduard Burtescu
cb9b0ed91b Disable old trans access via -Z orbit, #[rustc_no_mir] or --disable-orbit. 2016-08-24 13:23:37 +03:00
Eduard-Mihai Burtescu
5e9a5b3bd7 Rollup merge of #35734 - japaric:mips-uclibc, r=alexcrichton
add mips-uclibc targets

These targets cover OpenWRT 15.05 devices, which use the soft float ABI
and the uclibc library. None of the other built-in mips targets covered
those devices (mips-gnu is hard float and glibc-based, mips-musl is
musl-based).

With this commit one can now build std for these devices using these
commands:

```
$ configure --enable-rustbuild --target=mips-unknown-linux-uclibc
$ make
```

cc #35673

---

r? @alexcrichton
cc @felixalias This is the target the rust-tessel project should be using.
Note that the libc crate doesn't support the uclibc library and will have to be updated. We are lucky that uclibc and glibc are somewhat similar and one can build std and even run the libc-test test suite with the current, unmodified libc. About that last part, I tried to run the libc-test and got a bunch of compile errors. I don't intend to fix them but I'll post some instruction about how to run libc-test in the rust-lang/libc issue tracker.
2016-08-18 06:12:21 +03:00
Jonathan Turner
e20a7e3418 Rollup merge of #35725 - brson:bump, r=alexcrichton
Bump version to 1.13
2016-08-17 06:25:27 -07:00
bors
1bf5fa3269 Auto merge of #35538 - cgswords:libproc_macro, r=nrc
Kicking off libproc_macro

This PR introduces `libproc_macro`, which is currently quite bare-bones (just a few macro construction tools and an initial `quote!` macro).

This PR also introduces a few test cases for it, and an additional `shim` file (at `src/libsyntax/ext/proc_macro_shim.rs` to allow a facsimile usage of Macros 2.0 *today*!
2016-08-16 16:35:10 -07:00
Jorge Aparicio
1cf9cafeb1 add mips-uclibc targets
These targets cover OpenWRT 15.05 devices, which use the soft float ABI
and the uclibc library. None of the other built-in mips targets covered
those devices (mips-gnu is hard float and glibc-based, mips-musl is
musl-based).

With this commit one can now build std for these devices using these
commands:

```
$ configure --enable-rustbuild --target=mips-unknown-linux-uclibc
$ make
```

cc #35673
2016-08-16 17:12:51 -05:00
cgswords
98c8e0a05d Proc_macro is alive 2016-08-16 13:17:36 -07:00
Brian Anderson
16fc02569d Bump version to 1.13 2016-08-16 11:29:50 -07:00
bors
47e6da2a01 Auto merge of #35427 - cardoe:arm-musl-targets, r=alexcrichton
add GNU make files for arm-unknown-linux-musleabi

For Yocto (Embedded Linux meta distro) Rust is provided via the [meta-rust layer](https://github.com/meta-rust/meta-rust). In this project there have been patches to add `arm-unknown-linux-musleabi`. Rust recently acquired that support via #35060 but only for rustbuild. meta-rust is currently only able to build Rust support with the existing GNU Makefiles. This adds `arm-unknown-linux-musleabi` support to Rust for the GNU Makefiles until meta-rust is able to sort out why using rustbuild does not work for it.

/cc @srwalter @derekstraka @jmesmon @japaric
2016-08-14 18:36:33 -07:00