These aren't in their final form, but are all aiming to be part of 1.0, so at the very least encouraging usage now to find the bugs is nice.
Also, the widespread roll-out of associated types in the standard library indicates they're getting good, and it's lame to have to activate a feature in essentially every crate ever.
`#[deriving]` has been changed to `#[derive]`, so we should update this lint accordingly so that it remains consistent with the language.
Also register the rename with the LintStore.
I've changed the one reference to `raw_pointer_deriving` that occurs in the tests (as well as renamed the file appropriately), but the rest of the `raw_pointer_deriving`s in the Rust codebase will need to wait for a snapshot to be changed because stage0 doesn't know about the new lint name. I'll take care of the remaining renaming after the next snapshot.
Closes#20498.
This commit is an implementation of [RFC 494][rfc] which removes the entire
`std::c_vec` module and redesigns the `std::c_str` module as `std::ffi`.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0494-c_str-and-c_vec-stability.md
The interface of the new `CString` is outlined in the linked RFC, the primary
changes being:
* The `ToCStr` trait is gone, meaning the `with_c_str` and `to_c_str` methods
are now gone. These two methods are replaced with a `CString::from_slice`
method.
* The `CString` type is now just a wrapper around `Vec<u8>` with a static
guarantee that there is a trailing nul byte with no internal nul bytes. This
means that `CString` now implements `Deref<Target = [c_char]>`, which is where
it gains most of its methods from. A few helper methods are added to acquire a
slice of `u8` instead of `c_char`, as well as including a slice with the
trailing nul byte if necessary.
* All usage of non-owned `CString` values is now done via two functions inside
of `std::ffi`, called `c_str_to_bytes` and `c_str_to_bytes_with_nul`. These
functions are now the one method used to convert a `*const c_char` to a Rust
slice of `u8`.
Many more details, including newly deprecated methods, can be found linked in
the RFC. This is a:
[breaking-change]
Closes#20444
The previous scheme made it possible for another user/attacker to cause the
temporary directory creation scheme to panic. All you needed to know was the pid
of the process you wanted to target ('other_pid') and the suffix it was using
(let's pretend it's 'sfx') and then code such as this would, in essence, DOS it:
for i in range(0u, 1001) {
let tp = &Path::new(format!("/tmp/rs-{}-{}-sfx", other_pid, i));
match fs::mkdir(tp, io::USER_RWX) { _ => () }
}
Since the scheme only 1000 times to create a temporary directory before dying,
the next time the attacked process called TempDir::new("sfx") after that would
typically cause a panic. Of course, you don't necessarily need an attacker to
cause such a DOS: creating 1000 temporary directories without closing any of the
previous would be enough to DOS yourself.
This patch broadly follows the OpenBSD implementation of mkstemp. It uses the
operating system's random number generator to produce random directory names
that are impractical to guess (and, just in case someone manages to do that, it
retries creating the directory for a long time before giving up; OpenBSD
retries INT_MAX times, although 1<<31 seems enough to thwart even the most
patient attacker).
As a small additional change while the file name is changing, this patch also
makes the argument that TempDir::new takes a prefix rather than a suffix.
This is because 1) it more closely matches what mkstemp and friends do 2)
if you're going to have a deterministic part of a filename, you really want it at
the beginning so that shell completion is useful.
* Implement (derive) `Clone` for `ChaChaRng`, `Isaac*Rng`, `StdRng` and `ThreadRng`;
* Derive `XorShiftRng` `Clone` implementation instead of implementing it explicitly.
`OsRng` is the only Rng which does not implement `Clone` or `Copy` after this patch because of its dependence on `Reader`.
r? @huonw I guess?
Treat associated types the same as type parameters when it comes to region bounding. Fixes#20303.
Strictly speaking, this is a [breaking-change] (if you are using
associated types). You are no longer free to wantonly violate the type
system rules by closing associated types into objects without any form
of region bound. Instead you should add region bounds like `T::X :
'a`, just as you would with a normal type parameter.
r? @aturon
Fixes#17904. All the cases that I believe we should support are detailed in the test case, let me know if there is there is any more desired behavior. cc @japaric.
r? @nikomatsakis or whoever is appropriate.
While talking on IRC, someone wanted to post a link to the Rust source code, but while the lines of the rendered source code do have anchors (`<span id="[line number]">`), there is no convenient way to make links as they are not clickable. This PR makes them clickable.
Also, a minor fix of the FAQ is included.
macro_rules! is like an item that defines a macro. Other items don't have a
trailing semicolon, or use a paren-delimited body.
If there's an argument for matching the invocation syntax, e.g. parentheses for
an expr macro, then I think that applies more strongly to the *inner*
delimiters on the LHS, wrapping the individual argument patterns.
