Alex Crichton [Wed, 12 Aug 2015 05:11:34 +0000 (22:11 -0700)]
rollup merge of #27650: dotdash/backtrace_test
LLVM might perform tail merging on the calls that initiate the unwinding
process which breaks debuginfo and therefore this test. Since tail
merging is guaranteed to break debuginfo, it should be disabled for this
test.
This allows us to restore a testcase that I had to remove earlier
because of the same problem, because back then I didn't realize that
disabling tail merging was an option.
bors [Tue, 11 Aug 2015 17:27:34 +0000 (17:27 +0000)]
Auto merge of #27571 - TimNN:pretty-no-crate-type, r=alexcrichton
Because I wanted to change the pretty test as little as possible I added `// compiler-flags: --crate-type=lib` to those test that failed because of a missing `main`. Passes `make check-stage1-pretty` locally.
bors [Tue, 11 Aug 2015 12:59:14 +0000 (12:59 +0000)]
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.
Rollup merge of #27612 - vincentbernat:fix/doc/iter-nth, r=steveklabnik
The "nth" element can be confusing. In an array context, we know indexes
start from 0 but one may believe this is not the case with "nth". For
example, would `.nth(1)` return the first (1th/1st) or the second
element? Rephrase a bit to be less confusing.
Rollup merge of #27611 - vincentbernat:fix/doc/chars-iterator, r=steveklabnik
The previous wording was confusing. While would we need to go through
the whole list just to find the first code point? `chars()` being an
iterator, we only need to walk from the beginning of the list.
Note that I am not a native English speaker and I have still difficulties to spot if a "the" is needed somewhere. Feel free to take this PR as a mere suggestion.
Rollup merge of #27577 - diaphore:trailing-newline-formatmessagew, r=alexcrichton
`FormatMessageW` always inserts trailing `\r\n` to system messages which is a minor annoyance when they're fed to `Debug` but can break formatting with `Display`.
```rust
fn main() {
use std::env;
if let Err(err) = env::set_current_dir("???") {
println!("{:#?}\n{}", err, err);
}
}
```
```_
Error {
repr: Os {
code: 2,
message: "The system cannot find the file specified.\r\n"
}
}
The system cannot find the file specified.
(os error 2)
```
bors [Tue, 11 Aug 2015 07:48:39 +0000 (07:48 +0000)]
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!
bors [Tue, 11 Aug 2015 03:47:16 +0000 (03:47 +0000)]
Auto merge of #26818 - sfackler:duration-stabilization, r=aturon
This commit stabilizes the `std::time` module and the `Duration` type.
`Duration::span` remains unstable, and the `Display` implementation for
`Duration` has been removed as it is still being reworked and all trait
implementations for stable types are de facto stable.
This is a [breaking-change] to those using `Duration`'s `Display`
implementation.
I'm opening this PR as a platform for discussion - there may be some method renaming to do as part of the stabilization process.
bors [Tue, 11 Aug 2015 02:10:31 +0000 (02:10 +0000)]
Auto merge of #27416 - alexcrichton:fix-dll-export, r=brson
These two commits are aimed at "fixing" our usage of `dllexport` in the compiler. Currently we blanket apply this attribute to *everything* public in a crate, but this ends up with a few downsides:
* Executables are larger than the should be as a result of thinking they should export everything
* Native libraries aren't handled correctly because technically a statically included native library should be exported from a DLL in some cases.
* Symbols don't actually need to be exported if they never end up in a DLL.
The first commit adds a new unstable attribute, `#[linked_from]`, which is a way to tell the compiler what native library a block of symbols comes from. This is used to inform the compiler what set of native libraries are statically included in the rlib (or other output). This information is later used to export them from a DLL if necessary. Currently this is only used in a few places (such as the LLVM bindings) to get the compiler to link correctly.
The second commit stops adding `dllexport` to all items in LLVM and instead explicitly telling the linker what symbols should be exported. We only need to do this when building a dynamic library, and otherwise we can avoid adding `dllexport` or telling the linker about exported symbols.
As a testament to this change, the size of "Hello World" on MSVC drops from 1.2MB to 67KB as a result of this patch. This is because the linker can much more aggressively remove unused code.
These commits do not yet attempt to fix our story with `dllimport`, and I'll leave that to a future PR and issue, for now though I'm going to say that this
Alex Crichton [Wed, 29 Jul 2015 00:19:08 +0000 (17:19 -0700)]
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.
Alex Crichton [Thu, 30 Jul 2015 21:20:36 +0000 (14:20 -0700)]
syntax: Add a new unstable #[linked_from] attribute
To correctly reexport statically included libraries from a DLL on Windows, the
compiler will soon need to have knowledge about what symbols are statically
included and which are not. To solve this problem a new unstable
`#[linked_from]` attribute is being added and recognized on `extern` blocks to
indicate which native library the symbols are coming from.
The compiler then keeps track of what the set of FFI symbols are that are
included statically. This information will be used in a future commit to
configure how we invoke the linker on Windows.
Alex Crichton [Tue, 4 Aug 2015 16:08:07 +0000 (09:08 -0700)]
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!
Steven Fackler [Mon, 6 Jul 2015 06:20:00 +0000 (23:20 -0700)]
Stabilize the Duration API
This commit stabilizes the `std::time` module and the `Duration` type.
`Duration::span` remains unstable, and the `Display` implementation for
`Duration` has been removed as it is still being reworked and all trait
implementations for stable types are de facto stable.
This is a [breaking-change] to those using `Duration`'s `Display`
implementation.
This is a temporary workaround for the bugs that have been found in
the implementation of PR #26173.
* pnkfelix is unavailable in the short-term (i.e. for the next week) to fix them.
* When the bugs are fixed, we will turn this back on by default.
(If you want to play with the known-to-be-buggy optimization in the
meantime, you can opt-back in via the debugging option that this
commit is toggling.)
bors [Mon, 10 Aug 2015 23:40:54 +0000 (23:40 +0000)]
Auto merge of #27338 - alexcrichton:remove-morestack, r=brson
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)
Alex Crichton [Mon, 27 Jul 2015 20:41:35 +0000 (13:41 -0700)]
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)
Björn Steinbrink [Mon, 10 Aug 2015 23:03:36 +0000 (01:03 +0200)]
Make the backtrace-debuginfo test less error prone
LLVM might perform tail merging on the calls that initiate the unwinding
process which breaks debuginfo and therefore this test. Since tail
merging is guaranteed to break debuginfo, it should be disabled for this
test.
This allows us to restore a testcase that I had to remove earlier
because of the same problem, because back then I didn't realize that
disabling tail merging was an option.
bors [Mon, 10 Aug 2015 18:46:21 +0000 (18:46 +0000)]
Auto merge of #27252 - tbu-:pr_less_transmutes, r=alexcrichton
The replacements are functions that usually use a single `mem::transmute` in their body and restrict input and output via more concrete types than `T` and `U`. Worth noting are the `transmute` functions for slices and the `from_utf8*` family for mutable slices. Additionally, `mem::transmute` was often used for casting raw pointers, when you can already cast raw pointers just fine with `as`.
bors [Mon, 10 Aug 2015 17:06:15 +0000 (17:06 +0000)]
Auto merge of #27516 - alexcrichton:osx-flaky-zomg, r=brson
The investigation into #14232 discovered that it's possible that signal delivery
to a newly spawned process is racy on OSX. This test has been failing spuriously
on the OSX bots for some time now, so ignore it as we don't currently know a
solution and it looks like it may be out of our control.
bors [Mon, 10 Aug 2015 14:40:07 +0000 (14:40 +0000)]
Auto merge of #27547 - vberger:more_perseverant_resolve, r=nrc
As noted in my previous PR #27439 , the import resolution algorithm has two cases where it bails out:
- The algorithm will delay an import if the module containing the target of the import still has unresolved glob imports
- The algorithm will delay a glob import of the target module still has unresolved imports
This PR alters the behaviour to only bail out when the above described unresolved imports are `pub`, as non-pub imports don't affect the result anyway.
It is still possible to fail the algorithm with examples like
```rust
pub mod a {
pub use b::*;
}
pub mod b {
pub use a::*;
}
```
but such configurations cannot be resolved in any meaningful way, as these are cyclic imports.
bors [Mon, 10 Aug 2015 12:01:01 +0000 (12:01 +0000)]
Auto merge of #27634 - TimNN:master, r=dotdash
I don't know how this single inline caused the breakage but it seems to be the cause of the issue (see https://github.com/rust-lang/rust/issues/27619#issuecomment-129420094).
Replace many uses of `mem::transmute` with more specific functions
The replacements are functions that usually use a single `mem::transmute` in
their body and restrict input and output via more concrete types than `T` and
`U`. Worth noting are the `transmute` functions for slices and the `from_utf8*`
family for mutable slices. Additionally, `mem::transmute` was often used for
casting raw pointers, when you can already cast raw pointers just fine with
`as`.
Vincent Bernat [Sat, 8 Aug 2015 23:04:59 +0000 (01:04 +0200)]
doc/core: fix description of `nth` function
The "nth" element can be confusing. In an array context, we know indexes
start from 0 but one may believe this is not the case with "nth". For
example, would `.nth(1)` return the first (1th/1st) or the second
element? Rephrase a bit to be less confusing.
Vincent Bernat [Sat, 8 Aug 2015 22:56:38 +0000 (00:56 +0200)]
TRPL: minor correction on how `chars().nth()` work
The previous wording was confusing. While would we need to go through
the whole list just to find the first code point? `chars()` being an
iterator, we only need to walk from the beginning of the list.
bors [Sat, 8 Aug 2015 16:27:12 +0000 (16:27 +0000)]
Auto merge of #27595 - mike-marcacci:patch-1, r=steveklabnik
Keeping integer values and integer references in the "value" columns made the examples quite difficult for me to follow. I've added unicode arrows to references to make them more obvious, without using any characters with actual meaning in the rust language (like `&` or previously `~`).
Fix the function return type used in get_res_dtor()
Instead of the actual return type, we're currently passing the function
type to get_extern_fn(). The only reason this doesn't explode is because
get_extern_fn() actually doesn't care about the actual return type, just
about it being converging or not.
Mike Marcacci [Sat, 8 Aug 2015 06:13:08 +0000 (23:13 -0700)]
Added arrows to references in tables
Keeping integer values and integer references in the "value" columns made the examples quite difficult for me to follow. I've added unicode arrows to make references more obvious, without using a character with actual meaning in the rust language (like `&` or previously `~`).
This is a temporary workaround for the bugs that have been found in
the implementation of PR #26173.
* pnkfelix is unavailable in the short-term (i.e. for the next week) to fix them.
* When the bugs are fixed, we will turn this back on by default.
(If you want to play with the known-to-be-buggy optimization in the
meantime, you can opt-back in via the debugging option that this
commit is toggling.)
bors [Fri, 7 Aug 2015 12:23:06 +0000 (12:23 +0000)]
Auto merge of #27551 - arielb1:adt-def, r=nikomatsakis
This ended up being a bigger refactoring than I thought, as I also cleaned a few ugly points in rustc. There are still a few areas that need improvements.
projects / rust.git / log