The previous wording was confusing. While would we need to go through
the whole list just to find the first code point? `chars()` being an
iterator, we only need to walk from the beginning of the list.
Keeping integer values and integer references in the "value" columns made the examples quite difficult for me to follow. I've added unicode arrows to references to make them more obvious, without using any characters with actual meaning in the rust language (like `&` or previously `~`).
r? @steveklabnik
Keeping integer values and integer references in the "value" columns made the examples quite difficult for me to follow. I've added unicode arrows to make references more obvious, without using a character with actual meaning in the rust language (like `&` or previously `~`).
Turn nonzeroing move hints back off by default.
Works around bugs injected by PR #26173.
* (@pnkfelix is unavailable in the short-term (i.e. for the next week) to fix them.)
* When the bugs are fixed, we will turn nonzeroing move hints back on by default.
Fix#27401
This is a temporary workaround for the bugs that have been found in
the implementation of PR #26173.
* pnkfelix is unavailable in the short-term (i.e. for the next week) to fix them.
* When the bugs are fixed, we will turn this back on by default.
(If you want to play with the known-to-be-buggy optimization in the
meantime, you can opt-back in via the debugging option that this
commit is toggling.)
This ended up being a bigger refactoring than I thought, as I also cleaned a few ugly points in rustc. There are still a few areas that need improvements.
Performance numbers:
```
Before:
572.70user 5.52system 7:33.21elapsed 127%CPU (0avgtext+0avgdata 1173368maxresident)k
llvm-time: 385.858
After:
545.27user 5.49system 7:10.22elapsed 128%CPU (0avgtext+0avgdata 1145348maxresident)k
llvm-time: 387.119
```
A good 5% perf improvement. Note that after this patch >70% of the time is spent in LLVM - Amdahl's law is in full effect.
Passes make check locally.
r? @nikomatsakis
This search happens a lot! Locally, compiling hyper sees the following improvements:
before
real 0m30.843s
user 0m51.644s
sys 0m2.128s
real 0m30.164s
user 0m53.320s
sys 0m2.208s
after
real 0m28.438s
user 0m51.076s
sys 0m2.276s
real 0m28.612s
user 0m51.560s
sys 0m2.192s
This search happens a lot! Locally, compiling hyper sees the following improvements:
before
real 0m30.843s
user 0m51.644s
sys 0m2.128s
real 0m30.164s
user 0m53.320s
sys 0m2.208s
after
real 0m28.438s
user 0m51.076s
sys 0m2.276s
real 0m28.612s
user 0m51.560s
sys 0m2.192s
I got a bit confused reading the guide over why all of a sudden there was an asterisk in the code. I was explained what it was there for in the IRC, and I think it should added it to the docs to prevent any further confusion!
This pull request implements the functionality for [RFC 873](https://github.com/rust-lang/rfcs/blob/master/text/0873-type-macros.md). This is currently just an update of @freebroccolo's branch from January, the corresponding commits are linked in each commit message.
@nikomatsakis and I had talked about updating the macro language to support a lifetime fragment specifier, and it is possible to do that work on this branch as well. If so we can (collectively) talk about it next week during the pre-RustCamp work week.
In Section 3.2, TARPL says that "standard allocators (including jemalloc, the one used by default in Rust) generally consider passing in 0 for the size of an allocation as Undefined Behaviour."
However, the C standard and jemalloc manual says allocating zero bytes
should succeed:
- C11 7.22.3 paragraph 1: "If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object."
- [jemalloc manual](http://www.freebsd.org/cgi/man.cgi?query=jemalloc&sektion=3): "The malloc and calloc functions return a pointer to the allocated memory if successful; otherwise a NULL pointer is returned and errno is set to ENOMEM."
+ Note that the description for `allocm` says "Behavior is undefined if size is 0," but it is an experimental API.
r? @Gankro
In Section 3.2, TARPL says that "standard allocators (including jemalloc, the one used by default in Rust) generally consider passing in 0 for the size of an allocation as Undefined Behaviour."
However, the C standard and jemalloc manual says allocating zero bytes
should succeed:
- C11 7.22.3 paragraph 1: "If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object."
- [jemalloc manual](http://www.freebsd.org/cgi/man.cgi?query=jemalloc&sektion=3): "The malloc and calloc functions return a pointer to the allocated memory if successful; otherwise a NULL pointer is returned and errno is set to ENOMEM."
+ Note that the description for `allocm` says "Behavior is undefined if size is 0," but it is an experimental API.
