The change in #13600 was incorrect, containing a bad regular expression;
inside an indent function, errors are silently ignored (and the ``~=``
operation will return 0), so it just always failed, causing the cases
that were supposed to be caught to not be caught and making things like
the ``match`` example shown above or struct field definitions regress.
I have fixed the regular expression to what it should have been. This is
still imperfect, of course, not handling cases like where the first
argument to a function is a function call (``foo(bar(),``), but it'll do
for now.
----
I have a general request to make of reviewers about any changes made to `src/etc/vim`: **please tell me**. As a general rule I want to review them. (I’ll make an exception for changes the prelude; it needs fixing from time to time when some people don’t update the syntax file, anyway.)
cc @brandonw
The `walk_dir` iterator was simulating a queue using a vector (in particular, using `shift`),
leading to O(n^2) performance. Since the order was not well-specified (see issue #13411),
the simplest fix is to use the vector as a stack (and thus yield a depth-first traversal).
This patch does exactly that, and adds a test checking for depth-first behavior.
Note that the underlying `readdir` function does not specify any particular order, nor
does the system call it uses.
Closes#13411.
A new flag to the test runner, --nocapture, can be passed to instruct that the
output of tests should not be captured by default. The behavior can also be
triggered via a RUST_TEST_NOCAPTURE environment variable being set.
Closes#13374
The `walk_dir` iterator was simulating a queue using a vector (in particular, using `shift`),
leading to O(n^2) performance. Since the order was not well-specified (see issue #13411),
the simplest fix is to use the vector as a stack (and thus yield a depth-first traversal).
This patch does exactly that. It leaves the order as originally specified -- "some top-down
order" -- and adds a test to ensure a top-down traversal.
Note that the underlying `readdir` function does not specify any particular order, nor
does the system call it uses.
Closes#13411.
This update brings a few months of changes, but primarily a fix for the
following situation.
When creating a handle to stdin, libuv used to set the stdin handle to
nonblocking mode. This would end up affect this stdin handle across all
processes that shared it, which mean that stdin become nonblocking for everyone
using the same stdin. On linux, this also affected *stdout* because stdin/stdout
roughly point at the same thing.
This problem became apparent when running the test suite manually on a local
computer. The stdtest suite (running with libgreen) would set stdout to
nonblocking mode (as described above), and then the next test suite would always
fail for a printing failure (because stdout was returning EAGAIN).
This has been fixed upstream, joyent/libuv@342e8c, and this update pulls in this
fix. This also brings us in line with a recently upstreamed libuv patch.
Closes#12827Closes#13336Closes#13355
A new flag to the test runner, --nocapture, can be passed to instruct that the
output of tests should not be captured by default. The behavior can also be
triggered via a RUST_TEST_NOCAPTURE environment variable being set.
Closes#13374
This update brings a few months of changes, but primarily a fix for the
following situation.
When creating a handle to stdin, libuv used to set the stdin handle to
nonblocking mode. This would end up affect this stdin handle across all
processes that shared it, which mean that stdin become nonblocking for everyone
using the same stdin. On linux, this also affected *stdout* because stdin/stdout
roughly point at the same thing.
This problem became apparent when running the test suite manually on a local
computer. The stdtest suite (running with libgreen) would set stdout to
nonblocking mode (as described above), and then the next test suite would always
fail for a printing failure (because stdout was returning EAGAIN).
This has been fixed upstream, joyent/libuv@342e8c, and this update pulls in this
fix. This also brings us in line with a recently upstreamed libuv patch.
Closes#13336Closes#13355
Specifically, the method parameter cardinality mismatch or missing
method error message span now gets method itself exactly. It was the
whole expression.
Closes#9390Closes#13684Closes#13709
The change in #13600 was incorrect, containing a bad regular expression;
inside an indent function, errors are silently ignored (and the ``~=``
operation will return 0), so it just always failed, causing the cases
that were supposed to be caught to not be caught and making things like
the ``match`` example shown above or struct field definitions regress.
I have fixed the regular expression to what it should have been. This is
still imperfect, of course, not handling cases like where the first
argument to a function is a function call (``foo(bar(),``), but it'll do
for now.
This patch removes the special auto-rooting for `@` from the borrow checker. With `@` moving into a library, it doesn't make sense to keep this code around anymore. It also simplifies `trans` by removing root checking from there
@nikomatsakis
Closes: #11586
Some of the constant values in std::f32 were incorrectly copied from
std::f64. More broadly, both modules defined their constants redundantly
in two places, which is what led to the bug. Moreover, the specs for
some of the constants were incorrect, even when the values were correct.
Closes#13297. Closes#11537.
This is really only useful for #[cfg()]. For example:
```rust
enum Foo {
Bar,
Baz,
#[cfg(blob)]
Blob
}
fn match_foos(f: &Foo) {
match *f {
Bar => {}
Baz => {}
#[cfg(blob)]
Blob => {}
}
}
```
This is a kind of weird place to allow attributes, so it should probably
be discussed before merging.
The constructor for `TaskBuilder` is being changed to an associated
function called `new` for consistency with the rest of the standard
library.
Closes#13666
[breaking-change]
The constructor for `TaskBuilder` is being changed to an associated
function called `new` for consistency with the rest of the standard
library.
Closes#13666
[breaking-change]
This adds experimental support for timeouts when accepting sockets through
`TcpAcceptor::accept`. This does not add a separate `accept_timeout` function,
but rather it adds a `set_timeout` function instead. This second function is
intended to be used as a hard deadline after which all accepts will never block
and fail immediately.
This idea was derived from Go's SetDeadline() methods. We do not currently have
a robust time abstraction in the standard library, so I opted to have the
argument be a relative time in millseconds into the future. I believe a more
appropriate argument type is an absolute time, but this concept does not exist
yet (this is also why the function is marked #[experimental]).
The native support is built on select(), similarly to connect_timeout(), and the
green support is based on channel select and a timer.
cc #13523
This adds experimental support for timeouts when accepting sockets through
`TcpAcceptor::accept`. This does not add a separate `accept_timeout` function,
but rather it adds a `set_timeout` function instead. This second function is
intended to be used as a hard deadline after which all accepts will never block
and fail immediately.
This idea was derived from Go's SetDeadline() methods. We do not currently have
a robust time abstraction in the standard library, so I opted to have the
argument be a relative time in millseconds into the future. I believe a more
appropriate argument type is an absolute time, but this concept does not exist
yet (this is also why the function is marked #[experimental]).
The native support is built on select(), similarly to connect_timeout(), and the
green support is based on channel select and a timer.
cc #13523
Specifically, the method parameter cardinality mismatch or missing
method error message span now gets method itself exactly. It was the
whole expression.
Closes#9390Closes#13684Closes#13709
Some of the constant values in std::f32 were incorrectly copied from
std::f64. More broadly, both modules defined their constants redundantly
in two places, which is what led to the bug. Moreover, the specs for
some of the constants were incorrent, even when the values were correct.
Closes#13297. Closes#11537.
This allows the use of syntax extensions when cross-compiling (fixing #12102). It does this by encoding the target triple in the crate metadata and checking it when searching for files. Currently the crate triple must match the host triple when there is a macro_registrar_fn, it must match the target triple when linking, and can match either when only macro_rules! macros are used.
due to carelessness, this is pretty much a duplicate of https://github.com/mozilla/rust/pull/13450.
This adds the target triple to the crate metadata.
When searching for a crate the phase (link, syntax) is taken into account.
During link phase only crates matching the target triple are considered.
During syntax phase, either the target or host triple will be accepted, unless
the crate defines a macro_registrar, in which case only the host triple will
match.
This alters the borrow checker's requirements on invoking closures from
requiring an immutable borrow to requiring a unique immutable borrow. This means
that it is illegal to invoke a closure through a `&` pointer because there is no
guarantee that is not aliased. This does not mean that a closure is required to
be in a mutable location, but rather a location which can be proven to be
unique (often through a mutable pointer).
For example, the following code is unsound and is no longer allowed:
type Fn<'a> = ||:'a;
fn call(f: |Fn|) {
f(|| {
f(|| {})
});
}
fn main() {
call(|a| {
a();
});
}
There is no replacement for this pattern. For all closures which are stored in
structures, it was previously allowed to invoke the closure through `&self` but
it now requires invocation through `&mut self`.
The standard library has a good number of violations of this new rule, but the
fixes will be separated into multiple breaking change commits.
Closes#12224
The filestem of the desired output isn't necessarily a valid crate id, and
calling unwrap() will trigger an ICE in rustc. This tries a little harder to
infer a "valid crate id" from a crate, with an eventual fallback to a generic
crate id if alll else fails.
Closes#11107
Many of the instances of setting a global error variable ended up leaving a
dangling pointer into free'd memory. This changes the method of error
transmission to strdup any error and "relinquish ownership" to rustc when it
gets an error. The corresponding Rust code will then free the error as
necessary.
Closes#12865
As with the previous commits, the Finally trait is primarily implemented for
closures, so the trait was modified from `&self` to `&mut self`. This will
require that any closure variable invoked with `finally` to be stored in a
mutable slot.
[breaking-change]
This is similar to the previous commits to allow invocation of a closure through
a `&mut self` pointer because `&self` is disallowed. One of the primary
implementors of the CharEq trait is a closure type, which would not work if the
method continued to have `&self`.
In addition to changing mutability of the `matches` method, this modifies the
following methods from &CharEq to take a type which implements CharEq by value.
* trim_chars
* trim_left_chars
* trim_right_chars
Where these methods were previously invoked via
s.trim_chars(&'a')
it would now be invoked through
s.trim_chars('a')
[breaking-change]
Many iterators go through a closure when dealing with the `idx` method, which
are invalid after the previous change (closures cannot be invoked through a `&`
pointer). This commit alters the `fn idx` method on the RandomAccessIterator
to take `&mut self` rather than `&self`.
[breaking-change]
This alters the borrow checker's requirements on invoking closures from
requiring an immutable borrow to requiring a unique immutable borrow. This means
that it is illegal to invoke a closure through a `&` pointer because there is no
guarantee that is not aliased. This does not mean that a closure is required to
be in a mutable location, but rather a location which can be proven to be
unique (often through a mutable pointer).
For example, the following code is unsound and is no longer allowed:
type Fn<'a> = ||:'a;
fn call(f: |Fn|) {
f(|| {
f(|| {})
});
}
fn main() {
call(|a| {
a();
});
}
There is no replacement for this pattern. For all closures which are stored in
structures, it was previously allowed to invoke the closure through `&self` but
it now requires invocation through `&mut self`.
The standard library has a good number of violations of this new rule, but the
fixes will be separated into multiple breaking change commits.
Closes#12224
[breaking-change]
The BSD builders are failing with a different error that is not a timeout error
(Connection reset by peer), so this test isn't really all that useful on
freebsd. Due to a lack of a better idea of how to test a connect timeout, this
test is going to just be ignored for now.
`@` pointers used to have special rooting and regions management. With `@`
moving to standalone library, we don't need to keep that special
treatment around. This patch modifies the way `@` pointers are treated by
treating them as if they were `~` pointers
Region checker and borrow checker were modified in this patch.
Closes#11586
[breaking-change]
The BSD builders are failing with a different error that is not a timeout error
(Connection reset by peer), so this test isn't really all that useful on
freebsd. Due to a lack of a better idea of how to test a connect timeout, this
test is going to just be ignored for now.
