| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This commit standardizes the codebase on `iter` for parameters with
IntoIterator bounds.
Previously about 40% of IntoIterator parameters were named `iterable`,
with most of the rest being named `iter`. There was a single place where
it was named `iterator`.
|
|
Fix missing console output in `Barrier` example
The `println!` calls in the previous version were never shown (at least
not in the playpen) because the main thread is finished before all the
spawned child threads were synchronized. This commit adds a join for
each thread handle to wait in the main thread until all child threads
are finished.
r? @steveklabnik
|
|
|
|
libstd/sys/*/net: clean up API error checks.
1. Slightly improve `cvt_gai()` and `cvt()`.
2. Remove now redundant `cvt_r()`.
|
|
This adds checks to ensure that:
* link anchors refer to existing id's on the target page
* id's are unique within an html document
* page redirects are valid
|
|
std: Rewrite Once with poisoning
This commit rewrites the `std::sync::Once` primitive with poisoning in mind in
light of #31688. Currently a panic in the initialization closure will cause
future initialization closures to run, but the purpose of a Once is usually to
initialize some global state so it's highly likely that the global state is
corrupt if a panic happened. The same strategy of a mutex is taken where a panic
is propagated by default.
A new API, `call_once_force`, was added to subvert panics like is available on
Mutex as well (for when panicking is handled internally).
Adding this support was a significant enough change to the implementation that
it was just completely rewritten from scratch, primarily to avoid using a
`StaticMutex` which needs to have `destroy()` called on it at some point (a pain
to do).
Closes #31688
|
|
Signed-off-by: NODA, Kai <nodakai@gmail.com>
|
|
This commit rewrites the `std::sync::Once` primitive with poisoning in mind in
light of #31688. Currently a panic in the initialization closure will cause
future initialization closures to run, but the purpose of a Once is usually to
initialize some global state so it's highly likely that the global state is
corrupt if a panic happened. The same strategy of a mutex is taken where a panic
is propagated by default.
A new API, `call_once_force`, was added to subvert panics like is available on
Mutex as well (for when panicking is handled internally).
Adding this support was a significant enough change to the implementation that
it was just completely rewritten from scratch, primarily to avoid using a
`StaticMutex` which needs to have `destroy()` called on it at some point (a pain
to do).
Closes #31688
|
|
std: Add regression test for #32074
Just to make sure we don't accidentally break this in the future.
|
|
The `println!` calls in the previous version were never shown (at least
not in the playpen) because the main thread is finished before all the
spawned child threads were synchronized. This commit adds a join for
each thread handle to wait in the main thread until all child threads
are finished.
|
|
|
|
Fix unsound behaviour with null characters in thread names (issue #32475)
Previously, the thread name (&str) was converted to a CString in the
new thread, but outside unwind::try, causing a panic to continue into FFI.
This patch changes that behaviour, so that the panic instead happens
in the parent thread (where panic infrastructure is properly set up),
not the new thread.
This could potentially be a breaking change for architectures who don't
support thread names.
|
|
Add augmented assignment operator impls for time types
r? @alexcrichton
|
|
std: Fix inheriting stdin on status()
This regression was accidentally introduced in #31618, and it's just flipping a
boolean!
Closes #32254
|
|
r=pnkfelix
Restrict constants in patterns
This implements [RFC 1445](https://github.com/rust-lang/rfcs/blob/master/text/1445-restrict-constants-in-patterns.md). The primary change is to limit the types of constants used in patterns to those that *derive* `Eq` (note that implementing `Eq` is not sufficient). This has two main effects:
1. Floating point constants are linted, and will eventually be disallowed. This is because floating point constants do not implement `Eq` but only `PartialEq`. This check replaces the existing special case code that aimed to detect the use of `NaN`.
2. Structs and enums must derive `Eq` to be usable within a match.
This is a [breaking-change]: if you encounter a problem, you are most likely using a constant in an expression where the type of the constant is some struct that does not currently implement
`Eq`. Something like the following:
```rust
struct SomeType { ... }
const SOME_CONST: SomeType = ...;
match foo {
SOME_CONST => ...
}
```
The easiest and most future compatible fix is to annotate the type in question with `#[derive(Eq)]` (note that merely *implementing* `Eq` is not enough, it must be *derived*):
```rust
struct SomeType { ... }
const SOME_CONST: SomeType = ...;
match foo {
SOME_CONST => ...
}
```
Another good option is to rewrite the match arm to use an `if` condition (this is also particularly good for floating point types, which implement `PartialEq` but not `Eq`):
```rust
match foo {
c if c == SOME_CONST => ...
}
```
Finally, a third alternative is to tag the type with `#[structural_match]`; but this is not recommended, as the attribute is never expected to be stabilized. Please see RFC #1445 for more details.
cc https://github.com/rust-lang/rust/issues/31434
r? @pnkfelix
|
|
std: Link to gcc_s on NetBSD
Currently the nightlies we're producing fail when linking some C code into a
Rust application with the error message:
libgcc_s.so.1: error adding symbols: DSO missing from command line
By linking `gcc_s` instead of `gcc` this error goes away. I haven't tested this
on NetBSD itself, but should help get the Linux cross-compile image moreso up
and working!
|
|
|
|
Previously, the thread name (&str) was converted to a CString in the
new thread, but outside unwind::try, causing a panic to continue into FFI.
This patch changes that behaviour, so that the panic instead happens
in the parent thread (where panic infrastructure is properly set up),
not the new thread.
This could potentially be a breaking change for architectures who don't
support thread names.
Signed-off-by: David Henningsson <diwic@ubuntu.com>
|
|
Add code examples for libstd/time
Fixes #29379.
r? @steveklabnik
|
|
doc: Stdin is not writable
|
|
|
|
Rollup of 11 pull requests
- Successful merges: #32404, #32420, #32423, #32425, #32429, #32430, #32431, #32434, #32437, #32441, #32443
- Failed merges:
|
|
doc: small char improvements
|
|
std: Store flowinfo/scope_id in host byte order
Apparently these aren't supposed to be stored in network byte order, so doing so
ends up causing failures when it would otherwise succeed when stored in the host
byte order.
Closes #32424
|
|
Implement Default trait for OsString/OsStr
Fixes #32385
|
|
convert 99.9% of `try!`s to `?`s
The first commit is an automated conversion using the [untry] tool and the following command:
```
$ find -name '*.rs' -type f | xargs untry
```
at the root of the Rust repo.
[untry]: https://github.com/japaric/untry
cc @rust-lang/lang @alexcrichton @brson
|
|
|
|
|
|
Basic refactoring of HashMap
|
|
|
|
|
|
|
|
Automated conversion using the untry tool [1] and the following command:
```
$ find -name '*.rs' -type f | xargs untry
```
at the root of the Rust repo.
[1]: https://github.com/japaric/untry
|
|
Currently these have non-traditional APIs which take a buffer and report how
much was filled in, but they're not necessarily ergonomic to use. Returning an
iterator which *also* exposes an underlying slice shouldn't result in any
performance loss as it's just a lazy version of the same implementation, and
it's also much more ergonomic!
cc #27784
|
|
Apparently these aren't supposed to be stored in network byte order, so doing so
ends up causing failures when it would otherwise succeed when stored in the host
byte order.
Closes #32424
|
|
Since I changed no_run to should_panic on some tests, the were run but
two lacked an actual assertion. Further, I missed to check the return
type on another test.
|
|
|
|
|
|
|
|
|
|
|
|
Currently the nightlies we're producing fail when linking some C code into a
Rust application with the error message:
libgcc_s.so.1: error adding symbols: DSO missing from command line
By linking `gcc_s` instead of `gcc` this error goes away. I haven't tested this
on NetBSD itself, but should help get the Linux cross-compile image moreso up
and working!
|
|
|
|
|
|
- All Rust Doc tests execute the same command `/bin/cat file.txt` which
`should_panic` on all platforms consistently, because either
`/bin/cat` or `file.txt` do not exist.
|
|
Just to make sure we don't accidentally break this in the future.
|
|
|
|
|
|
std: Revert addition of `into_ascii_*` methods
The addition of these methods in #31335 required adding impls of the trait for
the `String` and `Vec<T>` types. This unfortunately caused a regression (#32074)
in type inference for using these methods which the libs team has decided to not
push forward with. These methods were stabilized in #32020 which was intended to
get backported to beta, but the backport hasn't happened just yet. This commit
reverts both the addition and stabilization of these methods.
One proposed method of handling this, in #32076, was to move the methods to an
extra trait to avoid conflicts with type inference. After some discussion,
however, the libs team concluded that we probably want to reevaluate what we're
doing here, so discussion will continue on the tracking issue, #27809.
Closes #32074
|
|
Make AssertRecoverSafe's field public
It's basically the very definition of a newtype, so we might as well
make things easy on people and let them construct and access it
directly.
r? @aturon
|
