| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Types that implement Deref can cause weird error messages due to their
private fields conflicting with a field of the type they deref to, e.g.,
previously
struct Foo { x: int }
let a: Arc<Foo> = ...;
println!("{}", a.x);
would complain the the `x` field of `Arc` was private (since Arc has a
private field called `x`) rather than just ignoring it.
This patch doesn't fix that issue, but does mean one would have to write
`a._ptr` to hit the same error message, which seems far less
common. (This patch `_`-prefixes all private fields of
`Deref`-implementing types.)
cc #12808
|
|
Some functions implemented for the Ascii struct have the same functionality as other functions implemented for the normal chars. For consistency, I think they should have the same name, so I renamed the functions in Ascii to match the names in the Char trait.
* Renamed `to_lower` to `to_lowercase`
* Renamed `to_upper` to `to_uppercase`
* Renamed `is_alpha` to `is_alphabetic`
* Renamed `is_alnum` to `is_alphanumeric`
* Renamed `is_lower` to `is_lowercase`
* Renamed `is_upper` to `is_uppercase`
[breaking-change]
|
|
Might as well remove the duplication/`forget` call.
|
|
On some systems (iOS for example) mutex is represented by opaque data structure which doesn't play well with simple data copy. Therefore mutex should be initialized from magic static value and filled by OS only when it landed RC.
Initially written for iOS but since landing iOS support might require quite a lot of time I think it is better to split parts which aren't directly related to iOS and merge them in
|
|
|
|
Some functions implemented for the Ascii struct have the same functionality as other functions implemented for the normal chars. For consistency, I think they should have the same name, so I renamed the functions in Ascii to match the names in the Char trait.
* Renamed `to_lower` to `to_lowercase`
* Renamed `to_upper` to `to_uppercase`
* Renamed `is_alpha` to `is_alphabetic`
* Renamed `is_alnum` to `is_alphanumeric`
* Renamed `is_lower` to `is_lowercase`
* Renamed `is_upper` to `is_uppercase`
[breaking-change]
|
|
* All of the *_val functions have gone from #[unstable] to #[stable]
* The overwrite and zeroed functions have gone from #[unstable] to #[stable]
* The uninit function is now deprecated, replaced by its stable counterpart,
uninitialized
[breaking-change]
|
|
On some systems (iOS for example) mutex is represented by
opaque data structure which doesn't play well with simple
data copy. Therefore mutex should be initialized from
magic static value and filled by OS only when it landed RC.
|
|
* All of the *_val functions have gone from #[unstable] to #[stable]
* The overwrite and zeroed functions have gone from #[unstable] to #[stable]
* The uninit function is now deprecated, replaced by its stable counterpart,
uninitialized
[breaking-change]
|
|
Followup to https://github.com/mozilla/rust/pull/14331 and https://github.com/mozilla/rust/pull/12524
|
|
[breaking-change]
|
|
[breaking-change]
|
|
[breaking-change]
|
|
|
|
|
|
|
|
These have all been deprecated for awhile now, so it's likely time to start removing them.
|
|
|
|
The span on a inner doc-comment would point to the next token, e.g. the span for the `a` line points to the `b` line, and the span of `b` points to the `fn`.
```rust
//! a
//! b
fn bar() {}
```
|
|
One of the long-term goals of the libstd facade is to move the collections
library underneath the standard library. This would imply that libcollections
today would invert its dependency with libstd.
One of the primary blockers for doing this is the HashMap collection. Of its two
major dependencies, hashing and randomness, this commit is the first step in
dealing with hashing.
When moving the hash module beneath libstd, it must break its primary dependence
on the io::Writer trait (used as the hashing state). The proposed strategy for
breaking this dependence is taking a similar path as core::fmt, which is to have
the hash module define its own "writer trait". This trait would be similar to
std::io::Writer, except that it would not return errors and it would have fewer
convenience methods.
The Hash trait today has its type parameter behind a feature gate (default type
parameters), so this pending change will likely break no code which hasn't opted
in to the feature gate. The SipState struct will lose its implementation of
io::Writer, but it will regain similar methods for dealing with writing data.
This change specifically prepares for the hash migration by modifying
deriving(Hash) to use the std::hash::Writer bound instead of the std::io::Writer
bound. This bound is currently wired to std::io::Writer, but after a snapshot it
will have no need to be wired to the io writer trait.
|
|
|
|
[breaking-change]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add slice::MutableCloneableVector to the prelude. It's the only slice
trait that's currently missing.
Update rust.vim to match the latest prelude and current set of keywords.
Also teach it to handle box placement expressions specially.
|
|
The new documentation site has shorter urls, gzip'd content, and index.html
redirecting functionality.
|
|
This type can be built with `Arc<Unsafe<T>>` now that liballoc exists.
|
|
|
|
This is now only used internally by the compiler.
|
|
One of the long-term goals of the libstd facade is to move the collections
library underneath the standard library. This would imply that libcollections
today would invert its dependency with libstd.
One of the primary blockers for doing this is the HashMap collection. Of its two
major dependencies, hashing and randomness, this commit is the first step in
dealing with hashing.
When moving the hash module beneath libstd, it must break its primary dependence
on the io::Writer trait (used as the hashing state). The proposed strategy for
breaking this dependence is taking a similar path as core::fmt, which is to have
the hash module define its own "writer trait". This trait would be similar to
std::io::Writer, except that it would not return errors and it would have fewer
convenience methods.
The Hash trait today has its type parameter behind a feature gate (default type
parameters), so this pending change will likely break no code which hasn't opted
in to the feature gate. The SipState struct will lose its implementation of
io::Writer, but it will regain similar methods for dealing with writing data.
This change specifically prepares for the hash migration by modifying
deriving(Hash) to use the std::hash::Writer bound instead of the std::io::Writer
bound. This bound is currently wired to std::io::Writer, but after a snapshot it
will have no need to be wired to the io writer trait.
|
|
StdWriter has .isatty(). StdReader can trivially vend the same function,
and someone asked today on IRC how to call isatty() on stdin.
|
|
Excluding the functions inherited from the cast module last week (with marked
stability levels), these functions received the following treatment.
* size_of - this method has become #[stable]
* nonzero_size_of/nonzero_size_of_val - these methods have been removed
* min_align_of - this method is now #[stable]
* pref_align_of - this method has been renamed without the
`pref_` prefix, and it is the "default alignment" now. This decision is in line
with what clang does (see url linked in comment on function). This function
is now #[stable].
* init - renamed to zeroed and marked #[stable]
* uninit - marked #[stable]
* move_val_init - renamed to overwrite and marked #[stable]
* {from,to}_{be,le}{16,32,64} - all functions marked #[stable]
* swap/replace/drop - marked #[stable]
* size_of_val/min_align_of_val/align_of_val - these functions are marked
#[unstable], but will continue to exist in some form. Concerns have been
raised about their `_val` prefix.
|
|
Excluding the functions inherited from the cast module last week (with marked
stability levels), these functions received the following treatment.
* size_of - this method has become #[stable]
* nonzero_size_of/nonzero_size_of_val - these methods have been removed
* min_align_of - this method is now #[stable]
* pref_align_of - this method has been renamed without the
`pref_` prefix, and it is the "default alignment" now. This decision is in line
with what clang does (see url linked in comment on function). This function
is now #[stable].
* init - renamed to zeroed and marked #[stable]
* uninit - marked #[stable]
* move_val_init - renamed to overwrite and marked #[stable]
* {from,to}_{be,le}{16,32,64} - all functions marked #[stable]
* swap/replace/drop - marked #[stable]
* size_of_val/min_align_of_val/align_of_val - these functions are marked
#[unstable], but will continue to exist in some form. Concerns have been
raised about their `_val` prefix.
[breaking-change]
|
|
This commit is part of the ongoing libstd facade efforts (cc #13851). The
compiler now recognizes some language items as "extern { fn foo(...); }" and
will automatically perform the following actions:
1. The foreign function has a pre-defined name.
2. The crate and downstream crates can only be built as rlibs until a crate
defines the lang item itself.
3. The actual lang item has a pre-defined name.
This is essentially nicer compiler support for the hokey
core-depends-on-std-failure scheme today, but it is implemented the same way.
The details are a little more hidden under the covers.
In addition to failure, this commit promotes the eh_personality and
rust_stack_exhausted functions to official lang items. The compiler can generate
calls to these functions, causing linkage errors if they are left undefined. The
checking for these items is not as precise as it could be. Crates compiling with
`-Z no-landing-pads` will not need the eh_personality lang item, and crates
compiling with no split stacks won't need the stack exhausted lang item. For
ease, however, these items are checked for presence in all final outputs of the
compiler.
It is quite easy to define dummy versions of the functions necessary:
#[lang = "stack_exhausted"]
extern fn stack_exhausted() { /* ... */ }
#[lang = "eh_personality"]
extern fn eh_personality() { /* ... */ }
cc #11922, rust_stack_exhausted is now a lang item
cc #13851, libcollections is blocked on eh_personality becoming weak
|
|
StdWriter has .isatty(). StdReader can trivially vend the same function,
and someone asked today on IRC how to call isatty() on stdin.
|
|
Only an example was needed, as the ability to write uints into the string is
already mentioned.
Fix #7102.
|
|
Only an example was needed, as the ability to write uints into the string is
already mentioned.
Fix #7102.
|
|
Every other trait in slice is in the prelude, so it makes sense to
provide MutableCloneableVector as well.
|
|
|
|
|
|
|
|
This type has been superseded by Arc<Unsafe<T>>. The UnsafeArc type is a relic
of an era that has long since past, and with the introduction of liballoc the
standard library is able to use the Arc smart pointer. With little need left for
UnsafeArc, it was removed.
All existing code using UnsafeArc should either be reevaluated to whether it can
use only Arc, or it should transition to Arc<Unsafe<T>>
[breaking-change]
|
|
They currently still use `&mut self`, this migration was aimed towards moving
from UnsafeArc<T> to Arc<Unsafe<T>>
|
|
This removes the usage of UnsafeArc
|
|
|
|
This removes the incorrect usage of `&mut self` in a concurrent setting.
|
