| Age | Commit message (Collapse) | Author | Lines |
|
These were intended to land in stable 1.8 but were just waiting for the
implementation PR, so now they're landing. Specifically this PR stabilizes:
* `AsciiExt::into_ascii_uppercase`
* `AsciiExt::into_ascii_lowercase`
* `AsciiExt for Vec<u8>`
* `AsciiExt for String`
|
|
This PR implements [RFC 1192](https://github.com/rust-lang/rfcs/blob/master/text/1192-inclusive-ranges.md), which is triple-dot syntax for inclusive range expressions. The new stuff is behind two feature gates (one for the syntax and one for the std::ops types). This replaces the deprecated functionality in std::iter. Along the way I simplified the desugaring for all ranges.
This is my first contribution to rust which changes more than one character outside of a test or comment, so please review carefully! Some of the individual commit messages have more of my notes. Also thanks for putting up with my dumb questions in #rust-internals.
- For implementing `std::ops::RangeInclusive`, I took @Stebalien's suggestion from https://github.com/rust-lang/rfcs/pull/1192#issuecomment-137864421. It seemed to me to make the implementation easier and increase type safety. If that stands, the RFC should be amended to avoid confusion.
- I also kind of like @glaebhoerl's [idea](https://github.com/rust-lang/rfcs/pull/1254#issuecomment-147815299), which is unified inclusive/exclusive range syntax something like `x>..=y`. We can experiment with this while everything is behind a feature gate.
- There are a couple of FIXMEs left (see the last commit). I didn't know what to do about `RangeArgument` and I haven't added `Index` impls yet. Those should be discussed/finished before merging.
cc @Gankro since you [complained](https://www.reddit.com/r/rust/comments/3xkfro/what_happened_to_inclusive_ranges/cy5j0yq)
cc #27777 #30877 rust-lang/rust#1192 rust-lang/rfcs#1254
relevant to #28237 (tracking issue)
|
|
These targets don't link statically to libunwind or libc
---
r? @alexcrichton
|
|
I have these tagged as stable in 1.9, so this shouldn't merge until the 1.8 beta's cut.
|
|
These targets don't link statically to libunwind or libc
|
|
|
|
These were intended to land in stable 1.8 but were just waiting for the
implementation PR, so now they're landing. Specifically this PR stabilizes:
* `AsciiExt::into_ascii_uppercase`
* `AsciiExt::into_ascii_lowercase`
* `AsciiExt for Vec<u8>`
* `AsciiExt for String`
|
|
|
|
|
|
r=alexcrichton
Was getting error:
```
running: "sh" "/home/flubba86/rust/src/libstd/../libbacktrace/configure" "--with-pic" "--disable-multilib" "--disable-shared" "--disable-host-shared" "--host=asmjs-unknown-emscripten" "--build=x86_64-unknown-linux-gnu"
...
Invalid configuration `asmjs-unknown-emscripten': system `emscripten' not recognized
```
This commit adds the emscripten target to the libbacktrace configure script so it is no longer unrecognized.
|
|
These types were already `!Sync`, but this improves error messages when they are used in contexts that require `Sync`, aligning them with conventions used with `Rc`, among others.
r? @alexcrichton
|
|
Was getting error:
```
running: "sh" "/home/flubba86/rust/src/libstd/../libbacktrace/configure" "--with-pic" "--disable-multilib" "--disable-shared" "--disable-host-shared" "--host=asmjs-unknown-emscripten" "--build=x86_64-unknown-linux-gnu"
...
Invalid configuration `asmjs-unknown-emscripten': system `emscripten' not recognized
```
Undo change to libbacktrace configure script.
Modify libstd build.rs to not build libbacktrace in the case of targeting emscripten.
|
|
These types were already `!Sync`, but this improves error messages when
they are used in contexts that require `Sync`, aligning them with
conventions used with `Rc`, among others.
|
|
The default implementations (with `where Self: Sized`) are so that methods that take `self` by value can exist in a trait that’s implemented for dynamically-sized types (`str` and `[u8]`).
CC https://github.com/rust-lang/rust/issues/27809#issuecomment-177564950
CC @alexcrichton
|
|
This commit is the result of the FCPs ending for the 1.8 release cycle for both
the libs and the lang suteams. The full list of changes are:
Stabilized
* `braced_empty_structs`
* `augmented_assignments`
* `str::encode_utf16` - renamed from `utf16_units`
* `str::EncodeUtf16` - renamed from `Utf16Units`
* `Ref::map`
* `RefMut::map`
* `ptr::drop_in_place`
* `time::Instant`
* `time::SystemTime`
* `{Instant,SystemTime}::now`
* `{Instant,SystemTime}::duration_since` - renamed from `duration_from_earlier`
* `{Instant,SystemTime}::elapsed`
* Various `Add`/`Sub` impls for `Time` and `SystemTime`
* `SystemTimeError`
* `SystemTimeError::duration`
* Various impls for `SystemTimeError`
* `UNIX_EPOCH`
* `ops::{Add,Sub,Mul,Div,Rem,BitAnd,BitOr,BitXor,Shl,Shr}Assign`
Deprecated
* Scoped TLS (the `scoped_thread_local!` macro)
* `Ref::filter_map`
* `RefMut::filter_map`
* `RwLockReadGuard::map`
* `RwLockWriteGuard::map`
* `Condvar::wait_timeout_with`
Closes #27714
Closes #27715
Closes #27746
Closes #27748
Closes #27908
Closes #29866
|
|
Also, `path` seems better than `p`
|
|
Also back out keepalive support for TCP since the API is perhaps not
actually what we want. You can't read the interval on Windows, and
we should probably separate the functionality of turning keepalive on
and overriding the interval.
|
|
|
|
|
|
Also, `path` seems better than `p`
|
|
|
|
Since it removes the old iter::{range_inclusive, RangeInclusive} which
were unstable and deprecated, this is a [breaking-change] on nightly.
|
|
r? @steveklabnik
Fixes #29334
|
|
Use .copy_from_slice() where applicable
.copy_from_slice() does the same job of .clone_from_slice(), but the
former is explicitly for Copy elements and calls `memcpy` directly, and
thus is it efficient without optimization too.
|
|
CryptGenRandom takes a DWORD (u32) for the length so it only supports
writing u32::MAX bytes at a time.
Casting the length from a usize caused truncation meaning the whole
buffer was not always filled.
cc #31841
This is the same as rust-lang-nursery/rand#99. I think it's a good idea to keep the implementations in sync.
r? @alexcrichton
|
|
Similar to #31825 where the read/write limits were capped for files, this
implements similar limits when reading/writing networking types. On Unix this
shouldn't affect anything because the write size is already a `usize`, but on
Windows this will cap the read/write amounts to `i32::max_value`.
cc #31841
|
|
.copy_from_slice() does the same job of .clone_from_slice(), but the
former is explicitly for Copy elements and calls `memcpy` directly, and
thus is it efficient without optimization too.
|
|
|
|
Make sure formatter errors are emitted by the default Write::write_fmt
Previously, if an error was returned from the formatter that did not
originate in an underlying writer error, Write::write_fmt would return
successfully even if the formatting did not complete (was interrupted by
an `fmt::Error` return).
Now we choose to emit an io::Error with kind Other for formatter errors.
Since this may reveal error returns from `write!()` and similar that
previously passed silently, it's a kind of a [breaking-change].
Fixes #31879
|
|
|
|
|
|
|
|
None
|
|
Previously, if an error was returned from the formatter that did not
originate in an underlying writer error, Write::write_fmt would return
successfully even if the formatting did not complete (was interrupted by
an `fmt::Error` return).
Now we choose to emit an io::Error with kind Other for formatter errors.
Since this may reveal error returns from `write!()` and similar that
previously passed silently, it's a kind of a [breaking-change].
|
|
|
|
|
|
|
|
|
|
This PR changes the visibility of extern crate declarations to match that of items (fixes #26775).
To avoid breakage, the PR makes it a `public_in_private` lint to reexport a private extern crate, and it adds the lint `inaccessible_extern_crate` for uses of an inaccessible extern crate.
The lints can be avoided by making the appropriate `extern crate` declaration public.
|
|
|
|
|
|
CryptGenRandom takes a DWORD (u32) for the length so it only supports
writing u32::MAX bytes at a time.
Casting the length from a usize caused truncation meaning the whole
buffer was not always filled.
|
|
fixes #29332
r? @steveklabnik
|
|
I have made changes and built it after that. Please advise,
https://github.com/rust-lang/rust/issues/31820
|
|
Similar to #31825 where the read/write limits were capped for files, this
implements similar limits when reading/writing networking types. On Unix this
shouldn't affect anything because the write size is already a `usize`, but on
Windows this will cap the read/write amounts to `i32::max_value`.
cc #31841
|
|
I am not entirely sure I have got everything right, but if it compiles it is ok probably...
I tested it with msvc x86_64 and gnu.
Somehow a lot of `EXCEPTION-*` constants are dead code when running test, no idea why.
I have put `#![cfg_attr(test, allow(dead_code))]` at the top for this.
|
|
r? @alexcrichton
|
|
|
|
I'm a bit iffy on the return type, but `Result` would also be a bit weird... The two error cases are `Unterminated` and `InteriorNul(usize)`.
I considered `from_chars(&[c_char])` but this meshes better with `as_bytes_with_nul()` and Rust code in general.
Should there also be a corresponding unsafe `from_bytes_unchecked` variant?
|
|
|