| Age | Commit message (Collapse) | Author | Lines |
|---|
|
compiletest: compact "linux" "macos" etc.as "unix".
liballoc: remove a superfluous "use".
libcollections: remove invocations of deprecated methods in favor of
their suggested replacements and use "_" for a loop counter.
libcoretest: remove invocations of deprecated methods; also add
"allow(deprecated)" for testing a deprecated method itself.
libglob: use "cfg_attr".
libgraphviz: add a test for one of data constructors.
libgreen: remove a superfluous "use".
libnum: "allow(type_overflow)" for type cast into u8 in a test code.
librustc: names of static variables should be in upper case.
libserialize: v[i] instead of get().
libstd/ascii: to_lowercase() instead of to_lower().
libstd/bitflags: modify AnotherSetOfFlags to use i8 as its backend.
It will serve better for testing various aspects of bitflags!.
libstd/collections: "allow(deprecated)" for testing a deprecated
method itself.
libstd/io: remove invocations of deprecated methods and superfluous "use".
Also add #[test] where it was missing.
libstd/num: introduce a helper function to effectively remove
invocations of a deprecated method.
libstd/path and rand: remove invocations of deprecated methods and
superfluous "use".
libstd/task and libsync/comm: "allow(deprecated)" for testing
a deprecated method itself.
libsync/deque: remove superfluous "unsafe".
libsync/mutex and once: names of static variables should be in upper case.
libterm: introduce a helper function to effectively remove
invocations of a deprecated method.
We still see a few warnings about using obsoleted native::task::spawn()
in the test modules for libsync. I'm not sure how I should replace them
with std::task::TaksBuilder and native::task::NativeTaskBuilder
(dependency to libstd?)
Signed-off-by: NODA, Kai <nodakai@gmail.com>
|
|
Also convert a number of `static mut` to just a plain old `static` and remove
some unsafe blocks.
|
|
Closes #17865
|
|
|
|
This change is an implementation of [RFC 69][rfc] which adds a third kind of
global to the language, `const`. This global is most similar to what the old
`static` was, and if you're unsure about what to use then you should use a
`const`.
The semantics of these three kinds of globals are:
* A `const` does not represent a memory location, but only a value. Constants
are translated as rvalues, which means that their values are directly inlined
at usage location (similar to a #define in C/C++). Constant values are, well,
constant, and can not be modified. Any "modification" is actually a
modification to a local value on the stack rather than the actual constant
itself.
Almost all values are allowed inside constants, whether they have interior
mutability or not. There are a few minor restrictions listed in the RFC, but
they should in general not come up too often.
* A `static` now always represents a memory location (unconditionally). Any
references to the same `static` are actually a reference to the same memory
location. Only values whose types ascribe to `Sync` are allowed in a `static`.
This restriction is in place because many threads may access a `static`
concurrently. Lifting this restriction (and allowing unsafe access) is a
future extension not implemented at this time.
* A `static mut` continues to always represent a memory location. All references
to a `static mut` continue to be `unsafe`.
This is a large breaking change, and many programs will need to be updated
accordingly. A summary of the breaking changes is:
* Statics may no longer be used in patterns. Statics now always represent a
memory location, which can sometimes be modified. To fix code, repurpose the
matched-on-`static` to a `const`.
static FOO: uint = 4;
match n {
FOO => { /* ... */ }
_ => { /* ... */ }
}
change this code to:
const FOO: uint = 4;
match n {
FOO => { /* ... */ }
_ => { /* ... */ }
}
* Statics may no longer refer to other statics by value. Due to statics being
able to change at runtime, allowing them to reference one another could
possibly lead to confusing semantics. If you are in this situation, use a
constant initializer instead. Note, however, that statics may reference other
statics by address, however.
* Statics may no longer be used in constant expressions, such as array lengths.
This is due to the same restrictions as listed above. Use a `const` instead.
[breaking-change]
Closes #17718
[rfc]: https://github.com/rust-lang/rfcs/pull/246
|
|
|
|
|
|
This reverts commit 2288f332301b9e22db2890df256322650a7f3445.
|
|
This commit repurposes most statics as constants in the standard library itself,
with the exception of TLS keys which precisely have their own memory location as
an implementation detail.
This commit also rewrites the bitflags syntax to use `const` instead of
`static`. All invocations will need to replace the word `static` with `const`
when declaring flags.
Due to the modification of the `bitflags!` syntax, this is a:
[breaking-change]
|
|
0.12.0 release
|
|
|
|
|
|
Adds a high-level discussion of "what collection should you use for what", as well as some general discussion of correct/efficient usage of the capacity, iterator, and entry APIs.
Still building docs to confirm this renders right and the examples are good, but the content can be reviewed now.
|
|
|
|
|
|
|
|
[breaking-change]
If you are using slicing syntax you will need to add #![feature(slicing_syntax)] to your crate.
|
|
|
|
|
|
|
|
|
|
For example, this renames `GroupRWX` to `GROUP_RWX`, and deprecates the old
name. Code using these statics should be updated accordingly.
|
|
Closes issue #17767
|
|
|
|
|
|
|
|
|
|
Conflicts:
src/libcollections/lib.rs
src/libcore/lib.rs
src/librustdoc/lib.rs
src/librustrt/lib.rs
src/libserialize/lib.rs
src/libstd/lib.rs
src/test/run-pass/issue-8898.rs
|
|
|
|
|
|
This test has recently been failing on the bots, and I'm not entirely sure why.
I haven't been able to reproduce locally or on the bots, so I'm adding some
messages to help diagnose the problem hopefully.
|
|
This reverts commit 40b9f5ded50ac4ce8c9323921ec556ad611af6b7.
|
|
This reverts commit 95cfc35607ccf5f02f02de56a35a9ef50fa23a82.
|
|
This reverts commit 6e0611a48707a1f5d90aee32a02b2b15957ef25b.
|
|
|
|
|
|
|
|
[breaking-change]
If you are using slicing syntax you will need to add #![feature(slicing_syntax)] to your crate.
|
|
|
|
The `std::io::signal` API was only implemented under `librustuv`, which
is now being removed. Rather than keep around an unimplemented API, this
commit removes it altogether.
See the [runtime removal
RFC](https://github.com/rust-lang/rfcs/pull/230) for more context.
See [green-rs](https://github.com/alexcrichton/green-rs/) for a possible
migration path for signal handling code, although in the long run we
plan to add native signal handling to `std::io`.
[breaking-change]
|
|
This commit removes the `iotest!` macro from `std::io`. The macro was
primarily used to ensure that all io-related tests were run on both
libnative and libgreen/librustuv. However, now that the librustuv stack
is being removed, the macro is no longer needed.
See the [runtime removal
RFC](https://github.com/rust-lang/rfcs/pull/230) for more context.
[breaking-change]
|
|
|
|
In some build environments (such as chrooted Nix builds), `env` can only
be found in the explicitly-provided PATH, not in default places such as
/bin or /usr/bin. So we need to pass-through PATH when spawning the
`env` sub-process.
Fixes #17617
|
|
|
|
Closes #17490
|
|
In some build environments (such as chrooted Nix builds), `env` can only
be found in the explicitly-provided PATH, not in default places such as
/bin or /usr/bin. So we need to pass-through PATH when spawning the
`env` sub-process.
Fixes #17617
|
|
|
|
This breaks code that looks like:
match foo {
1..3 => { ... }
}
Instead, write:
match foo {
1...3 => { ... }
}
Closes #17295.
[breaking-change]
|
|
This is the bare minimum to stop using split stacks on Windows, fixing https://github.com/rust-lang/rust/issues/13259 and #14742, by turning on stack probes for all functions and disabling compiler and runtime support for split stacks on Windows.
It does not restore the out-of-stack error message, which requires more runtime work.
This includes a test that the Windows TCB is no longer being clobbered, but the out-of-stack test itself is pretty weak, only testing that the program exits abnormally, not that it isn't writing to bogus memory, so I haven't truly verified that this is providing the safety we claim.
A more complete solution is in https://github.com/rust-lang/rust/pull/16388, which has some unresolved issues yet.
cc @Zoxc @klutzy @vadimcn
|
|
|
