bors [Tue, 16 Feb 2016 07:01:34 +0000 (07:01 +0000)]
Auto merge of #31668 - cuviper:lfs, r=alexcrichton
This follows the pattern already used for stat functions from #31551. Now
`ftruncate`, `lseek`, and `readdir_r` use their explicit 64-bit variants for
LFS support, using wider `off_t` and `dirent` types. This also updates to
`open64`, which uses no different types but implies the `O_LARGEFILE` flag.
Non-Linux platforms just map their normal functions to the 64-bit names.
bors [Tue, 16 Feb 2016 03:03:35 +0000 (03:03 +0000)]
Auto merge of #31639 - quodlibetor:doc-search-with-unknown-types, r=alexcrichton
This enables `*` in all type positions in doc searches, which I often
want in order to find functions that create or convert specific
types (e.g. `* -> vec`) but I don't actually know what kinds of input
they expect.
I actually started working on this because of #31598, but I've wanted it
several times when exploring new crates.
doc pages: add the ability to search unknown types
This enables `*` in all type positions in doc searches, which I often
want in order to find functions that create or convert specific
types (e.g. `* -> vec`) but I don't actually know what kinds of input
they expect.
I actually started working on this because of #31598, but I've wanted it
several times when exploring new crates.
bors [Mon, 15 Feb 2016 14:57:44 +0000 (14:57 +0000)]
Auto merge of #31656 - jonas-schievink:mirdump, r=nrc
This allows obtaining a textual MIR dump for individual items or all items in the crate.
I haven't added any tests since ~~I'm too lazy~~ this is an unstable debugging option, but I'll add one if required.
MIR for a single function can now be dumped using `rustc -Zunstable-options --unpretty mir=my_function` and no longer requires the use of in-source `#[rustc_mir]` attributes.
Blocks rust-lang/rust-playpen#154 (if MIR dump support from the playpen is even wanted).
Example output:
```rust
fn main() {
let x = Some(0);
x.unwrap_or_else(|| 1);
}
```
```
MIR for expr || 1 (id=16)
fn(arg0: [closure@test.rs:3:22: 3:26]) -> i32 {
let mut tmp0: ();
bb0: {
return = const 1;
goto -> bb1;
}
bb1: {
return;
}
}
MIR for fn main::main (id=4)
fn() -> () {
let var0: core::option::Option<i32>; // x
let mut tmp0: ();
let mut tmp1: i32;
let mut tmp2: core::option::Option<i32>;
let mut tmp3: [closure@test.rs:3:22: 3:26];
The `classifyArgumentType` function has two different paths depending on `RAA == CGCXXABI::RAA_DirectInMemory`, but I don't really know what's the corresponding option in Rust.
bors [Mon, 15 Feb 2016 07:13:02 +0000 (07:13 +0000)]
Auto merge of #31648 - jseyfried:fix_diagnostics, r=nrc
This PR fixes two unrelated diagnostics bugs in resolve.
First, it reports privacy errors for an import only after the import resolution is determined, fixing #31402.
Second, it expands the per-module map from block ids to anonymous modules so that it also maps module declarations ids to modules, and it uses this map to in `with_scope` to fix #31644.
Dirk Gadsden [Mon, 15 Feb 2016 06:26:37 +0000 (22:26 -0800)]
Rename `error-index-generator` to `error_index_generator`
This is because the tool compiler passes the name of the tool
as a command line `--cfg`. The improved session config parser
is stricter and no longer permits invalid meta items (such as
"error-index-generator").
Nick Cameron [Sun, 31 Jan 2016 19:39:50 +0000 (08:39 +1300)]
Add some simple error recovery to the parser and fix tests
Some tests just add the extra errors, others I fix by doing some simple error recovery. I've tried to avoid doing too much in the hope of doing something more principled later.
In general error messages are getting worse at this stage, but I think in the long run they will get better.
Alex Crichton [Sun, 7 Feb 2016 06:54:35 +0000 (22:54 -0800)]
std: Stop prefixing jemalloc symbols
Now that we properly only link in jemalloc when building executables, we have
far less to worry about in terms of polluting the global namespace with the
`free` and `malloc` symbols on Linux. This commit will primarily allow LLVM to
use jemalloc so the compiler will only be using one allocator overall.
Locally this took compile time for libsyntax from 95 seconds to 89 (a 6%
improvement).
Alex Crichton [Thu, 11 Feb 2016 19:06:31 +0000 (11:06 -0800)]
trans: Don't link whole rlibs to executables
Back in 9bc8e6d14 the linking of rlibs changed to using the `link_whole_rlib`
function. This change, however was only intended to affect dylibs, not
executables. For executables we don't actually want to link entire rlibs because
we want the linker to strip out as much as possible.
This commit adds a conditional to this logic to only link entire rlibs if we're
creating a dylib, and otherwise an executable just links an rlib as usual. A
test is included which will fail to link if this behavior is reverted.
Alex Crichton [Sun, 7 Feb 2016 06:56:25 +0000 (22:56 -0800)]
rustc: Ensure FNV hashing is inlined across crates
Right now the primary hashing algorithm of the compiler isn't actually inlined
across crates, meaning that it may be missing out on some crucial optimizations
in a few places (perhaps unrolling smaller loops, etc).
This commit made the hashing function disappear from a profiled version of the
compiler, but that's likely because it was just inlined elsewhere. When
compiling winapi, however, this decreased compile time from 18.3 to 17.8 seconds
(a 3% improvement).
bors [Sun, 14 Feb 2016 06:18:10 +0000 (06:18 +0000)]
Auto merge of #31581 - petrochenkov:patrefact, r=Manishearth
cc https://github.com/rust-lang/rust/pull/31487#issuecomment-182945101
plugin-[breaking-change]
The first commit renames `ast::Pat_` to `ast::PatKind` and uses its variants in enum qualified form. I've also taken the opportunity and renamed `PatKind::Region` into `PatKind::Ref`.
The second commit splits `PatKind::Enum` into `PatKind::TupleStruct` and `PatKind::UnitStruct`.
So, pattern kinds now correspond to their struct/variant kinds - `Struct`, `TupleStruct` and `UnitStruct`.
@nikomatsakis @nrc @arielb1 Are you okay with this naming scheme?
An alternative possible naming scheme is `PatKind::StructVariant`, `PatKind::TupleVariant`, `PatKind::UnitVariant` (it's probably closer to the common use, but I like it less).
I intend to apply these changes to HIR later, they should not necessarily go in the same nightly with https://github.com/rust-lang/rust/pull/31487
r? @Manishearth
Many of the types in these modules don't actually have a canonical platform
representation, for example the definition of `stat` on 32-bit Linux will change
depending on whether C code is compiled with LFS support or not. Unfortunately
the current types in `std::os::*::raw` are billed as "compatible with C", which
in light of this means it isn't really possible.
To make matters worse, platforms like Android sometimes define these types as
*smaller* than the way they're actually represented in the `stat` structure
itself. This means that when methods like `DirEntry::ino` are called on Android
the result may be truncated as we're tied to returning a `ino_t` type, not the
underlying type.
The commit here incorporates two backwards-compatible components:
* Deprecate all `raw` types that aren't in `std::os::raw`
* Expand the `std::os::*::fs::MetadataExt` trait on all platforms for method
accessors of all fields. The fields now returned widened types which are the
same across platforms (consistency across platforms is not required, however,
it's just convenient).
and two also backwards-incompatible components:
* Change the definition of all `std::os::*::raw` type aliases to
correspond to the newly widened types that are being returned on each
platform.
* Change the definition of `std::os::*::raw::stat` on Linux to match the LFS
definitions rather than the standard ones.
The breaking changes here will specifically break code that assumes that `libc`
and `std` agree on the definition of `std::os::*::raw` types, or that the `std`
types are faithful representations of the types in C. An [audit] has been
performed of crates.io to determine the fallout which was determined two be
minimal, with the two found cases of breakage having been fixed now.
Ok, so after all that, we're finally able to support LFS on Linux! This commit
then simultaneously starts using `stat64` and friends on Linux to ensure that we
can open >4GB files on 32-bit Linux. Yay!
Rollup merge of #31612 - raindev:grammar, r=steveklabnik
I feel sorry for bothering you with such a literally one character changes. If it is counter productive feel free to point it out in the comments, that would be totally understandable. I could try to pack such a changes together in one PR to make them less distractive.
Rollup merge of #31610 - Manishearth:doc-clarify-txrx, r=steveklabnik
Not everyone knows this convention. We could just rename the variables in the
example, but since this notation is commonly used it's a good opportunity to
introduce it.
Rollup merge of #31563 - SDX2000:docfixes1, r=steveklabnik
This is a minor change. Please see title. IMO this is important since this is the first instance when we talk about allocating a vector. Not saying that it is allocated on the stack here leaves room for speculation and this might put off some people (they might not even read the later sections which go into more detail about this).
Rollup merge of #31535 - Ketsuban:more-detail-in-wrapping-shift-documentation, r=steveklabnik
`wrapping_shl` and `wrapping_shr` are easy to mistake for rotations, when in fact they work somewhat differently. The documentation currently available is a little sparse and easy to misinterpret, so I've added a warning to anyone who bumps into them that the equivalent rotate methods may actually be what they're looking for.
If it's deemed useful to add a symmetrical mention to the documentation for the `rotate_left` and `rotate_right` methods, I can certainly have a go at that, but my gut feeling is that people likely to want a rotate will already know about the wrapping-arithmetic methods, for example from writing CPU simulators.
Many of the types in these modules don't actually have a canonical platform
representation, for example the definition of `stat` on 32-bit Linux will change
depending on whether C code is compiled with LFS support or not. Unfortunately
the current types in `std::os::*::raw` are billed as "compatible with C", which
in light of this means it isn't really possible.
To make matters worse, platforms like Android sometimes define these types as
*smaller* than the way they're actually represented in the `stat` structure
itself. This means that when methods like `DirEntry::ino` are called on Android
the result may be truncated as we're tied to returning a `ino_t` type, not the
underlying type.
The commit here incorporates two backwards-compatible components:
* Deprecate all `raw` types that aren't in `std::os::raw`
* Expand the `std::os::*::fs::MetadataExt` trait on all platforms for method
accessors of all fields. The fields now returned widened types which are the
same across platforms (consistency across platforms is not required, however,
it's just convenient).
and two also backwards-incompatible components:
* Change the definition of all `std::os::*::raw` type aliases to
correspond to the newly widened types that are being returned on each
platform.
* Change the definition of `std::os::*::raw::stat` on Linux to match the LFS
definitions rather than the standard ones.
The breaking changes here will specifically break code that assumes that `libc`
and `std` agree on the definition of `std::os::*::raw` types, or that the `std`
types are faithful representations of the types in C. An [audit] has been
performed of crates.io to determine the fallout which was determined two be
minimal, with the two found cases of breakage having been fixed now.
Ok, so after all that, we're finally able to support LFS on Linux! This commit
then simultaneously starts using `stat64` and friends on Linux to ensure that we
can open >4GB files on 32-bit Linux. Yay!
doc pages: add the ability to search unknown types
This enables `*` in all type positions in doc searches, which I often
want in order to find functions that create or convert specific
types (e.g. `* -> vec`) but I don't actually know what kinds of input
they expect.
I actually started working on this because of #31598, but I've wanted it
several times when exploring new crates.
Paul Dicker [Sat, 13 Feb 2016 19:44:37 +0000 (20:44 +0100)]
Fixes #28528
Fix `read_link` to also be able to read the target of junctions on Windows.
Also the path returned should not include a NT namespace, and there were
some problems with permissions.
bors [Sat, 13 Feb 2016 15:25:23 +0000 (15:25 +0000)]
Auto merge of #31588 - soltanmm:layer, r=nikomatsakis
<sup>**context:** moving back to a layered approach to type checking.</sup>
It looks like they'd not ended up tightly coupled in the time one was owned by the other. Every instance outside of `FnCtxt.inh` was from an `InferCtxt` created and dropped in the same function body.
This conflicts slightly with #30652, but there too it looks like the `FulfillmentContext` is from an `InferCtxt` that is created and dropped within the same function body (across one call to a module-private function).
That said, I heard that the PR that originally moved `FulfillmentContext` into `InferCtxt` was big, which leaves me concerned that I'm missing something.
bors [Sat, 13 Feb 2016 13:44:02 +0000 (13:44 +0000)]
Auto merge of #31579 - ollie27:msvc_link, r=alexcrichton
/LARGEADDRESSAWARE is already enabled for i686-pc-windows-gnu so we should probably be consistent.
https://msdn.microsoft.com/en-us/library/wz223b1z.aspx
/SAFESEH is a good thing to enable by default.
https://msdn.microsoft.com/en-us/library/9a89h429.aspx
bors [Sat, 13 Feb 2016 12:03:38 +0000 (12:03 +0000)]
Auto merge of #31570 - tomaka:ignore-emscripten, r=brson
Ignores 82 rpass tests that use threads.
I took care to only ignore tests that call `thread::spawn`. Some tests, for example `issue-16597`, also do fail because of lack of threads support, but for other reasons.
bors [Sat, 13 Feb 2016 08:27:42 +0000 (08:27 +0000)]
Auto merge of #31562 - llogiq:lint_post, r=Manishearth
This fixes #31512 for me.
A bit of explanation: I want to have `check_block_post(&mut self, &Context, &Block)` and `check_crate_post(&mut self, &Context, &Crate)` methods in both early and late lint passes. Ideally we'd have _post methods for all operations that walk, but this'll do for now.
projects / rust.git / log