Hash VecDeque in its slice parts
Use .as_slices() for a more efficient code path in VecDeque's Hash impl.
This still hashes the elements in the same order.
Before/after timing of VecDeque hashing 1024 elements of u8 and
u64 shows that the vecdeque now can match the Vec
(test_hashing_vec_of_u64 is the Vec run).
```
before
test test_hashing_u64 ... bench: 14,031 ns/iter (+/- 236) = 583 MB/s
test test_hashing_u8 ... bench: 7,887 ns/iter (+/- 65) = 129 MB/s
test test_hashing_vec_of_u64 ... bench: 6,578 ns/iter (+/- 76) = 1245 MB/s
after
running 5 tests
test test_hashing_u64 ... bench: 6,495 ns/iter (+/- 52) = 1261 MB/s
test test_hashing_u8 ... bench: 851 ns/iter (+/- 16) = 1203 MB/s
test test_hashing_vec_of_u64 ... bench: 6,499 ns/iter (+/- 59) = 1260 MB/s
```
This is a work in progress PR that potentially should fix#29084, #28308, #25385, #28288, #31011. I think this may also adresse parts of #2887.
The problem in this issues seems to be that when transcribing macro arguments, we just clone the argument Nonterminal, which still has to original spans. This leads to the unprintable spans. One solution would be to update the spans of the inserted argument to match the argument in the macro definition. So for [this testcase](https://github.com/rust-lang/rust/compare/master...fhahn:macro-ice?expand=1#diff-f7def7420c51621640707b6337726876R2) the error message would be displayed in the macro definition:
src/test/compile-fail/issue-31011.rs:4:12: 4:22 error: attempted access of field `trace` on type `&T`, but no field with that name was found
src/test/compile-fail/issue-31011.rs:4 if $ctx.trace {
Currently I've added a very simple `update_span` function, which updates the span of the outer-most expression of a `NtExpr`, but this `update_span` function should be updated to handle all Nonterminals. But I'm pretty new to the macro system and would like to check if this approach makes sense, before doing that.
This explicitly adds an option telling the linker on these platforms to make the stack and heap non-executable (should already be the case for Windows, and likely OS X).
Without this option there is some risk of accidentally losing NX protection, as the linker will not enable NX if any of the binary's constituent objects don't contain the .note.GNU-stack header.
We're not aware of any users who would want a binary with executable stack or heap, but in future this could be made possible by passing a flag to disable the protection, which would also help document the fact to the crate's users.
Edit: older discussion of previous quickfix to add a .note.GNU-stack header to libunwind's assembly:
Short term solution for issue #30824 to ensure that object files generated from assembler contain the .note.GNU-stack header.
When this header is not present in any constituent object files, the linker refrains from making the stack NX in the final executable.
Further actions:
I'll try to get this change merged in with upstream too, and then update these instructions to just compile the fixed version.
It seems a good idea to use issue #30824 or some other issue to add a test that similar security regressions can be automatically caught in future.
This improves == for VecDeque by using the slice representation.
This will also improve further if codegen for slice comparison improves.
Benchmark run of 1000 u64 elements, comparing for equality (all equal).
Cpu time to compare the vecdeques is reduced to less than 50% of what it
was before.
```
test test_eq_u64 ... bench: 1,885 ns/iter (+/- 163) = 4244 MB/s
test test_eq_new_u64 ... bench: 802 ns/iter (+/- 100) = 9975 MB/s
```
Use .as_slices() for a more efficient code path in VecDeque's Hash impl.
This still hashes the elements in the same order.
Before/after timing of VecDeque hashing 1024 elements of u8 and
u64 shows that the vecdeque now can match the Vec
(test_hashing_vec_of_u64 is the Vec run).
before
test test_hashing_u64 ... bench: 14,031 ns/iter (+/- 236) = 583 MB/s
test test_hashing_u8 ... bench: 7,887 ns/iter (+/- 65) = 129 MB/s
test test_hashing_vec_of_u64 ... bench: 6,578 ns/iter (+/- 76) = 1245 MB/s
after
running 5 tests
test test_hashing_u64 ... bench: 6,495 ns/iter (+/- 52) = 1261 MB/s
test test_hashing_u8 ... bench: 851 ns/iter (+/- 16) = 1203 MB/s
test test_hashing_vec_of_u64 ... bench: 6,499 ns/iter (+/- 59) = 1260 MB/s
This commit removes the `-D warnings` flag being passed through the makefiles to
all crates to instead be a crate attribute. We want these attributes always
applied for all our standard builds, and this is more amenable to Cargo-based
builds as well.
Note that all `deny(warnings)` attributes are gated with a `cfg(stage0)`
attribute currently to match the same semantics we have today
This commit implements the stabilization of the custom hasher support intended
for 1.7 but left out due to some last-minute questions that needed some
decisions. A summary of the actions done in this PR are:
Stable
* `std:#️⃣:BuildHasher`
* `BuildHasher::Hasher`
* `BuildHasher::build_hasher`
* `std:#️⃣:BuildHasherDefault`
* `HashMap::with_hasher`
* `HashMap::with_capacity_and_hasher`
* `HashSet::with_hasher`
* `HashSet::with_capacity_and_hasher`
* `std::collections::hash_map::RandomState`
* `RandomState::new`
Deprecated
* `std::collections::hash_state`
* `std::collections::hash_state::HashState` - this trait was also moved into
`std::hash` with a reexport here to ensure that we can have a blanket impl to
prevent immediate breakage on nightly. Note that this is unstable in both
location.
* `HashMap::with_hash_state` - renamed
* `HashMap::with_capacity_and_hash_state` - renamed
* `HashSet::with_hash_state` - renamed
* `HashSet::with_capacity_and_hash_state` - renamed
Closes#27713
This splits the output of panics into two lines as proposed in #15239 and adds a
note about how to get a backtrace. Because the default panic message consists of
multiple lines now, this changes the test runner's failure output to not indent
the first line anymore.
Fixes#15239 and fixes#11704.
This commit implements the stabilization of the custom hasher support intended
for 1.7 but left out due to some last-minute questions that needed some
decisions. A summary of the actions done in this PR are:
Stable
* `std:#️⃣:BuildHasher`
* `BuildHasher::Hasher`
* `BuildHasher::build_hasher`
* `std:#️⃣:BuildHasherDefault`
* `HashMap::with_hasher`
* `HashMap::with_capacity_and_hasher`
* `HashSet::with_hasher`
* `HashSet::with_capacity_and_hasher`
* `std::collections::hash_map::RandomState`
* `RandomState::new`
Deprecated
* `std::collections::hash_state`
* `std::collections::hash_state::HashState` - this trait was also moved into
`std::hash` with a reexport here to ensure that we can have a blanket impl to
prevent immediate breakage on nightly. Note that this is unstable in both
location.
* `HashMap::with_hash_state` - renamed
* `HashMap::with_capacity_and_hash_state` - renamed
* `HashSet::with_hash_state` - renamed
* `HashSet::with_capacity_and_hash_state` - renamed
Closes#27713
The purpose of the translation item collector is to find all monomorphic instances of functions, methods and statics that need to be translated into LLVM IR in order to compile the current crate.
So far these instances have been discovered lazily during the trans path. For incremental compilation we want to know the set of these instances in advance, and that is what the trans::collect module provides.
In the future, incremental and regular translation will be driven by the collector implemented here.
On all platforms, reading from stdin where the actual stdin isn't present should
return 0 bytes as having been read rather than the entire buffer.
On Windows, handle the case where we're inheriting stdio handles but one of them
isn't present. Currently the behavior is to fail returning an I/O error but
instead this commit corrects it to detecting this situation and propagating the
non-set handle.
Closes#31167
The previous example did not do what its description said. In it panicked on integer overflow in debug mode, and went into an infinite loop in release mode (wrapping back to 0 after printing 254).
The previous example did not do what its description said. In it panicked on integer overflow in debug mode, and went into an infinite loop in release mode (wrapping back to 0 after printing 254).
This fixes#23880, a scoping bug in which items in a block are shadowed by local variables and type parameters that are in scope.
After this PR, an item in a block will shadow any local variables or type parameters above the item in the scope hierarchy. Items in a block will continue to be shadowed by local variables in the same block (even if the item is defined after the local variable).
This is a [breaking-change]. For example, the following code breaks:
```rust
fn foo() {
let mut f = 1;
{
fn f() {}
f += 1; // This will resolve to the function instead of the local variable
}
}
