According to [RFC 344][], methods that return `&[u8]` should have names
ending in `bytes`. Though `include_bin!` is a macro not a method, it
seems reasonable to follow the convention anyway.
We keep the old name around for now, but trigger a deprecation warning
when it is used.
[RFC 344]: https://github.com/rust-lang/rfcs/blob/master/text/0344-conventions-galore.md
[breaking-change]
The current indentation level would indicate that Boolean literals are on the same level as Integer and Float literals under Number literals, unindenting moves it to the same scope as Character and string literals, Byte and byte string literals, and Number literals under Literals.
I was reading through the Rust Guide (hopefully looking to learn some Rust), and I figured it would be a good idea to open a pull request with some of the errata I noticed along the way. Most of the changes are pretty mundane, but there are a couple that might raise a bit of discussion.
### Punctuation outside of 'key term' quotes
This is something that was inconsistent in the Guide. While the convention in American English is to place punctuation immediately following a quotation mark *inside* the quotation mark, it seems strange to do this with 'key terms', considering they are not a true quotation.
### Changed comment placement in 17.2 code block
This is what the code block in [17.2 — Ownership, borrowing, and lifetimes](http://doc.rust-lang.org/guide.html#ownership,-borrowing,-and-lifetimes) looks like in fullscreened Safari 8:
Some of the comments extend *just* too far, causing them to bleed into the next line, so I moved a few of them above the relevant lines of code to avoid this.
- Various grammatical changes
- Place punctuation outside of key term quotes
- Change comment placement in 17.2 code block
- Replace double hyphens with en dashes
This commit is part of a series that introduces a `std::thread` API to
replace `std::task`.
In the new API, `spawn` returns a `JoinGuard`, which by default will
join the spawned thread when dropped. It can also be used to join
explicitly at any time, returning the thread's result. Alternatively,
the spawned thread can be explicitly detached (so no join takes place).
As part of this change, Rust processes now terminate when the main
thread exits, even if other detached threads are still running, moving
Rust closer to standard threading models. This new behavior may break code
that was relying on the previously implicit join-all.
In addition to the above, the new thread API also offers some built-in
support for building blocking abstractions in user space; see the module
doc for details.
Closes#18000
[breaking-change]
The current indentation level would indicate that Boolean literals are on the same level as Integer and Float literals under Number literals, unindenting moves it to the same scope as Character and string literals, Byte and byte string literals, and Number literals under Literals.
followed by a semicolon.
This allows code like `vec![1i, 2, 3].len();` to work.
This breaks code that uses macros as statements without putting
semicolons after them, such as:
fn main() {
...
assert!(a == b)
assert!(c == d)
println(...);
}
It also breaks code that uses macros as items without semicolons:
local_data_key!(foo)
fn main() {
println("hello world")
}
Add semicolons to fix this code. Those two examples can be fixed as
follows:
fn main() {
...
assert!(a == b);
assert!(c == d);
println(...);
}
local_data_key!(foo);
fn main() {
println("hello world")
}
RFC #378.
Closes#18635.
[breaking-change]
In US english, "that" is used in restrictive clauses in place of
"which", and often affects the meaning of sentences.
In UK english and many dialects, no distinction is
made.
While Rust devs want to avoid unproductive pedanticism, it is worth at
least being uniform in documentation such as:
http://doc.rust-lang.org/std/iter/index.html
and also in cases where correct usage of US english clarifies the
sentence.
- Change long inline code to code block
- Replace double-hyphens with en dash
- Miscellaneous rephrasings for clarity
**Edit**: Trivial `commit --amend` to change the commit message slightly.
This is a revival of #19517 (per request of @alexcrichton) now that the new snapshots have landed. We can now remove the last feature gates for if_let, while_let, and tuple_indexing scattered throughout the test sources since these features have been added to Rust.
Closes#19473.
In US english, "that" is used in restrictive clauses in place of
"which", and often affects the meaning of sentences.
In UK english and many dialects, no distinction is
made.
While Rust devs want to avoid unproductive pedanticism, it is worth at
least being uniform in documentation such as:
http://doc.rust-lang.org/std/iter/index.html
and also in cases where correct usage of US english clarifies the
sentence.
This change makes the compiler no longer infer whether types (structures
and enumerations) implement the `Copy` trait (and thus are implicitly
copyable). Rather, you must implement `Copy` yourself via `impl Copy for
MyType {}`.
A new warning has been added, `missing_copy_implementations`, to warn
you if a non-generic public type has been added that could have
implemented `Copy` but didn't.
For convenience, you may *temporarily* opt out of this behavior by using
`#![feature(opt_out_copy)]`. Note though that this feature gate will never be
accepted and will be removed by the time that 1.0 is released, so you should
transition your code away from using it.
This breaks code like:
#[deriving(Show)]
struct Point2D {
x: int,
y: int,
}
fn main() {
let mypoint = Point2D {
x: 1,
y: 1,
};
let otherpoint = mypoint;
println!("{}{}", mypoint, otherpoint);
}
Change this code to:
#[deriving(Show)]
struct Point2D {
x: int,
y: int,
}
impl Copy for Point2D {}
fn main() {
let mypoint = Point2D {
x: 1,
y: 1,
};
let otherpoint = mypoint;
println!("{}{}", mypoint, otherpoint);
}
This is the backwards-incompatible part of #13231.
Part of RFC #3.
[breaking-change]
The test harness will make sure that the panic message contains the
specified string. This is useful to help make `#[should_fail]` tests a
bit less brittle by decreasing the chance that the test isn't
"accidentally" passing due to a panic occurring earlier than expected.
The behavior is in some ways similar to JUnit's `expected` feature:
`@Test(expected=NullPointerException.class)`.
Without the message assertion, this test would pass even though it's not
actually reaching the intended part of the code:
```rust
#[test]
#[should_fail(message = "out of bounds")]
fn test_oob_array_access() {
let idx: uint = from_str("13o").unwrap(); // oops, this will panic
[1i32, 2, 3][idx];
}
```
In regards to:
https://github.com/rust-lang/rust/issues/19253#issuecomment-64836729
This commit:
* Changes the #deriving code so that it generates code that utilizes fewer
reexports (in particur Option::* and Result::*), which is necessary to
remove those reexports in the future
* Changes other areas of the codebase so that fewer reexports are utilized
Using `and` here instead of `but` sounds better to me, as but makes it sound like an item which is still under active development shouldn't normally require more testing, but this one does - or something like that :-)
@steveklabnik?
This is a work in progress, but this should get *extensive* review, so I'm putting it up early and often.
This is the start of a draft of the new 'ownership guide,' which explains ownership, borrowing, etc. I'm feeling better about this framing than last time's, but we'll see.
The "Returning Pointers" section of the pointers guide broke from the convention of putting code between backticks. This PR fixes that. There's also a little trailing whitespace I took care of.
