Alex Crichton [Thu, 15 May 2014 18:15:35 +0000 (11:15 -0700)]
mk: Don't run benchmarks with `make check`
The current suite of benchmarks for the standard distribution take a significant
amount of time to run, but it's unclear whether we're gaining any benefit from
running them. Some specific pain points:
* No one is looking at the data generated by the benchmarks. We have no graphs
or analysis of what's happening, so all the data is largely being cast into
the void.
* No benchmark has ever uncovered a bug, they have always run successfully.
* Benchmarks not only take a significant amount of time to run, but also take a
significant amount of time to compile. I don't think we should mitigate this
for now because it's useful to ensure that they do indeed still compile.
This commit disables --bench test runs by default as part of `make check`,
flipping the NO_BENCH environment variable to a PLEASE_BENCH variable which will
manually enable benchmarking. If and when a dedicated bot is set up for
benchmarking, this flag can be enabled on that bot.
bors [Thu, 15 May 2014 15:36:50 +0000 (08:36 -0700)]
auto merge of #13954 : aturon/rust/issue-11650, r=alexcrichton
## Process API
The existing APIs for spawning processes took strings for the command
and arguments, but the underlying system may not impose utf8 encoding,
so this is overly limiting.
The assumption we actually want to make is just that the command and
arguments are viewable as [u8] slices with no interior NULLs, i.e., as
CStrings. The ToCStr trait is a handy bound for types that meet this
requirement (such as &str and Path).
However, since the commands and arguments are often a mixture of
strings and paths, it would be inconvenient to take a slice with a
single T: ToCStr bound. So this patch revamps the process creation API
to instead use a builder-style interface, called `Command`, allowing
arguments to be added one at a time with differing ToCStr
implementations for each.
The initial cut of the builder API has some drawbacks that can be
addressed once issue #13851 (libstd as a facade) is closed. These are
detailed as FIXMEs.
## Dynamic library API
`std::unstable::dynamic_library::open_external` currently takes a
`Path`, but because `Paths` produce normalized strings, this can
change the semantics of lookups in a given environment. This patch
generalizes the function to take a `ToCStr`-bounded type, which
includes both `Path`s and `str`s.
## ToCStr API
Adds ToCStr impl for &Path and ~str. This is a stopgap until DST (#12938) lands.
Until DST lands, we cannot decompose &str into & and str, so we cannot
usefully take ToCStr arguments by reference (without forcing an
additional & around &str). So we are instead temporarily adding an
instance for &Path and ~str, so that we can take ToCStr as owned. When
DST lands, the &Path instance should be removed, the string instances
should be revisted, and arguments bound by ToCStr should be passed by
reference.
Huon Wilson [Mon, 5 May 2014 12:44:07 +0000 (22:44 +1000)]
test: ensure that the extended usage description gets printed.
Previously the longer hand-written usage string was never being printed:
theoretically it was trying to detect when precisely `--help` was
passed (but not `-h`), but the getopts framework was considering a check
for the presence of `-h` to be a check for that of `--help` too,
i.e. the code was always going through the `-h` path.
This changes it to print the extended usage for both `-h` and `--help`,
meaning that it does actually appear correctly.
Test executed on Mac, Intel Core i7 2GHz. Result is:
* 20ns per iteration without patch
* 4ns per iteration with this patch applied
Once.doit could be even faster (800ps per iteration), if `doit` function
was split into a pair of `doit`/`doit_slow`, and `doit` marked as
`#[inline]` like this:
bors [Thu, 15 May 2014 09:41:50 +0000 (02:41 -0700)]
auto merge of #14145 : pnkfelix/rust/fsk-better-svh-via-visitor, r=alexcrichton
Teach SVH computation to ignore more implementation artifacts.
In particular, this version of strict version hash (SVH) works much
like the deriving(Hash)-based implementation did, except that it
deliberately:
1. skips over content known not affect the generated crates, and,
2. uses a content-based hash for names instead of using the value of
the `Name` index itself, which can differ depending on the order
in which strings are interned (which in turn is affected by
e.g. the presence of `--cfg` options on the command line).
Added tests checking that changes in type sig are recognized in SVH.
(Only after adding the tests did I realize that this is not really a
special case at the AST level; as far as the visitor is concerned,
`int` and `i32` and `i64` are just idents.)
A test case for a bug I found in the new SVH while reviewing it.
Namely: non-pub `use` declarations *are* significant to the SVH
computation, since they can change which traits are part of the method
resolution step, and thus affect which methods get called from the
(potentially inlined) code.
Teach SVH computation to ignore more implementation artifacts.
In particular, this version of strict version hash (SVH) works much
like the deriving(Hash)-based implementation did, except that uses a
content-based hash that filters rustc implementation artifacts and
surface syntax artifacts.
Aaron Turon [Mon, 5 May 2014 21:53:57 +0000 (14:53 -0700)]
Change dynamic_library::open_external to take ToCStr
`std::unstable::dynamic_library::open_external` currently takes a
`Path`, but because `Paths` produce normalized strings, this can
change the semantics of lookups in a given environment. This patch
generalizes the function to take a `ToCStr`-bounded type, which
includes both `Path`s and `str`s.
Aaron Turon [Mon, 5 May 2014 21:33:55 +0000 (14:33 -0700)]
Process::new etc should support non-utf8 commands/args
The existing APIs for spawning processes took strings for the command
and arguments, but the underlying system may not impose utf8 encoding,
so this is overly limiting.
The assumption we actually want to make is just that the command and
arguments are viewable as [u8] slices with no interior NULLs, i.e., as
CStrings. The ToCStr trait is a handy bound for types that meet this
requirement (such as &str and Path).
However, since the commands and arguments are often a mixture of
strings and paths, it would be inconvenient to take a slice with a
single T: ToCStr bound. So this patch revamps the process creation API
to instead use a builder-style interface, called `Command`, allowing
arguments to be added one at a time with differing ToCStr
implementations for each.
The initial cut of the builder API has some drawbacks that can be
addressed once issue #13851 (libstd as a facade) is closed. These are
detailed as FIXMEs.
Aaron Turon [Mon, 5 May 2014 21:15:11 +0000 (14:15 -0700)]
Add ToCStr impl for &Path and StrBuf
This is a stopgap until DST (#12938) lands.
Until DST lands, we cannot decompose &str into & and str, so we cannot
usefully take ToCStr arguments by reference (without forcing an
additional & around &str). So we are instead temporarily adding an
instance for &Path and StrBuf, so that we can take ToCStr as owned. When
DST lands, the &Path instance should be removed, the string instances
should be revisted, and arguments bound by ToCStr should be passed by
reference.
bors [Wed, 14 May 2014 19:06:29 +0000 (12:06 -0700)]
auto merge of #14086 : Ryman/rust/resolve_error_suggestions, r=alexcrichton
Provides better help for the resolve failures inside an `impl` if the name matches:
- a field on the self type
- a method on the self type
- a method on the current trait ref (in a trait impl)
Not handling trait method suggestions if in a regular `impl` (as you can see on line 69 of the test), I believe it is possible though.
Also, provides a better message when `self` fails to resolve due to being a static method.
It's using some unsafe pointers to skip copying the larger structures (which are only used in error conditions); it's likely possible to get it working with lifetimes (all the useful refs should outlive the visitor calls) but I haven't really figured that out for this case. (can switch to copying code if wanted)
bors [Wed, 14 May 2014 16:21:25 +0000 (09:21 -0700)]
auto merge of #14009 : jcmoyer/rust/bitflags-complement, r=alexcrichton
I feel that this is a very vital, missing piece of functionality. This adds on to #13072.
Only bits used in the definition of the bitflag are considered for the universe set. This is a bit safer than simply inverting all of the bits in the wrapped value.
// `Not` implements set complement
assert!(!(FlagB | FlagC) == FlagA);
// `all` and `is_all` are the inverses of `empty` and `is_empty`
assert!(Flags::all() - FlagA == !FlagA);
assert!(FlagABC.is_all());
```
bors [Wed, 14 May 2014 12:56:18 +0000 (05:56 -0700)]
auto merge of #14191 : luqmana/rust/eu, r=alexcrichton
We were correctly determining the attributes needed for the parameters for extern fns, but when that extern fn was from another crate we never bothered to pass that information along to LLVM. (i.e never called `foreign::add_argument_attributes`).
I've just changed both local and non-local (crate) extern fn's to be dealt with together (through `foreign::register_foreign_item_fn`) so we don't run into something like again.
Test executed on Mac, Intel Core i7 2GHz. Result is:
* 20ns per iteration without patch
* 4ns per iteration with this patch applied
Once.doit could be even faster (800ps per iteration), if `doit` function
was split into a pair of `doit`/`doit_slow`, and `doit` marked as
`#[inline]` like this:
bors [Wed, 14 May 2014 09:36:23 +0000 (02:36 -0700)]
auto merge of #14179 : luqmana/rust/acp, r=alexcrichton
It's a bit odd to single out just android when we don't do this for any other cross compiling targets. Android builds will still work since we just pass the full path for gcc and ar with `-C linker` and `-C ar`.
I did add the flag to compiletest though so it can find gdb. Though, i'm pretty sure we don't run debuginfo tests on android anyways right now.
bors [Wed, 14 May 2014 08:06:24 +0000 (01:06 -0700)]
auto merge of #14169 : alexcrichton/rust/atomics, r=sanxiyn
This module is a foundation on which many other algorithms are built. When hardware support is missing, stubs are provided in libcompiler-rt.a, so this should be available on all platforms.
Luqman Aden [Tue, 13 May 2014 18:44:30 +0000 (14:44 -0400)]
Get rid of the android-cross-path flag to rustc.
There's no need to include this specific flag just for android. We can
already deal with what it tries to solve by using -C linker=/path/to/cc
and -C ar=/path/to/ar. The Makefiles for rustc already set this up when
we're crosscompiling.
I did add the flag to compiletest though so it can find gdb. Though, I'm
pretty sure we don't run debuginfo tests on android anyways right now.
bors [Wed, 14 May 2014 03:01:28 +0000 (20:01 -0700)]
auto merge of #13127 : kballard/rust/read_at_least, r=alexcrichton
Reader.read_at_least() ensures that at least a given number of bytes
have been read. The most common use-case for this is ensuring at least 1
byte has been read. If the reader returns 0 enough times in a row, a new
error kind NoProgress will be returned instead of looping infinitely.
This change is necessary in order to properly support Readers that
repeatedly return 0, either because they're broken, or because they're
attempting to do a non-blocking read on some resource that never becomes
available.
Also add .push() and .push_at_least() methods. push() is like read() but
the results are appended to the passed Vec.
Remove Reader.fill() and Reader.push_exact() as they end up being thin
wrappers around read_at_least() and push_at_least().
Kevin Ballard [Tue, 25 Mar 2014 06:22:23 +0000 (23:22 -0700)]
io: Add .read_at_least() to Reader
Reader.read_at_least() ensures that at least a given number of bytes
have been read. The most common use-case for this is ensuring at least 1
byte has been read. If the reader returns 0 enough times in a row, a new
error kind NoProgress will be returned instead of looping infinitely.
This change is necessary in order to properly support Readers that
repeatedly return 0, either because they're broken, or because they're
attempting to do a non-blocking read on some resource that never becomes
available.
Also add .push() and .push_at_least() methods. push() is like read() but
the results are appended to the passed Vec.
Remove Reader.fill() and Reader.push_exact() as they end up being thin
wrappers around read_at_least() and push_at_least().
bors [Wed, 14 May 2014 01:31:51 +0000 (18:31 -0700)]
auto merge of #14187 : alexcrichton/rust/rollup, r=alexcrichton
Closes #14184 (std: Move the owned module from core to std)
Closes #14183 (Allow blocks in const expressions)
Closes #14176 (Add tests for from_bits.)
Closes #14175 (Replaced ~T by Box<T> in manual)
Closes #14173 (Implements Default trait for BigInt and BigUint)
Closes #14171 (Fix #8391)
Closes #14159 (Clean up unicode code in libstd)
Closes #14126 (docs: Add a not found page)
Closes #14123 (add a line to the example to clarify semantics)
Closes #14106 (Pretty printer improvements)
Closes #14083 (rustllvm: Add LLVMRustArrayType)
Closes #13957 (io: Implement process wait timeouts)
Alex Crichton [Mon, 5 May 2014 23:58:42 +0000 (16:58 -0700)]
io: Implement process wait timeouts
This implements set_timeout() for std::io::Process which will affect wait()
operations on the process. This follows the same pattern as the rest of the
timeouts emerging in std::io::net.
The implementation was super easy for everything except libnative on unix
(backwards from usual!), which required a good bit of signal handling. There's a
doc comment explaining the strategy in libnative. Internally, this also required
refactoring the "helper thread" implementation used by libnative to allow for an
extra helper thread (not just the timer).
This is a breaking change in terms of the io::Process API. It is now possible
for wait() to fail, and subsequently wait_with_output(). These two functions now
return IoResult<T> due to the fact that they can time out.
Additionally, the wait_with_output() function has moved from taking `&mut self`
to taking `self`. If a timeout occurs while waiting with output, the semantics
are undesirable in almost all cases if attempting to re-wait on the process.
Equivalent functionality can still be achieved by dealing with the output
handles manually.
klutzy [Sat, 10 May 2014 08:30:55 +0000 (17:30 +0900)]
rustllvm: Add LLVMRustArrayType
LLVM internally uses `uint64_t` for array size, but the corresponding
C API (`LLVMArrayType`) uses `unsigned int` so ths value is truncated.
Therefore rustc generates wrong type for fixed-sized large vector e.g.
`[0 x i8]` for `[0u8, ..(1 << 32)]`.
This patch adds `LLVMRustArrayType` function for `uint64_t` support.
Alex Crichton [Sun, 11 May 2014 08:34:28 +0000 (01:34 -0700)]
syntax: Improve --pretty normal slightly
When printing doc comments, always put a newline after them in a macro
invocation to ensure that a line-doc-comment doesn't consume remaining tokens on
the line.
Alex Crichton [Sun, 11 May 2014 08:11:33 +0000 (01:11 -0700)]
syntax: Preserve attributes in #[deriving]
Now that the #[deriving] attribute is removed, the raw_pointers_deriving lint
was broken. This commit restores the lint by preserving lint attributes
across #[deriving] to the implementations and using #[automatically_derived] as
the trigger for activating the lint.
Alex Crichton [Sun, 11 May 2014 03:16:51 +0000 (20:16 -0700)]
syntax: Fix printing INT64_MIN
Integers are always parsed as a u64 in libsyntax, but they're stored as i64. The
parser and pretty printer both printed an i64 instead of u64, sometimes
introducing an extra negative sign.
Alex Crichton [Sun, 11 May 2014 00:39:08 +0000 (17:39 -0700)]
Touch up and rebase previous commits
* Added `// no-pretty-expanded` to pretty-print a test, but not run it through
the `expanded` variant.
* Removed #[deriving] and other expanded attributes after they are expanded
* Removed hacks around &str and &&str and friends (from both the parser and the
pretty printer).
* Un-ignored a bunch of tests
After testing `--pretty normal`, it tries to run `--pretty expanded` and
typecheck output.
Here we don't check convergence since it really diverges: for every
iteration, some extra lines (e.g.`extern crate std`) are inserted.
Some tests are `ignore-pretty`-ed since they cause various issues
with `--pretty expanded`.
Some `Expr` needs parentheses when printed. For example, without
parentheses, `ExprUnary(UnNeg, ExprBinary(BiAdd, ..))` becomes
`-lhs + rhs` which is wrong.
Those cases don't appear in ordinary code (since parentheses are
explicitly added) but they can appear in manually crafted ast by
extensions.
This is to clarify that match construct doesn't define a new variable, since I
observed a person reading the Rust tutorial who seemed to incorrectly think
that it did. Fixes https://github.com/mozilla/rust/issues/13571 .
Florian Zeitz [Mon, 12 May 2014 20:44:21 +0000 (22:44 +0200)]
std: Rename str::Normalizations to str::Decompositions
The Normalizations iterator has been renamed to Decompositions.
It does not currently include all forms of Unicode normalization,
but only encompasses decompositions.
If implemented recomposition would likely be a separate iterator
which works on the result of this one.
Alex Crichton [Tue, 13 May 2014 21:58:29 +0000 (14:58 -0700)]
std: Move the owned module from core to std
The compiler was updated to recognize that implementations for ty_uniq(..) are
allowed if the Box lang item is located in the current crate. This enforces the
idea that libcore cannot allocated, and moves all related trait implementations
from libcore to libstd.
This is a breaking change in that the AnyOwnExt trait has moved from the any
module to the owned module. Any previous users of std::any::AnyOwnExt should now
use std::owned::AnyOwnExt instead. This was done because the trait is intended
for Box traits and only Box traits.
bors [Tue, 13 May 2014 23:01:48 +0000 (16:01 -0700)]
auto merge of #14075 : Rufflewind/rust/patch-3, r=alexcrichton
- Use Unicode-aware versions of `CreateProcess` (Fixes #13815) and `Get/FreeEnvironmentStrings`.
- Includes a helper function `os::win32::as_mut_utf16_p`, which does the same thing as `os::win32::as_utf16_p` except the pointer is mutable.
- Fixed `make_command_line` to handle Unicode correctly.
- Tests for the above.
Phil Ruffwind [Wed, 7 May 2014 23:26:16 +0000 (19:26 -0400)]
Test Unicode support of process spawning
Added a run-pass test to ensure that processes can be correctly spawned
using non-ASCII arguments, working directory, and environment variables.
It also tests Unicode support of os::env_as_bytes.
An additional assertion was added to the test for make_command_line to
verify it handles Unicode correctly.