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
