Commit Graph

43592 Commits

Author SHA1 Message Date
petrochenkov
7b1916d253 Fix panic in lint for out of range literals 2015-05-20 13:03:18 +03:00
bors
749cb1931f Auto merge of #25596 - Ms2ger:rbml-docs, r=alexcrichton
This leads to more idiomatic code in the callers.
2015-05-20 09:13:28 +00:00
Luqman Aden
54dbd0baad librustc_trans: Remove misoptimization in treating derefs of Box as rvalues. 2015-05-20 05:07:27 -04:00
Iven Hsu
2ca3dfd4ac
trpl: Remove tailing semicolon of an inner attribute
The syntax with tailing semicolon is deprecated and the compiler will
complain about it.
2015-05-20 16:55:38 +08:00
bors
6d718f236d Auto merge of #25595 - dotdash:issue25549, r=eddyb
When taking the address of an unsized field we generate a rvalue datum
for the field and then convert it to an lvalue datum. At that point,
cleanup is scheduled for the field, leading to multiple drop calls.

The problem is that we generate an rvalue datum for the field, since the
pointer does not own the data and there's already cleanup scheduled
elsewhere by the true owner. Instead, an lvalue datum must be created.

Thanks to @eddyb for identifying the underlying cause and suggesting the
correct fix.

Fixes #25549.
2015-05-20 07:38:45 +00:00
bors
720735b943 Auto merge of #25588 - bluss:doc-string-from, r=alexcrichton
Use stable code in doc examples (libcollections)

Main task is to change from String::from_str to String::from in examples for String
(the latter constructor is stable). While I'm at it, also remove redundant feature flags,
fix some other instances of unstable code in examples (in examples for stable
methods), and remove some use of usize in examples too.
2015-05-20 06:03:58 +00:00
Nick Hamann
cc9d1de692 Add error explanation for E0202. 2015-05-20 00:38:10 -05:00
Steven Fackler
e161d5cf73 Stabilize debug builders for 1.2.0 2015-05-19 21:57:39 -07:00
Alex Crichton
e7aad28614 std: Handle DT_DIR file types in dirent pointers
This "fast path" in `DirEntry::file_type` on Unix wasn't turning out to be so
much of a fast path as the `DT_DIR` case wasn't handled, so directories fell
back to using `lstat` instead. This commit adds the missing case to return
quickly if a path is a directory and `DirEntry::file_type` is used.
2015-05-19 21:34:09 -07:00
bors
f6b446f4a9 Auto merge of #25624 - steveklabnik:rollup, r=steveklabnik
- Successful merges: #25583, #25585, #25602, #25604, #25607, #25611, #25614, #25620
- Failed merges:
2015-05-20 04:28:47 +00:00
Steve Klabnik
395d01cf64 Fix for https://github.com/rust-lang/rust/pull/25583 2015-05-19 23:22:28 -04:00
Steve Klabnik
55da4c6975 Small fix for https://github.com/rust-lang/rust/pull/25611 2015-05-19 21:27:01 -04:00
Austin Hellyer
31026c846e Fix a few typos in the releases 2015-05-19 17:34:14 -07:00
bors
43cf733bfa Auto merge of #25350 - alexcrichton:msvc, r=brson
Special thanks to @retep998 for the [excellent writeup](https://github.com/rust-lang/rfcs/issues/1061) of tasks to be done and @ricky26 for initially blazing the trail here!

# MSVC Support

This goal of this series of commits is to add MSVC support to the Rust compiler
and build system, allowing it more easily interoperate with Visual Studio
installations and native libraries compiled outside of MinGW.

The tl;dr; of this change is that there is a new target of the compiler,
`x86_64-pc-windows-msvc`, which will not interact with the MinGW toolchain at
all and will instead use `link.exe` to assemble output artifacts.

## Why try to use MSVC?

With today's Rust distribution, when you install a compiler on Windows you also
install `gcc.exe` and a number of supporting libraries by default (this can be
opted out of). This allows installations to remain independent of MinGW
installations, but it still generally requires native code to be linked with
MinGW instead of MSVC. Some more background can also be found in #1768 about the
incompatibilities between MinGW and MSVC.

Overall the current installation strategy is quite nice so long as you don't
interact with native code, but once you do the usage of a MinGW-based `gcc.exe`
starts to get quite painful.

Relying on a nonstandard Windows toolchain has also been a long-standing "code
smell" of Rust and has been slated for remedy for quite some time now. Using a
standard toolchain is a great motivational factor for improving the
interoperability of Rust code with the native system.

## What does it mean to use MSVC?

"Using MSVC" can be a bit of a nebulous concept, but this PR defines it as:

* The build system for Rust will build as much code as possible with the MSVC
  compiler, `cl.exe`.
* The build system will use native MSVC tools for managing archives.
* The compiler will link all output with `link.exe` instead of `gcc.exe`.

None of these are currently implemented today, but all are required for the
compiler to fluently interoperate with MSVC.

## How does this all work?

At the highest level, this PR adds a new target triple to the Rust compiler:

    x86_64-pc-windows-msvc

All logic for using MSVC or not is scoped within this triple and code can
conditionally build for MSVC or MinGW via:

    #[cfg(target_env = "msvc")]

It is expected that auto builders will be set up for MSVC-based compiles in
addition to the existing MinGW-based compiles, and we will likely soon start
shipping MSVC nightlies where `x86_64-pc-windows-msvc` is the host target triple
of the compiler.

# Summary of changes

Here I'll explain at a high level what many of the changes made were targeted
at, but many more details can be found in the commits themselves. Many thanks to
@retep998 for the excellent writeup in rust-lang/rfcs#1061 and @rick26 for a lot
of the initial proof-of-concept work!

## Build system changes

As is probably expected, a large chunk of this PR is changes to Rust's build
system to build with MSVC. At a high level **it is an explicit non goal** to
enable building outside of a MinGW shell, instead all Makefile infrastructure we
have today is retrofitted with support to use MSVC instead of the standard MSVC
toolchain. Some of the high-level changes are:

* The configure script now detects when MSVC is being targeted and adds a number
  of additional requirements about the build environment:
  * The `--msvc-root` option must be specified or `cl.exe` must be in PATH to
    discover where MSVC is installed. The compiler in use is also required to
    target x86_64.
  * Once the MSVC root is known, the INCLUDE/LIB environment variables are
    scraped so they can be reexported by the build system.
  * CMake is required to build LLVM with MSVC (and LLVM is also configured with
    CMake instead of the normal configure script).
  * jemalloc is currently unconditionally disabled for MSVC targets as jemalloc
    isn't a hard requirement and I don't know how to build it with MSVC.
* Invocations of a C and/or C++ compiler are now abstracted behind macros to
  appropriately call the underlying compiler with the correct format of
  arguments, for example there is now a macro for "assemble an archive from
  objects" instead of hard-coded invocations of `$(AR) crus liboutput.a ...`
* The output filenames for standard libraries such as morestack/compiler-rt are
  now "more correct" on windows as they are shipped as `foo.lib` instead of
  `libfoo.a`.
* Rust targets can now depend on native tools provided by LLVM, and as you'll
  see in the commits the entire MSVC target depends on `llvm-ar.exe`.
* Support for custom arbitrary makefile dependencies of Rust targets has been
  added. The MSVC target for `rustc_llvm` currently requires a custom `.DEF`
  file to be passed to the linker to get further linkages to complete.

## Compiler changes

The modifications made to the compiler have so far largely been minor tweaks
here and there, mostly just adding a layer of abstraction over whether MSVC or a
GNU-like linker is being used. At a high-level these changes are:

* The section name for metadata storage in dynamic libraries is called `.rustc`
  for MSVC-based platorms as section names cannot contain more than 8
  characters.
* The implementation of `rustc_back::Archive` was refactored, but the
  functionality has remained the same.
* Targets can now specify the default `ar` utility to use, and for MSVC this
  defaults to `llvm-ar.exe`
* The building of the linker command in `rustc_trans:🔙:link` has been
  abstracted behind a trait for the same code path to be used between GNU and
  MSVC linkers.

## Standard library changes

Only a few small changes were required to the stadnard library itself, and only
for minor differences between the C runtime of msvcrt.dll and MinGW's libc.a

* Some function names for floating point functions have leading underscores, and
  some are not present at all.
* Linkage to the `advapi32` library for crypto-related functions is now
  explicit.
* Some small bits of C code here and there were fixed for compatibility with
  MSVC's cl.exe compiler.

# Future Work

This commit is not yet a 100% complete port to using MSVC as there are still
some key components missing as well as some unimplemented optimizations. This PR
is already getting large enough that I wanted to draw the line here, but here's
a list of what is not implemented in this PR, on purpose:

## Unwinding

The revision of our LLVM submodule [does not seem to implement][llvm] does not
support lowering SEH exception handling on the Windows MSVC targets, so
unwinding support is not currently implemented for the standard library (it's
lowered to an abort).

[llvm]: https://github.com/rust-lang/llvm/blob/rust-llvm-2015-02-19/lib/CodeGen/Passes.cpp#L454-L461

It looks like, however, that upstream LLVM has quite a bit more support for SEH
unwinding and landing pads than the current revision we have, so adding support
will likely just involve updating LLVM and then adding some shims of our own
here and there.

## dllimport and dllexport

An interesting part of Windows which MSVC forces our hand on (and apparently
MinGW didn't) is the usage of `dllimport` and `dllexport` attributes in LLVM IR
as well as native dependencies (in C these correspond to
`__declspec(dllimport)`).

Whenever a dynamic library is built by MSVC it must have its public interface
specified by functions tagged with `dllexport` or otherwise they're not
available to be linked against. This poses a few problems for the compiler, some
of which are somewhat fundamental, but this commit alters the compiler to attach
the `dllexport` attribute to all LLVM functions that are reachable (e.g. they're
already tagged with external linkage). This is suboptimal for a few reasons:

* If an object file will never be included in a dynamic library, there's no need
  to attach the dllexport attribute. Most object files in Rust are not destined
  to become part of a dll as binaries are statically linked by default.
* If the compiler is emitting both an rlib and a dylib, the same source object
  file is currently used but with MSVC this may be less feasible. The compiler
  may be able to get around this, but it may involve some invasive changes to
  deal with this.

The flipside of this situation is that whenever you link to a dll and you import
a function from it, the import should be tagged with `dllimport`. At this time,
however, the compiler does not emit `dllimport` for any declarations other than
constants (where it is required), which is again suboptimal for even more
reasons!

* Calling a function imported from another dll without using `dllimport` causes
  the linker/compiler to have extra overhead (one `jmp` instruction on x86) when
  calling the function.
* The same object file may be used in different circumstances, so a function may
  be imported from a dll if the object is linked into a dll, but it may be
  just linked against if linked into an rlib.
* The compiler has no knowledge about whether native functions should be tagged
  dllimport or not.

For now the compiler takes the perf hit (I do not have any numbers to this
effect) by marking very little as `dllimport` and praying the linker will take
care of everything. Fixing this problem will likely require adding a few
attributes to Rust itself (feature gated at the start) and then strongly
recommending static linkage on Windows! This may also involve shipping a
statically linked compiler on Windows instead of a dynamically linked compiler,
but these sorts of changes are pretty invasive and aren't part of this PR.

## CI integration

Thankfully we don't need to set up a new snapshot bot for the changes made here as our snapshots are freestanding already, we should be able to use the same snapshot to bootstrap both MinGW and MSVC compilers (once a new snapshot is made from these changes).

I plan on setting up a new suite of auto bots which are testing MSVC configurations for now as well, for now they'll just be bootstrapping and not running tests, but once unwinding is implemented they'll start running all tests as well and we'll eventually start gating on them as well.

---

I'd love as many eyes on this as we've got as this was one of my first interactions with MSVC and Visual Studio, so there may be glaring holes that I'm missing here and there!

cc @retep998, @ricky26, @vadimcn, @klutzy 

r? @brson
2015-05-20 00:31:55 +00:00
Steve Klabnik
ed3c64451c Rollup merge of #25620 - brson:betavers, r=alexcrichton 2015-05-19 18:38:54 -04:00
Steve Klabnik
51a0c6a6fa Rollup merge of #25614 - parir:patch-2, r=alexcrichton
r? @steveklabnik
2015-05-19 18:38:54 -04:00
Steve Klabnik
dd1c68e6a1 Rollup merge of #25611 - parir:patch-1, r=steveklabnik
r? @steveklabnik
2015-05-19 18:38:54 -04:00
Steve Klabnik
7f74212906 Rollup merge of #25607 - peferron:doc-macros-assert-fix, r=steveklabnik
"Truth passes, success `panic!`s" seems to be a typo. The closest fix would be something like "Success passes, failure `panic!`s" but to me a "comparison failure" suggests that we couldn't compare the two values at all, not that we could successfully compare them and that the result was non-equality. So I opted to rewrite the paragraph a bit. If there's a better alternative please let me know.

r? @steveklabnik
2015-05-19 18:38:54 -04:00
Steve Klabnik
1d961fde2d Rollup merge of #25604 - skeuomorf:docs-lifetime, r=steveklabnik
r? @steveklabnik
2015-05-19 18:38:53 -04:00
Steve Klabnik
6fc93b85bc Rollup merge of #25602 - parkr:patch-1, r=alexcrichton
Padding and alignment are often not implemented by types and can cause confusion in the user.  Per discussion with @alexcrichton, here is my PR.

/cc https://github.com/rust-lang/time/issues/98
2015-05-19 18:38:53 -04:00
Steve Klabnik
1bcfe5e5ad Rollup merge of #25585 - sferik:change-default-gender, r=steveklabnik
The paper from which this example was taken made the mistake of assuming that all five philosophers are men. This it is a hypothetical example—there are no actual philosophers eating 🍝—so there is no good reason to make this assumption. Since women make up about half of the human population, all things being equal, women should represent about half of the philosophers. However, because this mistake has stood since 1985, I have changed *all* of the pronouns to be female, to make up for lost time. If someone would like to revert this patch or switch to neutral pronouns after 30 years, feel free to set your alarm clock for 2045.

r? @steveklabnik, since this is a documentation change and was created after reading http://words.steveklabnik.com/ouroboros, where I noticed this mistake.
2015-05-19 18:38:53 -04:00
Steve Klabnik
07c25d4ca0 Rollup merge of #25583 - steveklabnik:gh25517, r=alexcrichton
Fixes #25517
2015-05-19 18:38:53 -04:00
bors
c322dbbf8a Auto merge of #24333 - arielb1:implement-rfc401, r=nrc 2015-05-19 20:56:51 +00:00
Erik Michaels-Ober
b748c2e90d Change default gender in the dining philosophers project
The paper from which this example was taken made the mistake of assuming
that all five philosophers are men. This is a hypothetical
example--there are no actual philosophers eating spaghetti--so there is
no good reason to make this assumption. Since women make up about half
of the human population, all things being equal, women should represent
about half of the philosophers. However, because this mistake has stood
since 1985, I have changed *all* of the pronouns to be female, to make
up for lost time. If someone would like to revert this patch or switch
to neutral pronouns after 30 years, feel free to set your alarm clock
for 2045.
2015-05-19 22:38:24 +02:00
Ariel Ben-Yehuda
e7e1fd20de Fix rebase conflicts 2015-05-19 22:54:44 +03:00
bors
f34ff7af73 Auto merge of #25495 - alexcrichton:process-pid, r=aturon
This commits adds a method to the `std::process` module to get the process
identifier of the child as a `u32`. On Windows the underlying identifier is
already a `u32`, and on Unix the type is typically defined as `c_int` (`i32` for
almost all our supported platforms), but the actually pid is normally a small
positive number.

Eventually we may add functions to load information about a process based on its
identifier or the ability to terminate a process based on its identifier, but
for now this function should enable this sort of functionality to exist outside
the standard library.
2015-05-19 19:20:20 +00:00
Nick Hamann
50b802ade0 Add error explanations for E0185, E0186. 2015-05-19 14:00:30 -05:00
Brian Anderson
01c93a59e8 mk: Report the prerelease version on beta again. Fixes #25618 2015-05-19 11:34:34 -07:00
Alex Crichton
cb3071b273 mk: Update make dist for MSVC targets
This commit updates the `dist` target for MSVC to not build the mingw components
and to also ensure that the `llvm-ar.exe` binary is ferried along into the right
location for installs.
2015-05-19 10:53:07 -07:00
Alex Crichton
74f4f395ae std: Don't require rust_try as an exported symbol
This commit adds a small non-generic non-inlineable shim function to
`rt::unwind::try` which the compiler can take care of for managing the exported
symbol instead of having to edit `src/rt/rust_try.ll`
2015-05-19 10:53:07 -07:00
Alex Crichton
3d32cf5d9a rustc_trans: Apply dllexport attributes for MSVC
This commit modifies the compiler to emit `dllexport` for all reachable
functions and data on MSVC targets, regardless of whether a dynamic library is
being created or not. More details can be found in the commit itself.
2015-05-19 10:53:07 -07:00
Alex Crichton
9a2415b822 std: Mark rust_get_num_cpus as dllexport
This function is imported across the DLL boundary by the libtest dynamic
library, so it has to be marked as dllexport somehow, and for now this is done
with an attribute on the function specifically.
2015-05-19 10:53:07 -07:00
Alex Crichton
f5222fb892 std: Implement aborting stubs for MSVC unwinding
At this time unwinding support is not implemented for MSVC as
`libgcc_s_seh-1.dll` is not available by default (and this is used on MinGW),
but this should be investigated soon. For now this change is just aimed at
getting the compiler far enough to bootstrap everything instead of successfully
running tests.

This commit refactors the `std::rt::unwind` module a bit to prepare for SEH
support eventually by moving all GCC-specific functionality to its own submodule
and defining the interface needed.
2015-05-19 10:53:07 -07:00
Alex Crichton
847c8520b1 rustc_llvm: Don't export constants across dlls
For imports of constants across DLLs to work on Windows it *requires* that the
import be marked with `dllimport` (unlike functions where the marker is
optional, but strongly recommended). This currently isn't working for importing
FFI constants across boundaries, however, so the one constant exported from
`rustc_llvm.dll` is now a function to be called instead.
2015-05-19 10:53:07 -07:00
Alex Crichton
b538189ba0 mk: Generate a .def file for rustc_llvm on MSVC
Windows needs explicit exports of functions from DLLs but LLVM does not mention
any of its symbols as being export-able from a DLL. The compiler, however,
relies on being able to use LLVM symbols across DLL boundaries so we need to
force many of LLVM's symbols to be exported from `rustc_llvm.dll`. This commit
adds support for generation of a `rustc_llvm.def` file which is passed along to
the linker when generating `rustc_llvm.dll` which should keep all these symbols
exportable and usable.
2015-05-19 10:53:07 -07:00
Alex Crichton
ce8b317558 rustc_trans: Tidy up some style and line lengths
Match the surrounding style in the rest of the `rustc_trans::trans` module.
2015-05-19 10:53:06 -07:00
Alex Crichton
181dbd71d6 rustc_trans: Add MSVC linker support
This commit adds an implementation of the `Linker` trait which is used to drive
MSVC's `link.exe` support. Nothing too surprising here as it's mostly just
filling out the necessary tidbits here and there.
2015-05-19 10:53:06 -07:00
Alex Crichton
eb50ffd234 rustc_trans: Clean up some style in back::link
* Add some logging here and there
* Move some `err` + `abort_if_errors` to just using `fatal`
* Clean up some line-lengths
2015-05-19 10:53:06 -07:00
Alex Crichton
e2854b3893 libc: Add necessary libraries for MSVC
These libs seem to be required by the standard library at least to link
successfully!
2015-05-19 10:53:06 -07:00
Alex Crichton
d97b4af153 mklldeps: Don't link stdc++/c++ on MSVC
These libraries don't exist! The linker for MSVC is highly likely to not pass
`/NODEFAULTLIB` in which case the right standard library will automatically be
selected.
2015-05-19 10:53:06 -07:00
Alex Crichton
af56e2efde rustc_back: Tweak the MSVC target spec
This change primarily changes the default ar utility used by MSVC-targeting
compilers as `llvm-ar`, adding comments along the way as to why.
2015-05-19 10:53:06 -07:00
Alex Crichton
37659a1803 rustc_back: Remove unneeded explicit variable
This value is the default anyway
2015-05-19 10:53:06 -07:00
Alex Crichton
839dcfd5a7 rustc_back: Refactor Archive to better express intent
This commit was initially written to target either `ar` or `lib.exe` for MSVC,
but it ended up not needing `lib.exe` support after all. I would personally like
to refactor this to one day not invoke processes at all (but rather use the
`llvm-ar.cpp` file in LLVM as alibrary) so I chose to preserve this refactoring
to allow it to be easily done in the future.
2015-05-19 10:53:06 -07:00
Alex Crichton
f9846e902d rustc: Shorten MSVC metadata section name
It looks like section names in objects generated by `link.exe` are limited to at
most 8 characters in length, so shorten `.note.rustc` to just `.rustc`
2015-05-19 10:53:06 -07:00
Alex Crichton
a4ef308473 mk: Add the ability to depend on native LLVM tools
The compiler will require that `llvm-ar.exe` be available for MSVC-targeting
builds (more comments on this soon), so this commit adds support for targets to
depend on LLVM tools. The `core` library for MSVC depends on `llvm-ar.exe` which
will be copied into place for the target before the compiler starts to run.

Note that these targets all depend on `llvm-config.exe` to ensure that they're
built before they're attempted to be copied.
2015-05-19 10:53:04 -07:00
Alex Crichton
6122a5f559 mk: Fix MSVC build for rustllvm.lib
This commit updates the rustllvm.mk file with the necessary flags and such to
build rustllvm.lib with cl.exe instead of gcc. Some comments can be found in the
commit itself.
2015-05-19 10:52:57 -07:00
Alex Crichton
64412a49be mk: Fix building compiler-rt on MSVC
It looks like compiler-rt has a cmake build sytem inside its source, but I have
been unable to figure out how to use it and actually build the right library.
For now this commit hard-wires MSVC-targeting builds of libcompiler-rt to
continue using `make` as the primary bulid system, but some frobbing of the
flags are necessary to ensure that the right compiler is used.
2015-05-19 10:52:57 -07:00
Alex Crichton
ee64bab76c mk: Don't add cross prefixes for MSVC
Currently the MSVC compilers don't have any cross prefixes and we're only able
to make an MSVC compiler with a cross compile, so just avoid this logic on msvc
for now.
2015-05-19 10:52:57 -07:00
Alex Crichton
fcf7ecd1d7 mk: Add build system support for cl.exe
We have a number of support C/C++ files in Rust that we link into the standard
library and other various locations, and these all need to be built with cl.exe
instead of gcc.exe when targeting MSVC. This commit adds helper macros for this
functionality to use different sets of programs/flags/invocations on MSVC than
on GNU-like platforms.
2015-05-19 10:52:57 -07:00
Alex Crichton
b56d47cc80 mk: Enable building LLVM targeting MSVC
This commit modifies the makefiles to enable building LLVM with cmake and Visual
Studio to generate an LLVM that targets MSVC. Rust's configure script requires
cmake to be installed when targeting MSVC and will configure LLVM with cmake
instead of the normal `./configure` script LLVM provides. The build will then
run cmake to execute the build instead of the normal `make`.

Currently `make clean-llvm` isn't supported on MSVC as I can't figure out how to
run a "clean" target for the Visual Studio files.
2015-05-19 10:52:57 -07:00