Ryan Prichard [Wed, 22 Apr 2015 22:22:36 +0000 (15:22 -0700)]
Replace ignore-android with ignore-cross-compile in rustdoc tests
The problem is that rustdoc searches for external crates using the host
triple, not the target triple. It's actually unclear to me whether this is
correct behavior or not, but it is necessary to get cross-compiled tests
working.
Ryan Prichard [Wed, 22 Apr 2015 22:20:57 +0000 (15:20 -0700)]
Ignore cross-compilation in some fulldeps tests.
These tests fail, in general, for cross-compilation, because they require
the rustc crates to exist for the target, and they don't. We can't compile
them for the target unless we also compile LLVM for the target (we don't).
Android is a subset of cross-compilation.
The other fulldeps tests, on the other hand, work fine for
cross-compilation, and in fact, are verifying that rustc correctly searches
for a host plugin crate, not a target plugin crate.
Ryan Prichard [Fri, 17 Apr 2015 12:05:22 +0000 (05:05 -0700)]
Fix the dependency for the pretty-rpass-full tests
The current code attempts to define the
PRETTY_DEPS$(1)_H_$(3)_pretty-rpass-full variable, which does not work,
because $(1) and $(3) are not inside a function. Moreover, there is a test
(run-pass-fulldeps/compiler-calls.rs) that uses rustc_driver, which is not
an indirect dependency of librustc or libsyntax. Listing all the
dependencies will be hard to maintain, but there's a better way to do
this...
As with the rpass-full and cfail-full tests, add dependencies using the
$$(CSREQ$(1)_T_$(3)_H_$(3)) variable, which includes the complete set of
host and target crates, built for a particular stage and host. We use
T_$(3), not T_$(2), because we only build LLVM for host triples (not
target triples), so we can only build rustc_llvm for host triples. The
fulldeps tests that use plugins need host rustc crates, whereas fulldeps
tests that link against rustc and run should be skipped for
cross-compilation (such as Android).
Auto merge of #24422 - pnkfelix:typeck-highlevel-before-bodies, r=nikomatsakis
typeck: Do high-level structural/signature checks before function body checks.
This avoids various ICEs, e.g. premature calls to cat_expr that yield the dreaded "cat_expr Errd" ICE.
However, it also means that some early error feedback is now not provided. This may be for the best, because the error feedback were were providing in some of those cases were false positives -- it was spurious feedback and a distraction from the real problem.
So it is not 100% clear whether we actually want to put this change in or not. I think its a net win, but others might disagree.
(Kudos to @arielb1 for suggesting this modification.)
(The cast from the 64-bit value to isize was using the lower 32-bits,
which led to it being treated as a large positive value rather than a
smallish negative one. The fix was to use the same bits for the upper-
and lower- 32 bits.)
Alex Crichton [Mon, 13 Apr 2015 23:23:32 +0000 (16:23 -0700)]
rustdoc: Inline methods inhereted through Deref
Whenever a type implements Deref, rustdoc will now add a section to the "methods
available" sections for "Methods from Deref<Target=Foo>", listing all the
inherent methods of the type `Foo`.
Alex Crichton [Mon, 13 Apr 2015 18:55:00 +0000 (11:55 -0700)]
rustdoc: Overhaul stability displays
This commit is an overhaul to how rustdoc deals with stability of the standard
library. The handling has all been revisited with respect to Rust's current
approach to stability in terms of implementation as well as the state of the
standard library today. The high level changes made were:
* Stable items now have no marker by default
* Color-based small stability markers have been removed
* Module listings now fade out unstable/deprecated items slightly
* Trait methods have a separate background color based on stability and also
list the reason that they are unstable.
* `impl` blocks with stability no longer render at all. This may be re-added
once the compiler recognizes stability on `impl` blocks.
* `impl` blocks no longer have stability of the methods implemente indicated
* The stability summary has been removed
Auto merge of #24181 - jgallagher:aarch64-hfa, r=pnkfelix
I doubt this PR is ready to merge as-is, for a couple reasons:
* There are no tests for this change. I'm not sure how to add tests for this change, as it modifies the C ABI for a cross-compilation target. Anecdotally, I have an iOS library I've been working on, and before this change, it crashes running on an arm64 device due to bad calling conventions (a simplified example is in #24154), and after this change, it runs correctly.
* This is my first foray into LLVM. I did my best to reimplement what Clang does for AArch64 codegen (https://github.com/llvm-mirror/clang/blob/master/lib/CodeGen/TargetInfo.cpp), particularly in `ABIInfo::isHomogeneousAggregate`, `AArch64ABIInfo::isHomogeneousAggregateBaseType`, and `AArch64ABIInfo::isHomogeneousAggregateSmallEnough`, but I'm not confident I got a complete translation, particularly because Clang includes a lot of checks that I don't believe are necessary for rustc.
Auto merge of #24448 - alexcrichton:issue-24445, r=huonw
One of the parameters to the magical "register a thread-local destructor"
function is called `__dso_handle` and largely just passed along (this seems to
be what other implementations do). Currently we pass the *value* of this symbol,
but apparently the correct piece of information to pass is the *address* of the
symbol.
In a PIE binary the symbol actually contains an address to itself which is why
we've gotten away with what we're doing as long as we have. In a non-PIE binary
the symbol contains the address `NULL`, causing a segfault in the runtime
library if it keeps going.
Auto merge of #24437 - fhahn:issue-24434, r=alexcrichton
closes #24434
This PR changes executes `syntax::config::strip_unconfigured_items` before `syntax::feature_gate::check_crate_macros(sess.codemap()`. As far as I know, `strip_unconfigured_items` should be independent of `check_crate_macros`.
Auto merge of #24423 - tbelaire:include_bytes, r=alexcrichton
This is a little bit tricky, since with include_str!, we know that we
are including utf-8 content, so it's safe to store the source as a
String in a FileMap. We don't know that for include_bytes!, but I don't
think we actually need to track the contents anyways, so I'm passing "".
new_filemap does check for the zero length content, and it should be
reasonable, howeven I'm not sure if it would be better to pass None
instead of Some(Rc::new("")) as the src component of a FileMap.
Steve Klabnik [Wed, 15 Apr 2015 21:26:07 +0000 (17:26 -0400)]
Rollup merge of #24440 - nham:improve_enumerate_doc, r=alexcrichton
I found that the current description of `enumerate()` doesn't actually tell you what, specifically, the method does, and you have to look at the example to figure it out. Here's a description that I think is better.
Auto merge of #24330 - pnkfelix:issue-24267, r=nikomatsakis
Extend rustc::middle::dataflow to allow filtering kills from flow-exits.
Fix borrowck analysis so that it will not treat a break that pops through an assignment
```rust
x = { ... break; ... }
```
as a kill of the "moved-out" bit for `x`.
Fix #24267.
[breaking-change], but really, its only breaking code that was already buggy.
Revise rustc::middle::dataflow: one must select kill-kind when calling
add_kill. The current kill-kinds are (1.) kills associated with
ends-of-scopes and (2.) kills associated with the actual action of the
expression/pattern.
Then, use this to fix borrowck analysis so that it will not treat a
break that pops through an assignment `x = { ... break; ... }` as a
kill of the "moved-out" bit for `x`.
Alex Crichton [Wed, 15 Apr 2015 06:26:42 +0000 (23:26 -0700)]
std: Fix thread_local! in non-PIE binaries
One of the parameters to the magical "register a thread-local destructor"
function is called `__dso_handle` and largely just passed along (this seems to
be what other implementations do). Currently we pass the *value* of this symbol,
but apparently the correct piece of information to pass is the *address* of the
symbol.
In a PIE binary the symbol actually contains an address to itself which is why
we've gotten away with what we're doing as long as we have. In a non-PIE binary
the symbol contains the address `NULL`, causing a segfault in the runtime
library if it keeps going.
Theo Belaire [Wed, 15 Apr 2015 14:40:04 +0000 (10:40 -0400)]
Added a test for include_bytes! dep info
This tests that both include_str! and include_bytes! mark their input
file as a dependancy, and it's correctly outputted when you run
`rustc --emit dep-info`.
Auto merge of #24426 - alexcrichton:windows-pipes, r=aturon
This commit removes the last remnants of file descriptors from the Windows
implementation of `std::sys` by using `CreatePipe` to create anonymous pipes
instead of the `pipe` shim provided in msvcrt.
Auto merge of #24211 - alexcrichton:windows-wsa-flag-overlapped, r=aturon
This commit modifies the socket creation functions on windows to always specify
the `WSA_FLAG_OVERLAPPED` and `WSA_FLAG_NO_HANDLE_INHERIT` flags by default. The
overlapped flag enables IOCP APIs on Windows to be used with the socket at no
cost, enabling better interoperation with external libraries. The no handle
inherit flag mirrors the upcoming change to Unix to set CLOEXEC by default for
all handles.
Alex Crichton [Tue, 14 Apr 2015 18:17:47 +0000 (11:17 -0700)]
std: Remove final usage of fds from Windows
This commit removes the last remnants of file descriptors from the Windows
implementation of `std::sys` by using `CreatePipe` to create anonymous pipes
instead of the `pipe` shim provided in msvcrt.
Alex Crichton [Wed, 8 Apr 2015 22:43:37 +0000 (15:43 -0700)]
std: Set overlap/noinherit flags on windows sockets
This commit modifies the socket creation functions on windows to always specify
the `WSA_FLAG_OVERLAPPED` and `WSA_FLAG_NO_HANDLE_INHERIT` flags by default. The
overlapped flag enables IOCP APIs on Windows to be used with the socket at no
cost, enabling better interoperation with external libraries. The no handle
inherit flag mirrors the upcoming change to Unix to set CLOEXEC by default for
all handles.
Alex Crichton [Tue, 14 Apr 2015 17:55:57 +0000 (10:55 -0700)]
rollup merge of #24394: rundrop1/patch-1
Feel silly because it's just one thing but it was bothering me that the documentation tells you what you're not going to learn now instead of linking to the item in question. Am total noob pls assist, where is power button. :)
Alex Crichton [Tue, 14 Apr 2015 17:55:51 +0000 (10:55 -0700)]
rollup merge of #24379: rkruppe/fmt-negative-zero
Fixes #20596 by making `Debug` render negative zero with a `-` without affecting the behavior of `Display`.
While I was at it, I also removed some dead code from `float_to_str_bytes_common` (the one from `libcore/fmt/float.rs`, not the function of the same name in `libstd/num/strconv.rs`). It had support for different bases, and for negative numbers, but the function is internal to core and the couple places that call it (all in `libcore/fmt/mod.rs`) never use those features: They pass in `num.abs()` and base 10.
Alex Crichton [Tue, 14 Apr 2015 17:55:48 +0000 (10:55 -0700)]
rollup merge of #24376: lambdaburrito/master
Values for `_SC_*` are not the same value between `macos` and `linux` so I've added specific target constants for Mac OS X and added `_SC_NPROCESSORS_ONLN` for `linux` and `macos`.
Alex Crichton [Tue, 14 Apr 2015 17:55:45 +0000 (10:55 -0700)]
rollup merge of #24343: achanda/global_ip
- Adds two more functions for broadcast address and special
address classes reserved for documentation
- Modifies the globally routable IP check to include these
new functions
Alex Crichton [Tue, 14 Apr 2015 17:55:44 +0000 (10:55 -0700)]
rollup merge of #24342: tbelaire/patch-1
It was mistakenly calling `with_extension` with "foo.txt" instead of "txt".
I've also added an assert. This also calls more attention to the fact you get back a PathBuf, instead of a Path, which I feel is easy to miss when skimming.
Alex Crichton [Tue, 14 Apr 2015 17:55:41 +0000 (10:55 -0700)]
rollup merge of #24310: alexcrichton/stabilize-utf8-error
The meaning of each variant of this enum was somewhat ambiguous and it's uncler
that we wouldn't even want to add more enumeration values in the future. As a
result this error has been altered to instead become an opaque structure.
Learning about the "first invalid byte index" is still an unstable feature, but
the type itself is now stable.
Alex Crichton [Tue, 14 Apr 2015 17:55:40 +0000 (10:55 -0700)]
rollup merge of #24048: frewsxcv/patch-11
Since it doesn't utilize the parameter, it's not very idiomatic since it
could just use the `Result::or` method. So this changes the example to
utilize the parameter. As far as I can tell, all the numbers in this
example are completely arbitrary.
Theo Belaire [Tue, 14 Apr 2015 17:53:23 +0000 (13:53 -0400)]
include_bytes! now registers the file included
This is a little bit tricky, since with include_str!, we know that we
are including utf-8 content, so it's safe to store the source as a
String in a FileMap. We don't know that for include_bytes!, but I don't
think we actually need to track the contents anyways, so I'm passing "".
new_filemap does check for the zero length content, and it should be
reasonable, howeven I'm not sure if it would be better to pass None
instead of Some(Rc::new("")) as the src component of a FileMap.
projects / rust.git / log