Commit Graph

1780 Commits

Author SHA1 Message Date
Sébastien Marie
049d76bdd2 Pass libstdc++.so path to linker under OpenBSD
By default, the linker in use under OpenBSD is the linker of base, which
don't include /usr/local/lib where libstdc++ of gcc-4.9 lives. We need
to add this directory to linker-path-search (using -L).

Search the path of libstdc++.a, which is a known name (libstdc++.so has
SO_VERSION) in the same directory.
2015-09-20 19:06:37 +02:00
bors
50048c00b9 Auto merge of #28512 - lfairy:snapshot-pyc, r=alexcrichton
Closes #28508

r? @brson
2015-09-20 00:12:12 +00:00
Chris Wong
7f43941110 Don't include *.pyc files in source tarball
Closes #28508
2015-09-19 20:04:10 +12:00
Sébastien Marie
913fe6dbe9 add support for non-standard name of stdc++ library
it makes rustc compatible with gcc installation that are using
`--program-transform-name' configure flag (on OpenBSD for example).

- detects at configure the name of stdc++ library on the system

- use the detected name in llvm makefile (with enable-static-stdcpp),
  and pass it to mklldeps.py

- generate mklldeps.rs using this detected name

note that CFG_STDCPP_NAME is about stdc++ name, not about libc++. If
using libc++, the default name will be `stdc++', but it won't be used
when linking.
2015-09-18 18:03:59 +02:00
bors
8ea2198215 Auto merge of #28421 - alexcrichton:msvc-rmake, r=alexcrichton
Work carried over from #27938
2015-09-17 16:22:46 +00:00
Alex Crichton
0675dffac4 rmake: Get all tests passing on MSVC 2015-09-17 08:40:33 -07:00
Brian Anderson
cedde0fc8a Bump to 1.5 2015-09-15 14:05:10 -07:00
Niko Matsakis
c8a661838e enable slice patterns and enable building rustdoc 2015-09-06 16:48:57 -04:00
Niko Matsakis
9b45874445 plumbing to automatically run MIR for crates where it works;
this serves as a poor man's unit test infrastructure until
MIR is more built up
2015-09-06 07:27:23 -04:00
Niko Matsakis
faa9ec81b5 add MIR crate and link it into the driver 2015-09-06 07:27:23 -04:00
Diggory Blake
d4fc3ec208 Add line numbers to windows-gnu backtraces
Fix formatting
Remove unused imports
Refactor
Fix msvc build
Fix line lengths
Formatting
Enable backtrace tests
Fix using directive on mac
pwd info
Work-around buildbot PWD bug, and fix libbacktrace configuration
Use alternative to `env -u` which is not supported on bitrig
Disable tests on 32-bit windows gnu
2015-09-04 01:25:15 +01:00
bors
69c3b39d0d Auto merge of #28174 - steveklabnik:gh14705, r=alexcricton
Because 'doc' is a directory, when running `make doc`, you'll see
this:

    make: Nothing to be done for `doc'.

By adding a target for `doc` to build `docs`, both work.

Fixes #14705
2015-09-03 02:12:21 +00:00
Steve Klabnik
7c8c72d3b0 Introduce 'make doc' -> 'make docs'
Because 'doc' is a directory, when running `make doc`, you'll see
this:

    make: Nothing to be done for `doc'.

By adding a target for `doc` to build `docs`, both work.

Fixes #14705
2015-09-02 22:00:58 -04:00
Nick Cameron
facdf2ebb1 Add an intital HIR and lowering step 2015-09-03 10:02:36 +12:00
Cody P Schafer
2d0cb31d30 mk: tell rustc that we're only looking for native libs in the LLVM_LIBDIR
This fixes the case where we try to re-build & re-install rust to the
same prefix (without uninstalling) while using an llvm-root that is the
same as the prefix.

Without this, builds like that fail with:
	'error: multiple dylib candidates for `std` found'

See https://github.com/jmesmon/meta-rust/issues/6 for some details.

May also be related to #20342.
2015-08-26 13:43:15 -04:00
Tim JIANG
a1b2deb33b New cross target: i686-linux-android
- All the libstd tests are now passing in the optimized build against
  a Zenfone2 and the x86 Android simulator.
2015-08-23 15:38:11 +08:00
Marc-Antoine Perennou
c977596992 rustc_back: add configure options for default linker and ar
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
2015-08-19 18:06:34 +02:00
Huon Wilson
58891278a3 Type check platform-intrinsics in typeck. 2015-08-17 14:41:38 -07:00
Huon Wilson
9af385bddb Add rustc_platform_intrinsics & some arm/x86 intrs.
These are enough to implement a cross-platform SIMD single-precision
mandelbrot renderer.
2015-08-17 14:41:38 -07:00
Alex Crichton
45bf1ed1a1 rustc: Allow changing the default allocator
This commit is an implementation of [RFC 1183][rfc] which allows swapping out
the default allocator on nightly Rust. No new stable surface area should be
added as a part of this commit.

[rfc]: https://github.com/rust-lang/rfcs/pull/1183

Two new attributes have been added to the compiler:

* `#![needs_allocator]` - this is used by liballoc (and likely only liballoc) to
  indicate that it requires an allocator crate to be in scope.
* `#![allocator]` - this is a indicator that the crate is an allocator which can
  satisfy the `needs_allocator` attribute above.

The ABI of the allocator crate is defined to be a set of symbols that implement
the standard Rust allocation/deallocation functions. The symbols are not
currently checked for exhaustiveness or typechecked. There are also a number of
restrictions on these crates:

* An allocator crate cannot transitively depend on a crate that is flagged as
  needing an allocator (e.g. allocator crates can't depend on liballoc).
* There can only be one explicitly linked allocator in a final image.
* If no allocator is explicitly requested one will be injected on behalf of the
  compiler. Binaries and Rust dylibs will use jemalloc by default where
  available and staticlibs/other dylibs will use the system allocator by
  default.

Two allocators are provided by the distribution by default, `alloc_system` and
`alloc_jemalloc` which operate as advertised.

Closes #27389
2015-08-14 15:13:10 -07:00
bors
7b7fc67dd4 Auto merge of #27625 - wthrowe:find, r=alexcrichton
New enough find on Linux doesn't support "-perm +..." and suggests
using "-perm /..." instead, but that doesn't work on Windows.
Hopefully all platforms are happy with this expanded version.

I don't have access to a Windows development system to test this, so someone needs to verify that this actually works there before merging.

Closes #19981.
2015-08-13 16:09:22 +00:00
bors
b2aef9d58b Auto merge of #27789 - chriskrycho:remove_pandoc_references, r=steveklabnik
Per @steveklabnik's comment [here](https://github.com/rust-lang/cargo/issues/739#issuecomment-130085860), the Pandoc components of the Makefile are no longer used, and as such the corresponding components of the documentation are out of date.

  - I've removed the Pandoc (and therefore also LaTeX) elements of the makefile and confirmed that the build proceeds correctly.
  - I updated the documentation to reference `rustdoc` and  of Pandoc.

r? @steveklabnik
2015-08-13 03:52:10 +00:00
William Throwe
904e428dba Whitelist .pp files in tidy-binaries
Pretty-printed files sometimes start with #![some_feature], which
looks like a shebang line and confuses Windows builds into thinking
they are executables.
2015-08-12 19:08:22 -04:00
Alex Crichton
837ae4f3d4 rollup merge of #27678: alexcrichton/snapshots
* Lots of core prelude imports removed
* Makefile support for MSVC env vars and Rust crates removed
* Makefile support for morestack removed
2015-08-11 22:42:22 -07:00
Alex Crichton
bbef8893f7 rollup merge of #27676: alexcrichton/msvc-unwind
This commit leverages the runtime support for DWARF exception info added
in #27210 to enable unwinding by default on 64-bit MSVC. This also additionally
adds a few minor fixes here and there in the test harness and such to get
`make check` entirely passing on 64-bit MSVC:

* The invocation of `maketest.py` now works with spaces/quotes in CC
* debuginfo tests are disabled on MSVC
* A link error for librustc was hacked around (see #27438)
2015-08-11 22:42:21 -07:00
Alex Crichton
737397c584 rollup merge of #27622: eefriedman/https-url
Also fixes a few outdated links.
2015-08-11 22:11:25 -07:00
Chris Krycho
09ed80fc9c mk/docs: remove Pandoc and LaTeX elements. 2015-08-11 20:12:11 -04:00
Alex Crichton
b6b4f5a0e7 trans: Re-enable unwinding on 64-bit MSVC
This commit leverages the runtime support for DWARF exception info added
in #27210 to enable unwinding by default on 64-bit MSVC. This also additionally
adds a few minor fixes here and there in the test harness and such to get
`make check` entirely passing on 64-bit MSVC:

* The invocation of `maketest.py` now works with spaces/quotes in CC
* debuginfo tests are disabled on MSVC
* A link error for librustc was hacked around (see #27438)
2015-08-11 16:45:02 -07:00
Alex Crichton
938099a7eb Register new snapshots
* Lots of core prelude imports removed
* Makefile support for MSVC env vars and Rust crates removed
* Makefile support for morestack removed
2015-08-11 15:11:13 -07:00
bors
1af31d4974 Auto merge of #27553 - Diggsey:win-path-fix, r=alexcrichton
I have no idea how bors keeps working without this - I can only assume it's some peculiarity of how windows searches for DLLs.

Without this change, running `make check` on windows will not correctly set PATH to include eg. `x86_64-pc-windows-gnu\stage1\bin\rustlib\x86_64-pc-windows-gnu\lib`, and when it tries to run eg. `stage1/test/stdtest-x86_64-pc-windows-gnu.exe`, it will fail because windows can't find the DLLs on which it relies.

It seems to be just a mistake: when the equivalent was added for the branch that deals with unix-like platforms, the windows branch was left unchanged.
2015-08-11 12:59:14 +00:00
bors
23f43896ce Auto merge of #27518 - alexcrichton:msvc-builtin-llvm-ar, r=huonw
This means that we no longer need to ship the `llvm-ar.exe` binary in the MSVC
distribution, and after a snapshot we can remove a good bit of logic from the
makefiles!
2015-08-11 07:48:39 +00:00
Alex Crichton
e648c96c5f trans: Stop informing LLVM about dllexport
Rust's current compilation model makes it impossible on Windows to generate one
object file with a complete and final set of dllexport annotations. This is
because when an object is generated the compiler doesn't actually know if it
will later be included in a dynamic library or not. The compiler works around
this today by flagging *everything* as dllexport, but this has the drawback of
exposing too much.

Thankfully there are alternate methods of specifying the exported surface area
of a dll on Windows, one of which is passing a `*.def` file to the linker which
lists all public symbols of the dynamic library. This commit removes all
locations that add `dllexport` to LLVM variables and instead dynamically
generates a `*.def` file which is passed to the linker. This file will include
all the public symbols of the current object file as well as all upstream
libraries, and the crucial aspect is that it's only used when generating a
dynamic library. When generating an executable this file isn't generated, so all
the symbols aren't exported from an executable.

To ensure that statically included native libraries are reexported correctly,
the previously added support for the `#[linked_from]` attribute is used to
determine the set of FFI symbols that are exported from a dynamic library, and
this is required to get the compiler to link correctly.
2015-08-10 18:20:42 -07:00
Alex Crichton
138252cc6a trans: Specify archive_format for MSVC
This means that we no longer need to ship the `llvm-ar.exe` binary in the MSVC
distribution, and after a snapshot we can remove a good bit of logic from the
makefiles!
2015-08-10 17:45:16 -07:00
Alex Crichton
7a3fdfbf67 Remove morestack support
This commit removes all morestack support from the compiler which entails:

* Segmented stacks are no longer emitted in codegen.
* We no longer build or distribute libmorestack.a
* The `stack_exhausted` lang item is no longer required

The only current use of the segmented stack support in LLVM is to detect stack
overflow. This is no longer really required, however, because we already have
guard pages for all threads and registered signal handlers watching for a
segfault on those pages (to print out a stack overflow message). Additionally,
major platforms (aka Windows) already don't use morestack.

This means that Rust is by default less likely to catch stack overflows because
if a function takes up more than one page of stack space it won't hit the guard
page. This is what the purpose of morestack was (to catch this case), but it's
better served with stack probes which have more cross platform support and no
runtime support necessary. Until LLVM supports this for all platform it looks
like morestack isn't really buying us much.

cc #16012 (still need stack probes)
Closes #26458 (a drive-by fix to help diagnostics on stack overflow)
2015-08-10 16:35:44 -07:00
William Throwe
f001f9a73e Make tidy-binaries find invocation work on Linux
New enough find on Linux doesn't support "-perm +..." and suggests
using "-perm /..." instead, but that doesn't work on Windows.
Hopefully all platforms are happy with this expanded version.
2015-08-10 00:12:45 -04:00
Eli Friedman
bbbfed2f93 Use https URLs to refer to rust-lang.org where appropriate.
Also fixes a few outdated links.
2015-08-09 14:28:46 -07:00
Diggory Blake
6203d97a86 Fix setting of PATH for make check on windows 2015-08-06 04:47:15 +01:00
Brian Anderson
ac085a6a9e Bump to 1.4 2015-08-04 12:47:00 -07:00
Alexis Beingessner
ca902dd8cb rename TARPL to The Rustinomicon 2015-08-03 11:22:08 -07:00
bors
dbf3a63dd7 Auto merge of #27386 - chris-morgan:ctags-stuff-update, r=alexcrichton
As there’s no C++ runtime any more there’s really no point in having anything but Rust tags being made.

I’ve also taken the liberty of excluding the compiler parts of this in the `librust%,,` pattern substitution. Whether or not this is “correct” will depend on whether you want tags for the compiler or for general use. For myself, I want it for general use.

I’m not sure how much people use the tags files anyway. I definitely do, but with Racer existing the tags files aren’t quite so necessary.
2015-07-30 13:39:08 +00:00
bors
4d52d7c857 Auto merge of #27032 - Gankro:tarpl, r=aturon,acrichto,arielb,pnkfelix,nrc,nmatsakis,huonw
I've been baking this out of tree for long enough. This is currently about ~2/5ths the size of TRPL. Time to get it in tree so it can be more widely maintained and scrutinized. I've preserved the whole gruesome history including various rewrites. I can definitely squash these a fair amount if desired. Some random people submitted minor fixes though, so they're mixed in.

Edit: forgot to link to rendered http://cglab.ca/~abeinges/blah/turpl/_book/

Edit2:

To streamline the review process, I'm going to break this into sections that need official "domain expert" approval:

# Summary

* [ ] references.md -- very important, needs work

* [x] Meet Safe and Unsafe: reviewed by @aturon
* [x] Data Layout: reviewed by @arielb1 
* [x] Ownership: reviewed by @aturon ( and sorta @nikomatsakis ) -- significantly updated, may need re-r
* [x] Coversions:  reviewed by @nrc 
* [x] Uninitialized Memory: reviewed by @pnkfelix 
* [x] Ownership-Oriented Resource Management: reviewed by @aturon
* [x] Unwinding: reviewed by @alexcrichton 
* [x] Concurrency: reviewed by @aturon
* [x] Implementing Vec:  r? @huonw
2015-07-30 00:56:01 +00:00
Chris Morgan
aede1c73bd Update the ctags rules and targets.
As there’s no C++ runtime any more there’s really no point in having
anything but Rust tags being made.

I’ve also taken the liberty of excluding the compiler parts of this in
the `librust%,,` pattern substitution. Whether or not this is “correct”
will depend on whether you want tags for the compiler or for general
use. For myself, I want it for general use.

I’m not sure how much people use the tags files anyway. I definitely do,
but with Racer existing the tags files aren’t quite so necessary.
2015-07-30 06:35:42 +10:00
bors
aa6efd959e Auto merge of #27173 - mark-buer:split-android-ndks, r=alexcrichton
Allows a multi-Android-target Rust compiler to be built.
Without these (or similar) changes, only a single-Android-target Rust compiler is possible.
Please see https://internals.rust-lang.org/t/dual-target-android-rust-compiler/2382/3 for additional context.
2015-07-28 17:58:18 +00:00
Mark Buer
33a7e67904 Splits Android NDK path configuration. 2015-07-28 19:21:04 +12:00
Alex Crichton
c35b2bd226 trans: Move rust_try into the compiler
This commit moves the IR files in the distribution, rust_try.ll,
rust_try_msvc_64.ll, and rust_try_msvc_32.ll into the compiler from the main
distribution. There's a few reasons for this change:

* LLVM changes its IR syntax from time to time, so it's very difficult to
  have these files build across many LLVM versions simultaneously. We'll likely
  want to retain this ability for quite some time into the future.
* The implementation of these files is closely tied to the compiler and runtime
  itself, so it makes sense to fold it into a location which can do more
  platform-specific checks for various implementation details (such as MSVC 32
  vs 64-bit).
* This removes LLVM as a build-time dependency of the standard library. This may
  end up becoming very useful if we move towards building the standard library
  with Cargo.

In the immediate future, however, this commit should restore compatibility with
LLVM 3.5 and 3.6.
2015-07-21 16:08:11 -07:00
Alexis Beingessner
04578f6611 update build to make tarpl 2015-07-13 23:31:52 -07:00
Dave Huseby
1a928f434a adding support for i686-unknown-freebsd target 2015-07-11 00:23:04 -07:00
Alex Crichton
4a824275b9 trans: Use LLVM's writeArchive to modify archives
We have previously always relied upon an external tool, `ar`, to modify archives
that the compiler produces (staticlibs, rlibs, etc). This approach, however, has
a number of downsides:

* Spawning a process is relatively expensive for small compilations
* Encoding arguments across process boundaries often incurs unnecessary overhead
  or lossiness. For example `ar` has a tough time dealing with files that have
  the same name in archives, and the compiler copies many files around to ensure
  they can be passed to `ar` in a reasonable fashion.
* Most `ar` programs found do **not** have the ability to target arbitrary
  platforms, so this is an extra tool which needs to be found/specified when
  cross compiling.

The LLVM project has had a tool called `llvm-ar` for quite some time now, but it
wasn't available in the standard LLVM libraries (it was just a standalone
program). Recently, however, in LLVM 3.7, this functionality has been moved to a
library and is now accessible by consumers of LLVM via the `writeArchive`
function.

This commit migrates our archive bindings to no longer invoke `ar` by default
but instead make a library call to LLVM to do various operations. This solves
all of the downsides listed above:

* Archive management is now much faster, for example creating a "hello world"
  staticlib is now 6x faster (50ms => 8ms). Linking dynamic libraries also
  recently started requiring modification of rlibs, and linking a hello world
  dynamic library is now 2x faster.
* The compiler is now one step closer to "hassle free" cross compilation because
  no external tool is needed for managing archives, LLVM does the right thing!

This commit does not remove support for calling a system `ar` utility currently.
We will continue to maintain compatibility with LLVM 3.5 and 3.6 looking forward
(so the system LLVM can be used wherever possible), and in these cases we must
shell out to a system utility. All nightly builds of Rust, however, will stop
needing a system `ar`.
2015-07-10 09:06:21 -07:00
bors
2ceaa77ae2 Auto merge of #26741 - alexcrichton:noinline-destructors, r=brson
This PR was originally going to be a "let's start running tests on MSVC" PR, but it didn't quite get to that point. It instead gets us ~80% of the way there! The steps taken in this PR are:

* Landing pads are turned on by default for 64-bit MSVC. The LLVM support is "good enough" with the caveat the destructor glue is now marked noinline. This was recommended [on the associated bug](https://llvm.org/bugs/show_bug.cgi?id=23884) as a stopgap until LLVM has a better representation for exception handling in MSVC. The consequence of this is that MSVC will have a bit of a perf hit, but there are possible routes we can take if this workaround sticks around for too long.
* The linker (`link.exe`) is now looked up in the Windows Registry if it's not otherwise available in the environment. This improves using the compiler outside of a VS shell (e.g. in a MSYS shell or in a vanilla cmd.exe shell). This also makes cross compiles via Cargo "just work" when crossing between 32 and 64 bit!
* TLS destructors were fixed to start running on MSVC (they previously weren't running at all)
* A few assorted `run-pass` tests were fixed.
* The dependency on the `rust_builtin` library was removed entirely for MSVC to try to prevent any `cl.exe` compiled objects get into the standard library. This should help us later remove any dependence on the CRT by the standard library.
* I re-added `rust_try_msvc_32.ll` for 32-bit MSVC and ensured that landing pads were turned off by default there as well.

Despite landing pads being enabled, there are still *many* failing tests on MSVC. The two major classes I've identified so far are:

* Spurious aborts. It appears that when optimizations are enabled that landing pads aren't always lined up properly, and sometimes an exception being thrown can't find the catch block down the stack, causing the program to abort. I've been working to reduce this test case but haven't been met with great success just yet.
* Parallel codegen does not work on MSVC. Our current strategy is to take the N object files emitted by the N codegen threads and use `ld -r` to assemble them into *one* object file. The MSVC linker, however, does not have this ability, and this will need to be rearchitected to work on MSVC.

I will fix parallel codegen in a future PR, and I'll also be watching LLVM closely to see if the aborts... disappear!
2015-07-06 19:49:16 +00:00
Tamir Duberstein
1491a8fa01 Remove unused variable 2015-07-06 08:40:40 -04:00