This is accomplished by rewriting static expressions into equivalent patterns.
This way, patterns referencing static variables can both participate
in exhaustiveness analysis as well as be compiled down into the appropriate
branch of the decision trees that match expressions are codegened to.
Fixes#6533.
Fixes#13626.
Fixes#13731.
Fixes#14576.
Fixes#15393.
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
Reimplement the string slice's `Iterator<char>` by wrapping the already efficient
slice iterator.
The iterator uses our guarantee that the string contains valid UTF-8, but its only unsafe
code is transmuting the decoded `u32` into `char`.
Benchmarks suggest that the runtime of `Chars` benchmarks are reduced by up to 30%,
runtime of `Chars` reversed reduced by up to 60%.
```
BEFORE
test str::bench::char_indicesator ... bench: 124 ns/iter (+/- 1)
test str::bench::char_indicesator_rev ... bench: 188 ns/iter (+/- 9)
test str::bench::char_iterator ... bench: 122 ns/iter (+/- 2)
test str::bench::char_iterator_ascii ... bench: 302 ns/iter (+/- 41)
test str::bench::char_iterator_for ... bench: 123 ns/iter (+/- 4)
test str::bench::char_iterator_rev ... bench: 189 ns/iter (+/- 14)
test str::bench::char_iterator_rev_for ... bench: 177 ns/iter (+/- 4)
AFTER
test str::bench::char_indicesator ... bench: 85 ns/iter (+/- 3)
test str::bench::char_indicesator_rev ... bench: 82 ns/iter (+/- 2)
test str::bench::char_iterator ... bench: 100 ns/iter (+/- 3)
test str::bench::char_iterator_ascii ... bench: 317 ns/iter (+/- 3)
test str::bench::char_iterator_for ... bench: 86 ns/iter (+/- 2)
test str::bench::char_iterator_rev ... bench: 80 ns/iter (+/- 6)
test str::bench::char_iterator_rev_for ... bench: 68 ns/iter (+/- 0)
```
Note: Branch name is no longer indicative of the implementation.
The first is to require that `#[crate_name]` and `--crate-name` always match (if both are specified). The second is to fix parallel compilation in cargo by mixing in `-C extra-filename` into the temporary outputs of the compiler.
When invoking the compiler in parallel, the intermediate output of the object
files and bytecode can stomp over one another if two crates with the same name
are being compiled.
The output file is already being disambiguated with `-C extra-filename`, so this
commit alters the naming of the temporary files to also mix in the extra
filename to ensure that file names don't clash.
This is accomplished by rewriting static expressions into equivalent patterns.
This way, patterns referencing static variables can both participate
in exhaustiveness analysis as well as be compiled down into the appropriate
branch of the decision trees that match expressions are codegened to.
Fixes#6533.
Fixes#13626.
Fixes#13731.
Fixes#14576.
Fixes#15393.
Thanks to comments from @alexcrichton, write the next/next_back function
bodies without nested functions in a more top-to-bottom flow style.
Also improve comment style and motivate the unsafe blocks with comments.
Thanks to comments from @huonw, clarify decoding details and use
statics for important constants for UTF-8 decoding. Convert some magic
numbers scattered in the same file to use the statics too.
Removed `index_to_bitset` field and `_frozen` methods.
Drive-by: Added some missing docs on the `each_bit` method.
Drive-by: Put in a regular pattern: when calling `compute_id_range`, ensure `words_per_id > 0` by either asserting it or checking and returning early. (The prior code did the latter in a few cases where necessary, but debugging is much aided by the asserts.)
Fix#15019.
Part of the original discussions around the `--crate-name` flag brought up that
mass confusion can arise when the flag specifies a different name than is
contained in the crate.
The current primary use case of the `--crate-name` flag is through cargo and
not requiring a `#[crate_name]` attribute, but if the `#[crate_name]` attribute
is specified it will likely go awry when the two names deviate from one another.
This commit requires that if both are provided they both match to prevent this
confusion.
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
Importing from types was disallowed in #6462. Flag was set for paths whether it is a module or a type. Type flag was set when impl was seen. The problem is, for cross-crate situations, when reexport is involved, it is possible that impl is seen too late because metadata is loaded lazily.
Fix#15664.
This small patch causes the stability lint to bail out when traversing
any AST produced via a macro expansion. Ultimately, we would like to
lint the contents of the macro at the place where the macro is defined,
but regardless we should not be linting it at the use site.
Closes#15703
I decided to change it up a little today and hack out the beginning of the String guide. Strings are different enough in Rust that I think they deserve a specific guide, especially for those who are used to managed languages.
I decided to start with Strings because they get asked about a lot in IRC, and also based on discussions like this one on reddit: http://www.reddit.com/r/rust/comments/2ac390/generic_string_literals/
I blatantly stole bits from our other documentation on Strings. It's a little sparse at current, but I wanted to start somewhere.
I am not exactly sure what should go in "Best Practices," and would like the feedback from the team on this. Specifically due to comments like this one: http://www.reddit.com/r/rust/comments/2ac390/generic_string_literals/citmxb5
This should fix issue #15541. It would be good to have an test case for this would also be nice but I haven't had the time to write one. The change is very small though and it doesn't break anything in the existing test suite, so I guess we can add it without test for now.
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]
r? @alexcrichton
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]
Simple usage examples for Integer methods. Also group `div_rem` and `div_mod_floor` together at the bottom of the trait, to reflect the documentation rendering.
Re-use the vector iterator to implement the chars iterator.
The iterator uses our guarantee that the string contains valid UTF-8,
but its only unsafe code is transmuting the decoded u32 into char.
