This leaves the `Share` trait at `std::kinds` via a `#[deprecated]` `pub use`
statement, but the `NoShare` struct is no longer part of `std::kinds::marker`
due to #12660 (the build cannot bootstrap otherwise).
All code referencing the `Share` trait should now reference the `Sync` trait,
and all code referencing the `NoShare` type should now reference the `NoSync`
type. The functionality and meaning of this trait have not changed, only the
naming.
Closes#16281
[breaking-change]
This leaves the `Share` trait at `std::kinds` via a `#[deprecated]` `pub use`
statement, but the `NoShare` struct is no longer part of `std::kinds::marker`
due to #12660 (the build cannot bootstrap otherwise).
All code referencing the `Share` trait should now reference the `Sync` trait,
and all code referencing the `NoShare` type should now reference the `NoSync`
type. The functionality and meaning of this trait have not changed, only the
naming.
Closes#16281
[breaking-change]
The reference manual said that code is interpreted as UTF-8 text and a implementation will normalize it to NFKC. However, rustc doesn't do any normalization now.
We may want to do any normalization for symbols, but normalizing whole text seems harmful because doing so loses some sort of information even if we choose a non-K variant of normalization.
I'd suggest removing "normalized to Unicode normalization form NFKC" phrase for the present so that the manual represents the current state properly. When we address the problem (with a RFC?), then the manual should be updated.
Closes#12388.
Reference: https://github.com/rust-lang/rust/issues/2253
The reference manual said that code is interpreted as UTF-8 text and a
implementation will normalize it to NFKC. However, rustc doesn't do
any normalization now.
We may want to do any normalization for symbols, but normalizing whole
text seems harmful because doing so loses some sort of information even
if we choose a non-K variant of normalization.
I'd suggest removing "normalized to Unicode normalization form NFKC"
phrase for the present so that the manual represents the current state
properly. When we address the problem (with a RFC?), then the manual
should be updated.
Closes#12388.
Reference: https://github.com/rust-lang/rust/issues/2253
Signed-off-by: OGINO Masanori <masanori.ogino@gmail.com>
This is the next section of the guide, and it's on pointers. It's not done yet, as I need to write the section on ownership and borrowing, but I figured I'd share the rest now, to get feedback on the rest of it while I take some time to get that right.
The start of a testing guide. This PR relies on the crates and modules one because I shuffled some stuff around, so sorry about that.
I got stuck with how to import this name with cargo. @wycats and @alexcrichton , any ideas?
This is an alternative to upgrading the way rvalues are handled in the
borrow check. Making rvalues handled more like lvalues in the borrow
check caused numerous problems related to double mutable borrows and
rvalue scopes. Rather than come up with more borrow check rules to try
to solve these problems, I decided to just forbid pattern bindings after
`@`. This affected fewer than 10 lines of code in the compiler and
libraries.
This breaks code like:
match x {
y @ z => { ... }
}
match a {
b @ Some(c) => { ... }
}
Change this code to use nested `match` or `let` expressions. For
example:
match x {
y => {
let z = y;
...
}
}
match a {
Some(c) => {
let b = Some(c);
...
}
}
Closes#14587.
[breaking-change]
Not included are two required patches:
* LLVM: segmented stack support for DragonFly [1]
* jemalloc: simple configure patches
[1]: http://reviews.llvm.org/D4705
Not included are two required patches:
* LLVM: segmented stack support for DragonFly [1]
* jemalloc: simple configure patches
[1]: http://reviews.llvm.org/D4705
This is super, super WIP, but I'm going to go get lunch for a while, and figured I'd toss my work up here in case anyone wants to see my work as I do it.
This contains a new introductory section explaining the basics of pointers, and some pitfalls that Rust attempts to solve. I'd be interested in hearing how my explanation is, as well as if this belongs here. Pointers are such a crucial concept, I don't mind having a beginners' section on them in the main docs, even though our main audience is supposed to understand them already. Reasonable people may disagree, however.
The translation is based on an early version of tutorial.md, thus most
of entries have been marked as fuzzy and actually they are incorrect.
Now tutorial.md is planed to be replaced with guide.md, so I'd suggest
removing translation files for a while.
/cc @gifnksm
The translation is based on an early version of tutorial.md, thus most
of entries have been marked as fuzzy and actually they are incorrect.
Now tutorial.md is planed to be replaced with guide.md, so I'd suggest
removing translation files for a while.
Signed-off-by: OGINO Masanori <masanori.ogino@gmail.com>
This eliminates the last vestige of the `~` syntax.
Instead of `~self`, write `self: Box<TypeOfSelf>`; instead of `mut
~self`, write `mut self: Box<TypeOfSelf>`, replacing `TypeOfSelf` with
the self-type parameter as specified in the implementation.
Closes#13885.
[breaking-change]
We now build the game at the end of the first section.
I wanted to do it as we went along, but it's too hard with these fundamentals
not in place. The rest will do the 'as we go' approach, but I think this is
better.
Simplify example in 5.2 to remove hidden `#[deriving(Show)]`. Traits haven't been introduced yet and now it's easier to just type in the code and expect it to work. Add in some examples for constructing the enum types. Explicitly expose `#![feature(struct_variant)]` in the code to make it more transparent, this bit me when I worked through the tutorial.
Add references in chapter 8 to later chapters describing `Rc`, `Gc` and `Send`. This is a simple fix for #15293.
Simplify vector indexing example in chapter 13 and removed hidden, unnecessary, code. Gave an example usage of the derived `Rand` trait in chapter 17.
Removed references to removed 'extra' crate.
Three small changes:
1. Re-organize headers in the Strings guide so they show up correctly.
2. build the strings guide with the other docs
3. include the strings guide in the list of guides
except where trait objects are involved.
Part of issue #15349, though I'm leaving it open for trait objects.
Cross borrowing for trait objects remains because it is needed until we
have DST.
This will break code like:
fn foo(x: &int) { ... }
let a = box 3i;
foo(a);
Change this code to:
fn foo(x: &int) { ... }
let a = box 3i;
foo(&*a);
[breaking-change]
5.2 Simplify example to remove hidden #[deriving(Show)].
Add example for constructing the enums.
8 Reference later sections describing rc, gc and send.
Fix for #15293.
13 Simplify BananaMania example to remove hidden code.
17 Gave an example using the derived Rand trait.
Removed references to removed 'extra' crate.
- Treat WOFF as binary files so that git does not perform newline normalization.
- Replace corrupt Heuristica files with Source Serif Pro — italics are [almost in production](https://github.com/adobe/source-serif-pro/issues/2) so I left Heuristica Italic which makes a good pair with SSP. Overall, Source Serif Pro is I think a better fit for rustdoc (cc @TheHydroImpulse). This ought to fix#15527.
- Store Source Code Pro locally in order to make offline docs freestanding. Fixes#14778.
Preview: http://adrientetar.legtux.org/cached/rust-docs/core.html
r? @alexcrichton
I'm leaving off `rustdoc` usage because it won't work unless this is a `pub fn`, and I want to talk about public/private in the context of modules. I'm also not mentioning `//!` because it is exclusively used to provide the overview of a module.
