Add non-panicking abs() functions to all signed integer types.
Currently, calling abs() on one of the signed integer types might panic (in
debug mode at least) because the absolute value of the largest negative value
can not be represented in that signed type. Unlike all other integer
operations, there is currently not a non-panicking version on this function.
This seems to just be an oversight in the design, therefore just adding it now.
Escape fewer Unicode codepoints in `Debug` impl of `str`
Use the same procedure as Python to determine whether a character is
printable, described in [PEP 3138]. In particular, this means that the
following character classes are escaped:
- Cc (Other, Control)
- Cf (Other, Format)
- Cs (Other, Surrogate), even though they can't appear in Rust strings
- Co (Other, Private Use)
- Cn (Other, Not Assigned)
- Zl (Separator, Line)
- Zp (Separator, Paragraph)
- Zs (Separator, Space), except for the ASCII space `' '` `0x20`
This allows for user-friendly inspection of strings that are not
English (e.g. compare `"\u{e9}\u{e8}\u{ea}"` to `"éèê"`).
Fixes#34318.
CC #34422.
[PEP 3138]: https://www.python.org/dev/peps/pep-3138/
Currently, calling abs() on one of the signed integer types might panic (in
debug mode at least) because the absolute value of the largest negative value
can not be represented in that signed type. Unlike all other integer
operations, there is currently not a non-panicking version on this function.
This seems to just be an oversight in the design, therefore just adding it now.
Use the same procedure as Python to determine whether a character is
printable, described in [PEP 3138]. In particular, this means that the
following character classes are escaped:
- Cc (Other, Control)
- Cf (Other, Format)
- Cs (Other, Surrogate), even though they can't appear in Rust strings
- Co (Other, Private Use)
- Cn (Other, Not Assigned)
- Zl (Separator, Line)
- Zp (Separator, Paragraph)
- Zs (Separator, Space), except for the ASCII space `' '` (`0x20`)
This allows for user-friendly inspection of strings that are not
English (e.g. compare `"\u{e9}\u{e8}\u{ea}"` to `"éèê"`).
Fixes#34318.
[PEP 3138]: https://www.python.org/dev/peps/pep-3138/
feat: reinterpret `precision` field for strings
This commit changes the behavior of formatting string arguments with both width and precision fields set.
Documentation says that the `width` field is the "minimum width" that the format should take up. If the value's string does not fill up this many characters, then the padding specified by fill/alignment will be used to take up the required space.
This is true for all formatted types except string, which is truncated down to `precision` number of chars and then all of `fill`, `align` and `width` fields are completely ignored.
For example: `format!("{:/^10.8}", "1234567890);` emits "12345678". In the contrast Python version works as the expected:
```python
>>> '{:/^10.8}'.format('1234567890')
'/12345678/'
```
This commit gives back the `Python` behavior by changing the `precision` field meaning to the truncation and nothing more. The result string *will* be prepended/appended up to the `width` field with the proper `fill` char.
__However, this is the breaking change, I admit.__ Feel free to close it, but otherwise it should be mentioned in the `std::fmt` documentation somewhere near of `fill/align/width` fields description.
core: impl From<T> for Option<T>
First, the semantics of this `impl` seem spot on. If I have a value `T`, and I wish to make a `Option<T>`, then `Option::from(val)` should always give `Some(val)`.
Second, this allows improvement for several APIs that currently take `Option<T>` as arguments. Consider:
```rust
fn set_read_timeout(&mut self, timeout: Option<u32>) {
// ...
}
x.set_read_timeout(Some(30));
x.set_read_timeout(Some(10));
x.set_read_timeout(None);
```
With this `impl`:
```rust
fn set_read_timeout<T: Into<Option<u32>>>(&mut self, timeout: T) {
let timeout = timeout.into();
// ...
}
x.set_read_timeout(30);
x.set_read_timeout(10);
x.set_read_timeout(Some(10)); // backwards compatible
x.set_read_timeout(None);
```
The change to those methods aren't included, but could be modified later.
r? @sfackler
Fix up documentation around no_std
1. Fix the sections in the book to have the correct signatures. I've
also marked them as `ignore`; there's no way to set the `no_std`
feature for libc, so it pulls in the stdlib, so this wasn't even
testing the actual thing it was testing. Better to just ignore.
2. Correcting libcore's docs for factual inaccuracy, and add a note
about language items.
Fixes#33677
r? @alexcrichton
1. Fix the sections in the book to have the correct signatures. I've
also marked them as `ignore`; there's no way to set the `no_std`
feature for libc, so it pulls in the stdlib, so this wasn't even
testing the actual thing it was testing. Better to just ignore.
2. Correcting libcore's docs for factual inaccuracy, and add a note
about language items.
Fixes#33677
doc: Mention that writeln! and println! always use LF
Fixes#34697
I'm not really satisfied with the wording, but I didn't have a better idea. Suggestions welcome.
This primarily removes a lot of `sync::Static*` APIs and rejiggers the
associated implementations. While doing this it was discovered that the
`is_poisoned` method can actually result in a data race for the Mutex/RwLock
primitives, so the inner `Cell<bool>` was changed to an `AtomicBool` to prevent
the associated data race. Otherwise the usage/gurantees should be the same
they were before.
Some more pattern cleanup and bugfixing
The next part of https://github.com/rust-lang/rust/pull/34095
The most significant fixed mistake is definitions for partially resolved associated types not being updated after full resolution.
```
fn f<T: Fn()>(arg: T::Output) { .... } // <- the definition of T::Output was not updated in def_map
```
For this reason unstable associated types of stable traits, like `FnOnce::Output`, could be used in stable code when written in unqualified form. Now they are properly checked, this is a **[breaking-change]** (pretty minor one, but a crater run would be nice). The fix is not to use unstable library features in stable code, alternatively `FnOnce::Output` can be stabilized.
Besides that, paths in struct patterns and expressions `S::A { .. }` are now fully resolved as associated types. Such types cannot be identified as structs at the moment, i.e. the change doesn't make previously invalid code valid, but it improves error diagnostics.
Other changes: `Def::Err` is supported better (less chances for ICEs for erroneous code), some incorrect error messages are corrected, some duplicated error messages are not reported, ADT definitions are now available through constructor IDs, everything else is cleanup and code audit.
Fixes https://github.com/rust-lang/rust/issues/34209
Closes https://github.com/rust-lang/rust/issues/22933 (adds tests)
r? @eddyb
