| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Clarified the documentation for Formatter::precision
Added a note that `precision` is interpreted as max-width when formatting strings
|
|
Debug implementations of std types aren't stable, and neither are
derived Debug implementations for any types, including user-defined
types. This commit adds a section to the Debug documentatio noting this
stability status.
|
|
|
|
|
|
|
|
Document unsafe blocks in core::fmt
r? @RalfJung
CC: @rust-lang/wg-unsafe-code-guidelines
#66219
Sorry for the hiatus, but here's a few more files with the unsafe blocks documented! I think working on it smaller chunks like this will be easier for everyone.
|
|
Try to ensure usize marker does not get merged
This follows up on [this conversation](https://github.com/rust-lang/rust/pull/69209#discussion_r379911282). However, I'm not confident this is quite correct, so feedback is appreciated, as always.
|
|
|
|
|
|
|
|
Currently, function items are always tagged unnamed_addr, which means that
casting a function to a function pointer is not guaranteed to produce a
deterministic address. However, once a function pointer is created, we do expect
that to remain stable. So, this changes the show_usize function to a static
containing a function pointer and uses that for comparisons.
Notably, a *static* may have 'unstable' address, but the function pointer within
it must be constant.
Resolves issue 58320.
|
|
This prevents accidental dereferences and so forth of the Void type, as well as
cleaning up the error message to reference Opaque rather than the more
complicated PhantomData type.
|
|
|
|
The contents were always UTF-8 anyway, and &str has an equivalent representation
to &[u8], so this should not affect performance while removing unsafety at
edges.
It may be worth exploring a further adjustment that stores a single byte
(instead of 16) as the contents are always "", "-", or "+".
|
|
|
|
|
|
|
|
|
|
These are no longer used by Formatter methods.
|
|
These are only called from one place and don't generally support being called
from other places; furthermore, they're the only formatter functions that look
at the `args` field (which a future commit will remove).
|
|
The formatting infrastructure stopped emitting these a while back, and in
removing them we can simplify related code.
|
|
Implement `DebugStruct::non_exhaustive`.
This patch adds a function (finish_non_exhaustive) to add ellipsis before the closing brace when formatting using `DebugStruct`.
## Example
```rust
#![feature(debug_non_exhaustive)]
use std::fmt;
struct Bar {
bar: i32,
hidden: f32,
}
impl fmt::Debug for Bar {
fn fmt(&self, fmt: &mut fmt::Formatter<'_>) -> fmt::Result {
fmt.debug_struct("Bar")
.field("bar", &self.bar)
.non_exhaustive(true) // Show that some other field(s) exist.
.finish()
}
}
assert_eq!(
format!("{:?}", Bar { bar: 10, hidden: 1.0 }),
"Bar { bar: 10, .. }",
);
```
|
|
Reset Formatter flags on exit from pad_integral
This fixes a bug where after calling pad_integral with appropriate flags, the
fill and alignment flags would be set to '0' and 'Right' and left as such even
after exiting pad_integral, which meant that future calls on the same Formatter
would get incorrect flags reported.
This is quite difficult to observe in practice, as almost all formatting
implementations in practice don't call `Display::fmt` directly, but rather use
`write!` or a similar macro, which means that they cannot observe the effects of
the wrong flags (as `write!` creates a fresh Formatter instance). However, we
include a test case.
A manual check leads me to believe this is the only case where we failed to reset the flags appropriately, but I could have missed something.
|
|
|
|
|
|
This fixes a bug where after calling pad_integral with appropriate flags, the
fill and alignment flags would be set to '0' and 'Right' and left as such even
after exiting pad_integral, which meant that future calls on the same Formatter
would get incorrect flags reported.
This is quite difficult to observe in practice, as almost all formatting
implementations in practice don't call `Display::fmt` directly, but rather use
`write!` or a similar macro, which means that they cannot observe the effects of
the wrong flags (as `write!` creates a fresh Formatter instance). However, we
include a test case.
|
|
|
|
|
|
Add more delegations to the fmt docs and add doctests
HI,
this is a continuation to #67021
I replaced the `Debug` example with one that use the `Debug*` helpers so that padding etc will work too.
I also added asserts for the doctests as @RalfJung asked :)
The only thing I left with the `write!` macro is the `Display` example as I didn't know if there's a better way to do that.
r? @QuietMisdreavus
|
|
|
|
This reverts commit 15c30ddd69d6cc3fffe6d304c6dc968a5ed046f1.
|
|
|
|
|
|
This commit applies rustfmt with default settings to files in
src/libcore *that are not involved in any currently open PR* to minimize
merge conflicts. The list of files involved in open PRs was determined
by querying GitHub's GraphQL API with this script:
https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8
With the list of files from the script in `outstanding_files`, the
relevant commands were:
$ find src/libcore -name '*.rs' | xargs rustfmt --edition=2018
$ rg libcore outstanding_files | xargs git checkout --
Repeating this process several months apart should get us coverage of
most of the rest of libcore.
|
|
|
|
|
|
|
|
fmt::Write is about string slices, not byte slices
No idea why the docs talk about bytes, maybe a copy-paste error?
|
|
|
|
|
|
|
|
|
|
Instead let's do this via `RUSTFLAGS` in `builder.rs`. Currently
requires a submodule update of `stdarch` to fix a problem with previous
compilers.
|
