core::slice was originally written to tolerate overflow (notably, with
slices of zero-sized elements), but it was never updated to use wrapping
arithmetic when overflow traps were added.
Also correctly handle the case of calling .nth() on an Iter with a
zero-sized element type. The iterator was assuming that the pointer
value of the returned reference was meaningful, but that's not true for
zero-sized elements.
Fixes#25016.
There were still some mentions of `~[T]` and `~T`, mostly in comments and debugging statements. I tried to do my best to preserve meaning, but I might have gotten some wrong-- I'm happy to fix anything :)
I've found that there are still huge amounts of occurrences of `task`s in the documentation. This PR tries to eliminate all of them in favor of `thread`.
An automated script was run against the `.rs` and `.md` files,
subsituting every occurrence of `task` with `thread`. In the `.rs`
files, only the texts in the comment blocks were affected.
The [UnsafeCell documentation says it is undefined behavior](http://doc.rust-lang.org/nightly/std/cell/struct.UnsafeCell.html), so people shouldn't do it.
This happened to catch one case in libstd that was doing this, and I switched that to use an UnsafeCell internally.
Closes#13146
collections: Implement String::drain(range) according to RFC 574
`.drain(range)` is unstable and under feature(collections_drain).
This adds a safe way to remove any range of a String as efficiently as
possible.
As noted in the code, this drain iterator has none of the memory safety
issues of the vector version.
RFC tracking issue is #23055
`.drain(range)` is unstable and under feature(collections_drain).
This adds a safe way to remove any range of a String as efficiently as
possible.
As noted in the code, this drain iterator has none of the memory safety
issues of the vector version.
RFC tracking issue is #23055
Hi! While researching stuff for the reference and the grammar, I came across a few mentions of using the `priv` keyword that was removed in 0.11.0 (#13547, #8122, rust-lang/rfcs#26, [RFC 0026](https://github.com/rust-lang/rfcs/blob/master/text/0026-remove-priv.md)).
One occurrence is a mention in the reference, a few are in comments, and a few are marking test functions. I left the test that makes sure you can't name an ident `priv` since it's still a reserved keyword. I did a little grepping around for `priv `, priv in backticks, `Private` etc and I think the remaining instances are fine, but if anyone knows anywhere in particular I should check for any other lingering mentions of `priv`, please let me know and I would be happy to! 🍂🌊
The new functionality being tested here is that a drop impl bounded by
`UserDefined` does not cause dropck to inject its conservative
constraints on region inference.
This is OK to do given:
- PIE is supported on Android starting with API 16.
- The bots are running API 18.
- API < 16 now has a 12.5% market share[0] as of 2015-04-29.
Closes#17437.
[0] https://developer.android.com/about/dashboards/index.html
r? @alexcrichton
Add `-g` (to testcase) that I should have included in PR #24932.
Note it is safe, with respect to autobuilds, to land before #24945.
(In other words, landing this sooner won't break things for anyone any
worse than they were already broken, since there are *other* tests
that also add `-g` to their flags via `compile-flags: -g`.)
Fixes for -g handling
First:
* decouples our handling of `-g` for the test suite from our handling of `-g` for the rest of the compiler/stdlib building.
* Namely, if you do `--enable-debug` or `--enable-debuginfo`, that should only affect `rustc` and the standard library crates; the tests should all continue to compile without `-g` unless:
* you pass `--enable-debuginfo-tests`, or
* the test itself requests the `-g` option (e.g. via a `// compile-flags: -g` embedded comment).
Second:
* Makes `rustc` more flexible in that it now accepts multiple occurrences of `-g -g`
* (as a drive-by, I gave `-O` the same treatment: multiple occurrences of `-O` are treated as synonymous as a single occurrence of `-O`.
Fix#24937
Currently, LLVM lowers a cttz8 on x86_64 to these instructions:
```asm
movzbl %dil, %eax
bsfl %eax, %eax
movl $32, %ecx
cmovnel %eax, %ecx
cmpl $32, %ecx
movl $8, %eax
cmovnel %ecx, %eax
```
To improve the codegen, we can zero extend the 8 bit integer, then set
bit 8 and perform a cttz operation on the extended value. That way
there's no conditional operation involved at all.
This was discovered by this benchmark: https://github.com/Kimundi/long_strings_without_repeats
Timings on my box with the current nightly:
```
running 4 tests
test bench_cpp_naive_big ... bench: 5479222 ns/iter (+/- 254222)
test bench_noop_big ... bench: 571405 ns/iter (+/- 111950)
test bench_rust_naive_big ... bench: 7798102 ns/iter (+/- 148841)
test bench_rust_unsafe_big ... bench: 6606488 ns/iter (+/- 67529)
```
Timings with the patch applied:
```
running 4 tests
test bench_cpp_naive_big ... bench: 5470944 ns/iter (+/- 7109)
test bench_noop_big ... bench: 568944 ns/iter (+/- 6895)
test bench_rust_naive_big ... bench: 6795901 ns/iter (+/- 43806)
test bench_rust_unsafe_big ... bench: 5584879 ns/iter (+/- 5291)
```
This is OK to do given:
- PIE is supported on Android starting with API 16.
- The bots are running API 18.
- API < 16 now has a 12.5% market share[0] as of 2015-04-29.
Unfortunately, this breaks backtrace support. See #17520.
Closes#17437.
[0] https://developer.android.com/about/dashboards/index.html
Note it is safe, with respect to autobuilds, to land before #24945.
(In other words, landing this sooner won't break things for anyone any
worse than they were already broken, since there are *other* tests
that also add `-g` to their flags via `compile-flags: -g`.)
metdata: Fix zero-normalization of the pos of a `MultiByteChar`
Fix#24687
The source byte/character mappings for every crate track the collection of multi-characters from its source files specially. When we import the source information for another file into the current compilation unit, we assign its byte-positions unique values by shifting them all by a fixed adjustment, tracked in the `start_pos` field. But when we pull out the source span information for one function from one crate and into our own crate, we need to re-normalize the byte positions: subtracting the old `start_pos` and adding the new `start_pos`. The `new_imported_filemap(..)` method handles adding the new `start_pos`, so all `creader` needs to do is re-normalize each `pos` to zero.
It seems like it was indeed trying to do this, but it mistakenly added the old `start_pos` instead of subtracting it.
There are still quite a few ignored Android tests kicking around, most of which were added in 445faca844, which has a pretty unfortunate commit message.
r? @alexcrichton
