Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reduce FormattingOptions to 64 bits #136974

Merged
merged 4 commits into from
Mar 22, 2025
Merged

Conversation

m-ou-se
Copy link
Member

@m-ou-se m-ou-se commented Feb 13, 2025

This is part of #99012

This reduces FormattingOptions from 6-7 machine words (384 bits on 64-bit platforms, 224 bits on 32-bit platforms) to just 64 bits (a single register on 64-bit platforms).

Before:

pub struct FormattingOptions {
    flags: u32, // only 6 bits used
    fill: char,
    align: Option<Alignment>,
    width: Option<usize>,
    precision: Option<usize>,
}

After:

pub struct FormattingOptions {
    /// Bits:
    ///  - 0-20: fill character (21 bits, a full `char`)
    ///  - 21: `+` flag
    ///  - 22: `-` flag
    ///  - 23: `#` flag
    ///  - 24: `0` flag
    ///  - 25: `x?` flag
    ///  - 26: `X?` flag
    ///  - 27: Width flag (if set, the width field below is used)
    ///  - 28: Precision flag (if set, the precision field below is used)
    ///  - 29-30: Alignment (0: Left, 1: Right, 2: Center, 3: Unknown)
    ///  - 31: Always set to 1
    flags: u32,
    /// Width if width flag above is set. Otherwise, always 0.
    width: u16,
    /// Precision if precision flag above is set. Otherwise, always 0.
    precision: u16,
}

@m-ou-se m-ou-se added T-libs Relevant to the library team, which will review and decide on the PR/issue. A-fmt Area: `core::fmt` S-experimental Status: Ongoing experiment that does not require reviewing and won't be merged in its current state. labels Feb 13, 2025
@m-ou-se m-ou-se self-assigned this Feb 13, 2025
@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 13, 2025
@m-ou-se m-ou-se removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 13, 2025
@m-ou-se
Copy link
Member Author

m-ou-se commented Feb 13, 2025

@bors try @rust-timer queue

@rust-timer

This comment has been minimized.

@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Feb 13, 2025
@bors
Copy link
Contributor

bors commented Feb 13, 2025

⌛ Trying commit c059377 with merge 47853a6...

bors added a commit to rust-lang-ci/rust that referenced this pull request Feb 13, 2025
Reduce FormattingOptions to 64 bits

This reduces FormattingOptions from 6-7 machine words (384 bits on 64-bit platforms, 224 bits on 32-bit platforms) to just 64 bits (a single register on 64-bit platforms).

This PR includes rust-lang#136932, which reduces the width and precision options to 16 bits, to make it all fit.

Before:

```rust
pub struct FormattingOptions {
    flags: u32, // only 6 bits used
    fill: char,
    align: Option<Alignment>,
    width: Option<usize>,
    precision: Option<usize>,
}
```

After:

```rust
pub struct FormattingOptions {
    /// Bits:
    ///  - 0: `+` flag [rt::Flag::SignPlus]
    ///  - 1: `-` flag [rt::Flag::SignMinus]
    ///  - 2: `#` flag [rt::Flag::Alternate]
    ///  - 3: `0` flag [rt::Flag::SignAwareZeroPad]
    ///  - 4: `x?` flag [rt::Flag::DebugLowerHex]
    ///  - 5: `X?` flag [rt::Flag::DebugUpperHex]
    ///  - 6-7: Alignment (0: Left, 1: Right, 2: Center, 3: Unknown)
    ///  - 8: Width flag (if set, the width field below is used)
    ///  - 9: Precision flag (if set, the precision field below is used)
    ///  - 10: unused
    ///  - 11-31: fill character (21 bits, a full `char`)
    flags: u32,
    /// Width if width flag above is set. Otherwise, always 0.
    width: u16,
    /// Precision if precision flag above is set. Otherwise, always 0.
    precision: u16,
}
```
@rust-log-analyzer

This comment has been minimized.

@bors
Copy link
Contributor

bors commented Feb 13, 2025

☀️ Try build successful - checks-actions
Build commit: 47853a6 (47853a630ac42e5c5ab5fcd1f07d37eef67f84e9)

@rust-timer

This comment has been minimized.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (47853a6): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

mean range count
Regressions ❌
(primary)
0.6% [0.6%, 0.6%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-0.4% [-0.7%, -0.2%] 5
Improvements ✅
(secondary)
-0.5% [-0.7%, -0.2%] 2
All ❌✅ (primary) -0.2% [-0.7%, 0.6%] 6

Max RSS (memory usage)

Results (primary 2.0%, secondary -1.2%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
2.0% [1.9%, 2.1%] 2
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-1.2% [-1.2%, -1.2%] 1
All ❌✅ (primary) 2.0% [1.9%, 2.1%] 2

Cycles

Results (secondary -0.3%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
1.8% [1.8%, 1.8%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-2.3% [-2.3%, -2.3%] 1
All ❌✅ (primary) - - 0

Binary size

Results (primary -0.2%, secondary -0.1%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
0.1% [0.0%, 0.3%] 6
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-0.2% [-0.5%, -0.0%] 70
Improvements ✅
(secondary)
-0.1% [-0.3%, -0.0%] 56
All ❌✅ (primary) -0.2% [-0.5%, 0.3%] 76

Bootstrap: 792.804s -> 787.91s (-0.62%)
Artifact size: 347.85 MiB -> 347.86 MiB (0.00%)

@rustbot rustbot added perf-regression Performance regression. and removed S-waiting-on-perf Status: Waiting on a perf run to be completed. labels Feb 13, 2025
@m-ou-se
Copy link
Member Author

m-ou-se commented Feb 13, 2025

@m-ou-se m-ou-se added S-blocked Status: Blocked on something else such as an RFC or other implementation work. and removed S-experimental Status: Ongoing experiment that does not require reviewing and won't be merged in its current state. labels Feb 13, 2025
@m-ou-se

This comment was marked as outdated.

@rust-log-analyzer

This comment has been minimized.

@bors

This comment was marked as outdated.

jieyouxu added a commit to jieyouxu/rust that referenced this pull request Mar 10, 2025
…=scottmcm

Reduce formatting `width` and `precision` to 16 bits

This is part of rust-lang#99012

This is reduces the `width` and `precision` fields in format strings to 16 bits. They are currently full `usize`s, but it's a bit nonsensical that we need to support the case where someone wants to pad their value to eighteen quintillion spaces and/or have eighteen quintillion digits of precision.

By reducing these fields to 16 bit, we can reduce `FormattingOptions` to 64 bits (see rust-lang#136974) and improve the in memory representation of `format_args!()`. (See additional context below.)

This also fixes a bug where the width or precision is silently truncated when cross-compiling to a target with a smaller `usize`. By reducing the width and precision fields to the minimum guaranteed size of `usize`, 16 bits, this bug is eliminated.

This is a breaking change, but affects almost no existing code.

---

Details of this change:

There are three ways to set a width or precision today:

1. Directly a formatting string, e.g. `println!("{a:1234}")`
2. Indirectly in a formatting string, e.g. `println!("{a:width$}", width=1234)`
3. Through the unstable `FormattingOptions::width` method.

This PR:

- Adds a compiler error for 1. (`println!("{a:9999999}")` no longer compiles and gives a clear error.)
- Adds a runtime check for 2. (`println!("{a:width$}, width=9999999)` will panic.)
- Changes the signatures of the (unstable) `FormattingOptions::[get_]width` methods to use a `u16` instead.

---

Additional context for improving `FormattingOptions` and `fmt::Arguments`:

All the formatting flags and options are currently:

- The `+` flag (1 bit)
- The `-` flag (1 bit)
- The `#` flag (1 bit)
- The `0` flag (1 bit)
- The `x?` flag (1 bit)
- The `X?` flag (1 bit)
- The alignment (2 bits)
- The fill character (21 bits)
- Whether a width is specified (1 bit)
- Whether a precision is specified (1 bit)
- If used, the width (a full usize)
- If used, the precision (a full usize)

Everything except the last two can simply fit in a `u32` (those add up to 31 bits in total).

If we can accept a max width and precision of u16::MAX, we can make a `FormattingOptions` that is exactly 64 bits in size; the same size as a thin reference on most platforms.

If, additionally, we also limit the number of formatting arguments, we can also reduce the size of `fmt::Arguments` (that is, of a `format_args!()` expression).
jieyouxu added a commit to jieyouxu/rust that referenced this pull request Mar 10, 2025
…=scottmcm

Reduce formatting `width` and `precision` to 16 bits

This is part of rust-lang#99012

This is reduces the `width` and `precision` fields in format strings to 16 bits. They are currently full `usize`s, but it's a bit nonsensical that we need to support the case where someone wants to pad their value to eighteen quintillion spaces and/or have eighteen quintillion digits of precision.

By reducing these fields to 16 bit, we can reduce `FormattingOptions` to 64 bits (see rust-lang#136974) and improve the in memory representation of `format_args!()`. (See additional context below.)

This also fixes a bug where the width or precision is silently truncated when cross-compiling to a target with a smaller `usize`. By reducing the width and precision fields to the minimum guaranteed size of `usize`, 16 bits, this bug is eliminated.

This is a breaking change, but affects almost no existing code.

---

Details of this change:

There are three ways to set a width or precision today:

1. Directly a formatting string, e.g. `println!("{a:1234}")`
2. Indirectly in a formatting string, e.g. `println!("{a:width$}", width=1234)`
3. Through the unstable `FormattingOptions::width` method.

This PR:

- Adds a compiler error for 1. (`println!("{a:9999999}")` no longer compiles and gives a clear error.)
- Adds a runtime check for 2. (`println!("{a:width$}, width=9999999)` will panic.)
- Changes the signatures of the (unstable) `FormattingOptions::[get_]width` methods to use a `u16` instead.

---

Additional context for improving `FormattingOptions` and `fmt::Arguments`:

All the formatting flags and options are currently:

- The `+` flag (1 bit)
- The `-` flag (1 bit)
- The `#` flag (1 bit)
- The `0` flag (1 bit)
- The `x?` flag (1 bit)
- The `X?` flag (1 bit)
- The alignment (2 bits)
- The fill character (21 bits)
- Whether a width is specified (1 bit)
- Whether a precision is specified (1 bit)
- If used, the width (a full usize)
- If used, the precision (a full usize)

Everything except the last two can simply fit in a `u32` (those add up to 31 bits in total).

If we can accept a max width and precision of u16::MAX, we can make a `FormattingOptions` that is exactly 64 bits in size; the same size as a thin reference on most platforms.

If, additionally, we also limit the number of formatting arguments, we can also reduce the size of `fmt::Arguments` (that is, of a `format_args!()` expression).
jieyouxu added a commit to jieyouxu/rust that referenced this pull request Mar 11, 2025
…=scottmcm

Reduce formatting `width` and `precision` to 16 bits

This is part of rust-lang#99012

This is reduces the `width` and `precision` fields in format strings to 16 bits. They are currently full `usize`s, but it's a bit nonsensical that we need to support the case where someone wants to pad their value to eighteen quintillion spaces and/or have eighteen quintillion digits of precision.

By reducing these fields to 16 bit, we can reduce `FormattingOptions` to 64 bits (see rust-lang#136974) and improve the in memory representation of `format_args!()`. (See additional context below.)

This also fixes a bug where the width or precision is silently truncated when cross-compiling to a target with a smaller `usize`. By reducing the width and precision fields to the minimum guaranteed size of `usize`, 16 bits, this bug is eliminated.

This is a breaking change, but affects almost no existing code.

---

Details of this change:

There are three ways to set a width or precision today:

1. Directly a formatting string, e.g. `println!("{a:1234}")`
2. Indirectly in a formatting string, e.g. `println!("{a:width$}", width=1234)`
3. Through the unstable `FormattingOptions::width` method.

This PR:

- Adds a compiler error for 1. (`println!("{a:9999999}")` no longer compiles and gives a clear error.)
- Adds a runtime check for 2. (`println!("{a:width$}, width=9999999)` will panic.)
- Changes the signatures of the (unstable) `FormattingOptions::[get_]width` methods to use a `u16` instead.

---

Additional context for improving `FormattingOptions` and `fmt::Arguments`:

All the formatting flags and options are currently:

- The `+` flag (1 bit)
- The `-` flag (1 bit)
- The `#` flag (1 bit)
- The `0` flag (1 bit)
- The `x?` flag (1 bit)
- The `X?` flag (1 bit)
- The alignment (2 bits)
- The fill character (21 bits)
- Whether a width is specified (1 bit)
- Whether a precision is specified (1 bit)
- If used, the width (a full usize)
- If used, the precision (a full usize)

Everything except the last two can simply fit in a `u32` (those add up to 31 bits in total).

If we can accept a max width and precision of u16::MAX, we can make a `FormattingOptions` that is exactly 64 bits in size; the same size as a thin reference on most platforms.

If, additionally, we also limit the number of formatting arguments, we can also reduce the size of `fmt::Arguments` (that is, of a `format_args!()` expression).
Comment on lines +1968 to +1970
// Extract the debug upper/lower hex, zero pad, alternate, and plus/minus flags
// to stay compatible with older versions of Rust.
self.options.flags >> 21 & 0x3F
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Checking: do we have pinning tests already that continue to pass after this change?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, there's currently no test for this method. This method is deprecated, so perhaps we shouldn't put effort into trying to keep it compatible with older versions of Rust.

Maybe we should add a test, or change the method to just always return 0.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a test.

@scottmcm
Copy link
Member

Looks good to me! I put some thoughts above, but r=me even if you look at them and decide they're not needed.

@rust-log-analyzer

This comment has been minimized.

@m-ou-se m-ou-se force-pushed the fmt-options-64-bit branch from c5f6ecf to d7685f0 Compare March 21, 2025 16:06
@m-ou-se
Copy link
Member Author

m-ou-se commented Mar 21, 2025

@bors r=scottmcm

@bors
Copy link
Contributor

bors commented Mar 21, 2025

📌 Commit d7685f0 has been approved by scottmcm

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 21, 2025
@bors
Copy link
Contributor

bors commented Mar 22, 2025

⌛ Testing commit d7685f0 with merge ce76ccc...

bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 22, 2025
Reduce FormattingOptions to 64 bits

This is part of rust-lang#99012

This reduces FormattingOptions from 6-7 machine words (384 bits on 64-bit platforms, 224 bits on 32-bit platforms) to just 64 bits (a single register on 64-bit platforms).

Before:

```rust
pub struct FormattingOptions {
    flags: u32, // only 6 bits used
    fill: char,
    align: Option<Alignment>,
    width: Option<usize>,
    precision: Option<usize>,
}
```

After:

```rust
pub struct FormattingOptions {
    /// Bits:
    ///  - 0-20: fill character (21 bits, a full `char`)
    ///  - 21: `+` flag
    ///  - 22: `-` flag
    ///  - 23: `#` flag
    ///  - 24: `0` flag
    ///  - 25: `x?` flag
    ///  - 26: `X?` flag
    ///  - 27: Width flag (if set, the width field below is used)
    ///  - 28: Precision flag (if set, the precision field below is used)
    ///  - 29-30: Alignment (0: Left, 1: Right, 2: Center, 3: Unknown)
    ///  - 31: Always set to 1
    flags: u32,
    /// Width if width flag above is set. Otherwise, always 0.
    width: u16,
    /// Precision if precision flag above is set. Otherwise, always 0.
    precision: u16,
}
```
@rust-log-analyzer
Copy link
Collaborator

The job i686-mingw-2 failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
[RUSTC-TIMING] rustc_std_workspace_core test:false 0.657
error: could not compile `rustc-std-workspace-core` (lib)

Caused by:
  process didn't exit successfully: `D:\a\rust\rust\build\bootstrap\debug\rustc D:\a\rust\rust\build\bootstrap\debug\rustc --crate-name rustc_std_workspace_core --edition=2024 library\rustc-std-workspace-core\lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C embed-bitcode=no -C codegen-units=1 -C debug-assertions=on --check-cfg cfg(docsrs,test) --check-cfg "cfg(feature, values())" -C metadata=2975d146d9ade100 -C extra-filename=-237cf34ade28b0c6 --out-dir D:\a\rust\rust\build\i686-pc-windows-gnu\stage0-std\i686-pc-windows-gnu\release\deps --target i686-pc-windows-gnu -L dependency=D:\a\rust\rust\build\i686-pc-windows-gnu\stage0-std\i686-pc-windows-gnu\release\deps -L dependency=D:\a\rust\rust\build\i686-pc-windows-gnu\stage0-std\release\deps --extern core=D:\a\rust\rust\build\i686-pc-windows-gnu\stage0-std\i686-pc-windows-gnu\release\deps\libcore-382cf6b153344497.rmeta --cfg=bootstrap -Csymbol-mangling-version=legacy --check-cfg=cfg(feature,values(any())) -Zunstable-options --check-cfg=cfg(bootstrap) -Zmacro-backtrace -Csplit-debuginfo=packed -Cprefer-dynamic -Zinline-mir -Zinline-mir-preserve-debug -Zmir_strip_debuginfo=locals-in-tiny-functions -Alinker-messages -Cforce-frame-pointers=yes "-Zcrate-attr=doc(html_root_url=\"https://doc.rust-lang.org/nightly/\")" -Z binary-dep-depinfo` (exit code: 0xc0000005, STATUS_ACCESS_VIOLATION)
warning: build failed, waiting for other jobs to finish...
[RUSTC-TIMING] compiler_builtins test:false 4.562
[RUSTC-TIMING] core test:false 28.553
Build completed unsuccessfully in 0:22:20
make: *** [Makefile:126: ci-mingw-x-2] Error 1
  local time: Sat Mar 22 06:53:51 CUT 2025
  network time: Sat, 22 Mar 2025 06:53:51 GMT
##[error]Process completed with exit code 2.
Post job cleanup.
[command]"C:\Program Files\Git\bin\git.exe" version

@bors
Copy link
Contributor

bors commented Mar 22, 2025

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Mar 22, 2025
@m-ou-se
Copy link
Member Author

m-ou-se commented Mar 22, 2025

@bors retry

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 22, 2025
@bors
Copy link
Contributor

bors commented Mar 22, 2025

⌛ Testing commit d7685f0 with merge 0ce1369...

@bors
Copy link
Contributor

bors commented Mar 22, 2025

☀️ Test successful - checks-actions
Approved by: scottmcm
Pushing 0ce1369 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Mar 22, 2025
@bors bors merged commit 0ce1369 into rust-lang:master Mar 22, 2025
7 checks passed
@rustbot rustbot added this to the 1.87.0 milestone Mar 22, 2025
Copy link

What is this? This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing db68788 (parent) -> 0ce1369 (this PR)

Test differences

Show 200 test diffs

Additionally, 200 doctest diffs were found. These are ignored, as they are noisy.

Job group index

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (0ce1369): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

  • If the regression was expected or you think it can be justified,
    please write a comment with sufficient written justification, and add
    @rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
  • If you think that you know of a way to resolve the regression, try to create
    a new PR with a fix for the regression.
  • If you do not understand the regression or you think that it is just noise,
    you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
    were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
0.2% [0.2%, 0.2%] 3
Improvements ✅
(primary)
-0.4% [-0.5%, -0.2%] 7
Improvements ✅
(secondary)
-1.5% [-1.5%, -1.5%] 1
All ❌✅ (primary) -0.4% [-0.5%, -0.2%] 7

Max RSS (memory usage)

Results (primary -0.2%, secondary 4.4%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
7.1% [4.9%, 9.3%] 2
Regressions ❌
(secondary)
4.4% [3.2%, 5.6%] 2
Improvements ✅
(primary)
-3.8% [-6.6%, -1.7%] 4
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) -0.2% [-6.6%, 9.3%] 6

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

Results (primary -0.2%, secondary -0.1%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
0.0% [0.0%, 0.1%] 3
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-0.2% [-0.5%, -0.0%] 81
Improvements ✅
(secondary)
-0.1% [-0.3%, -0.0%] 53
All ❌✅ (primary) -0.2% [-0.5%, 0.1%] 84

Bootstrap: 775.231s -> 774.128s (-0.14%)
Artifact size: 365.57 MiB -> 365.52 MiB (-0.01%)

@rustbot rustbot added the perf-regression Performance regression. label Mar 22, 2025
@m-ou-se m-ou-se deleted the fmt-options-64-bit branch March 22, 2025 18:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-fmt Area: `core::fmt` merged-by-bors This PR was explicitly merged by bors. perf-regression Performance regression. perf-regression-triaged The performance regression has been triaged. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants