Errors can be printed with {}, printing with {:?} does not work very
well.
Not actually related to this PR, but it came up when running the tests
and now is as good a time to fix it as any.
This was motivated by a desire to remove allocation in the common
pattern of
let old = key.replace(None)
do_something();
key.replace(old);
This also switched the map representation from a Vec to a TreeMap. A Vec
may be reasonable if there's only a couple TLD keys, but a TreeMap
provides better behavior as the number of keys increases.
Like the Vec, this TreeMap implementation does not shrink the container
when a value is removed. Unlike Vec, this TreeMap implementation cannot
reuse an empty node for a different key. Therefore any key that has been
inserted into the TLD at least once will continue to take up space in
the Map until the task ends. The expectation is that the majority of
keys that are inserted into TLD will be expected to have a value for
most of the rest of the task's lifetime. If this assumption is wrong,
there are two reasonable ways to fix this that could be implemented in
the future:
1. Provide an API call to either remove a specific key from the TLD and
destruct its node (e.g. `remove()`), or instead to explicitly clean
up all currently-empty nodes in the map (e.g. `compact()`). This is
simple, but requires the user to explicitly call it.
2. Keep track of the number of empty nodes in the map and when the map
is mutated (via `replace()`), if the number of empty nodes passes
some threshold, compact it automatically. Alternatively, whenever a
new key is inserted that hasn't been used before, compact the map at
that point.
---
Benchmarks:
I ran 3 benchmarks. tld_replace_none just replaces the tld key with None
repeatedly. tld_replace_some replaces it with Some repeatedly. And
tld_replace_none_some simulates the common behavior of replacing with
None, then replacing with the previous value again (which was a Some).
Old implementation:
test tld_replace_none ... bench: 20 ns/iter (+/- 0)
test tld_replace_none_some ... bench: 77 ns/iter (+/- 4)
test tld_replace_some ... bench: 57 ns/iter (+/- 2)
New implementation:
test tld_replace_none ... bench: 11 ns/iter (+/- 0)
test tld_replace_none_some ... bench: 23 ns/iter (+/- 0)
test tld_replace_some ... bench: 12 ns/iter (+/- 0)
The correct terminology is Task-Local Data, or TLD. Task-Local Storage,
or TLS, is the old terminology that was abandoned because of the
confusion with Thread-Local Storage (TLS).
the CFG for match statements.
There were two bugs in issue #14684. One was simply that the borrow
check didn't know about the correct CFG for match statements: the
pattern must be a predecessor of the guard. This disallows the bad
behavior if there are bindings in the pattern. But it isn't enough to
prevent the memory safety problem, because of wildcards; thus, this
patch introduces a more restrictive rule, which disallows assignments
and mutable borrows inside guards outright.
I discussed this with Niko and we decided this was the best plan of
action.
This breaks code that performs mutable borrows in pattern guards. Most
commonly, the code looks like this:
impl Foo {
fn f(&mut self, ...) {}
fn g(&mut self, ...) {
match bar {
Baz if self.f(...) => { ... }
_ => { ... }
}
}
}
Change this code to not use a guard. For example:
impl Foo {
fn f(&mut self, ...) {}
fn g(&mut self, ...) {
match bar {
Baz => {
if self.f(...) {
...
} else {
...
}
}
_ => { ... }
}
}
}
Sometimes this can result in code duplication, but often it illustrates
a hidden memory safety problem.
Closes#14684.
[breaking-change]
r? @pnkfelix
Some of the fixes include:
- fixing mismatch between the documentation and the function parameters. (i.e. documentation references `path` parameter, but it's actually called `from`, or vice versa)
- A few Error sections were missing an "if" on the middle clause. For example, they used to be: "This function will return an error if [Thing], [Another Thing], or if [Yet Another Thing]." I added an "if" so it becomes "This function will return an error if [Thing], if [Another Thing], or if [Yet Another Thing]"
- The error sections previously started off with 3 different phrases:
- "This function will return an error if ..."
- "Will return an error if ..."
- "This call will return an error if ..."
I've standardized on the first phrase.
We previously reexported entire modules, which caused private things to
become reachable and trip the dead code and private items in public API
lints.
Closes#15912
Previously the implementation of Hash was limited to tuples of up to arity 8. This increases it to tuples of up to arity 12.
Also, the implementation macro for `Hash` used to expand to something like this:
impl Hash for (a7,)
impl Hash for (a6, a7)
impl Hash for (a5, a6, a7)
...
This style is inconsistent with the implementations in core::tuple, which look like this:
impl Trait for (A,)
impl Trait for (A, B)
impl Trait for (A, B, C)
...
This is perhaps a minor point, but it does mean the documentation pages are inconsistent. Compare the tuple implementations in the documentation for [Hash](http://static.rust-lang.org/doc/master/std/hash/trait.Hash.html) and [PartialOrd](http://static.rust-lang.org/doc/master/core/cmp/trait.PartialOrd.html)
This changes the Hash implementation to be consistent with `core::tuple`.
Some minor changes to the compiler to expose this information. Very
inconvenient since struct fields aren't an item. Adds (yet another) table to
metadata.
Closes#15739
We previously reexported entire modules, which caused private things to
become reachable and trip the dead code and private items in public API
lints.
Closes#15912
Stumbled across this and thought it would be cool to prove. I've never used Ogden's Lemma before, but I'm pretty sure I used it right. The pumping lemma definitely doesn't seem sufficient for the job. In particular, when using the pumping lemma, you can always just pump one of the quotes, and it's fine. Ogden's Lemma lets you effectively force the pumper to use certain characters in the string.
@cmr
