jiebi/CodeConvo huggingface dataset:
Change:
Currently bootstrap supports LTO flavors thin-local (default), thin and fat. Adding the option to completely disable it can speed up develop cycles, especially with incremental compilation. See for benchmarks. When LTO is disabled the standard library still has to be built with so that it can be used by other crates which enable LTO. Disabling should become the default for the library and compiler profile templates. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim to not loose it to time, but feel free to claim it if you want, I might not start work on this until February.
Error: Parsing assign command in failed: ...' claim' ' to not lo'... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
claim Shouldn't this bot be able to detect end of command and silently ignore the rest of the line ?

Discussion:
# Select LTO mode that will be used for compiling rustc. By default, thin local LTO # (LTO within a single crate) is used (like for any Rust crate). You can also select <del> # "thin" or "fat" to apply Thin/Fat LTO to the `rustc_driver` dylib. </del> <ins> # "thin" or "fat" to apply Thin/Fat LTO to the `rustc_driver` dylib, or "off" to disable # LTO entirely. </ins> #lto = "thin-local" # =============================================================================

if stage >= 1 { cargo.rustflag("-Cembed-bitcode=yes"); } <ins> if builder.config.rust_lto == RustcLto::Off { cargo.rustflag("-Clto=off"); } </ins> // By default, rustc does not include unwind tables unless they are required // for a particular target. They are not required by RISC-V targets, but

cargo.rustflag("-Cembed-bitcode=yes"); } RustcLto::ThinLocal => { /* Do nothing, this is the default */ } <ins> RustcLto::Off => { cargo.rustflag("-Clto=off"); } } } else { if builder.config.rust_lto == RustcLto::Off { cargo.rustflag("-Clto=off"); </ins> } }

} /// LTO mode used for compiling rustc itself. <del> #[derive(Default, Clone)] </del> <ins> #[derive(Default, Clone, PartialEq)] </ins> pub enum RustcLto { <ins> Off, </ins> #[default] ThinLocal, Thin,

"thin-local" => Ok(RustcLto::ThinLocal), "thin" => Ok(RustcLto::Thin), "fat" => Ok(RustcLto::Fat), <ins> "off" => Ok(RustcLto::Off), </ins> _ => Err(format!("Invalid value for rustc LTO: {}", s)), } }

incremental = true # Print backtrace on internal compiler errors during bootstrap backtrace-on-ice = true <ins> # Make the compiler and standard library faster to build, at the expense of a ~20% runtime slowdown. lto = "off" </ins> [llvm] # Will download LLVM from CI if available on your platform.

[rust] # This greatly increases the speed of rebuilds, especially when there are only minor changes. However, it makes the initial build slightly slower. incremental = true <ins> # Make the compiler and standard library faster to build, at the expense of a ~20% runtime slowdown. lto = "off" </ins> [llvm] # Will download LLVM from CI if available on your platform.
Change:
Affected crate: , at path in repo Commit: Building rustdoc JSON with Consider the following type from in that commit: I expected to see this happen: the rustdoc JSON should state that etc. are all implemented for that type. Instead, this happened: none of those traits are listed as implemented for that type. Deleting and rebuilding the rustdoc JSON causes all the missing trait impls to be present again. : The same bug is present on nightly: The bug was first spotted by who filed on for incorrectly reporting that types stopped being etc. Of course we now know this was because those traits were genuinely not present in the underlying rustdoc JSON file. Thanks for all the awesome work you've been doing! It's been absolutely fundamental for .
It should be fixed with
That didn't fix it MCVE: Produces (On )
This is fixed & works just fine as of today
It would be great to make sure we have a regression test case for this before closing the issue, since this is a correctness concern for cargo-semver-checks that would be very difficult to debug if it reoccurs.
Absolutely, that's what I've done in

Discussion:
<ins> //@ compile-flags: --document-private-items --document-hidden-items pub trait TheTrait {} #[doc(hidden)] struct Value {} //@ has '$.index[*][?(@.docs=="THE IMPL")]' /// THE IMPL impl TheTrait for Value {} </ins>
Change:
[ ] Previous Stable [ ] Current Stable [ ] Current Beta [ ] Current Nightly No response
searched toolchains through Regression in
I wonder if this is cc ?
very likely :thinking: will revert if we don't figure out how to fix this in the near future
<details<summarycompiler logs</summary</detailsedit: my bad I'm experiencing
WG-prioritization assigning priority (). label -I-prioritize +P-medium
bisection tested with , seems to point to commit searched nightlies: from nightly-2023-01-15 to nightly-2023-02-09 regressed nightly: nightly-2023-01-27 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsit's a rollup of:
I already bisected this one (see second comment :D) any should we revert now? it's still ICEing
yeah, wanted to revert this since looking at this a few days ago :sweat_smile: but for that I want to update the comment for why we're avoiding opaque types which is effort, so I've put it off for a while. Should get to it over the next few days

Discussion:
RetagKind, RuntimePhase, Rvalue, SourceScope, Statement, StatementKind, Terminator, TerminatorKind, UnOp, START_BLOCK, }; <del> use rustc_middle::ty::{self, InstanceDef, ParamEnv, Ty, TyCtxt}; </del> <ins> use rustc_middle::ty::{self, InstanceDef, ParamEnv, Ty, TyCtxt, TypeVisitable}; </ins> use rustc_mir_dataflow::impls::MaybeStorageLive; use rustc_mir_dataflow::storage::always_storage_live_locals; use rustc_mir_dataflow::{Analysis, ResultsCursor};

return true; } <ins> // We sometimes have to use `defining_opaque_types` for subtyping // to succeed here and figuring out how exactly that should work // is annoying. It is harmless enough to just not validate anything // in that case. We still check this after analysis as all opque // types have been revealed at this point. if (src, dest).has_opaque_types() { return true; } </ins> crate::util::is_subtype(self.tcx, self.param_env, src, dest) } }

// check-pass <ins> // compile-flags: -Zvalidate-mir // Using -Zvalidate-mir as a regression test for #107346. </ins> trait Duh {}

warning: opaque type `impl Trait<Assoc = impl Send>` does not satisfy its associated type bounds <del> --> $DIR/nested-return-type2.rs:25:24 </del> <ins> --> $DIR/nested-return-type2.rs:28:24 </ins> | LL |     type Assoc: Duh; |                 --- this associated type bound is unsatisfied for `impl Send`
Change:
[ ] Previous Stable [ ] Current Stable [ ] Current Beta [X] Current Nightly Needs
Should be fixed by
On current nightly () seems to be fixed (emits only warnings like before): (if this counts as "tested" I can remove )
we should have a proper automated test so this doesn't slip through again

Discussion:
<ins> // check-pass // edition:2018 fn main() {} struct StructA {} struct StructB {} impl StructA { fn fn_taking_struct_b(&self, struct_b: &StructB) -> bool { true } } async fn get_struct_a_async() -> StructA { StructA {} } async fn ice() { match Some(StructB {}) { Some(struct_b) if get_struct_a_async().await.fn_taking_struct_b(&struct_b) => {} _ => {} } } </ins>
Change:
[ ] Previous Stable [ ] Current Stable [ ] Current Beta [ ] Current Nightly No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
reduced:
reduced further claim I think try to get a span from to but we work around and assume that since we don't have a , it must be somewhere near EOF. When we then try to point at it via diagnostics, we get the error that we don't have anything to actually point to.

Discussion:
keep_space: (bool, bool), ) { let primary_span = if let Some((lo, hi)) = spans { <ins> if hi.is_empty() { // do not point at delims that do not exist return; } </ins> MultiSpan::from(vec![lo, hi]) } else { MultiSpan::from(value_span)

<ins> // check that we don't generate a span that points beyond EOF // error-pattern: unclosed delimiter // error-pattern: unclosed delimiter // error-pattern: unclosed delimiter fn a(){{{ </ins>

<ins> error: this file contains an unclosed delimiter --> $DIR/issue-107423-unused-delim-only-one-no-pair.rs:7:11 | LL | fn a(){{{ |       --- ^ |       ||| |       ||unclosed delimiter |       |unclosed delimiter |       unclosed delimiter error: this file contains an unclosed delimiter --> $DIR/issue-107423-unused-delim-only-one-no-pair.rs:7:11 | LL | fn a(){{{ |       --- ^ |       ||| |       ||unclosed delimiter |       |unclosed delimiter |       unclosed delimiter error: this file contains an unclosed delimiter --> $DIR/issue-107423-unused-delim-only-one-no-pair.rs:7:11 | LL | fn a(){{{ |       --- ^ |       ||| |       ||unclosed delimiter |       |unclosed delimiter |       unclosed delimiter error: aborting due to 3 previous errors </ins>
Change:
This happens when a test function is declared inside another function, the one where the tests start running to be precise, using a custom testing framework in a nostd environment. link: at lines: 31 [function declared outside] , 40 [comment of function declared inside] I checked with the latest version of the nightly channel, and could not find any related issues <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Running on your current master branch () doesn't reproduce the issue for me, all tests pass.
That is because the section causing the issue is commented out, if you remove function27 (dont mind the name) from and replace the comment from the function init() in with function27, it should reproduce the issue (just checked again) ! I shouldve pushed and linked a version that reproduces the issue, my bad
I'm able to reproduce this with nightly <details<summary<stronglong file</strong</summary<p</p</details
Got it down to this: using (see ).
claim

Discussion:
} let sp = ecx.with_def_site_ctxt(attr_sp); <del> let mut item = anno_item.expect_item(); </del> <ins> let (mut item, is_stmt) = match anno_item { Annotatable::Item(item) => (item, false), Annotatable::Stmt(stmt) if let ast::StmtKind::Item(_) = stmt.kind => if let ast::StmtKind::Item(i) = stmt.into_inner().kind { (i, true) } else { unreachable!() }, _ => { ecx.struct_span_err( anno_item.span(), "`#[test_case]` attribute is only allowed on items", ) .emit(); return vec![]; } }; </ins> item = item.map(|mut item| { let test_path_symbol = Symbol::intern(&item_path( // skip the name of the root module

item }); <del> return vec![Annotatable::Item(item)]; </del> <ins> let ret = if is_stmt { Annotatable::Stmt(P(ecx.stmt_item(item.span, item))) } else { Annotatable::Item(item) }; vec![ret] </ins> } pub fn expand_test(

<ins> // compile-flags: --test #![feature(custom_test_frameworks)] #![deny(unnameable_test_items)] fn foo() { #[test_case] //~^ ERROR cannot test inner items [unnameable_test_items] fn test2() {} } </ins>

<ins> error: cannot test inner items --> $DIR/issue-107454.rs:7:5 | LL |     #[test_case] |     ^^^^^^^^^^^^ | note: the lint level is defined here --> $DIR/issue-107454.rs:4:9 | LL | #![deny(unnameable_test_items)] |         ^^^^^^^^^^^^^^^^^^^^^ = note: this error originates in the attribute macro `test_case` (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to previous error </ins>
Change:
Typically, one would write to check whether is aligned to 8B. However, Clippy complains and says it would be nicer to write it as . Although it is disputable whether this is really more readable, the problem is that the code generated is significantly worse. For example, let's take this code: I expected to see the same optimal code generated. However, the compiler indeed generates separate instruction for instruction and additional compare, instead of a single instruction. Code generated on x64: Code generated on ARM: This happens with the newest Rust 1.67 as well as with older versions and in nightly. Checking of / and / with / operators against can be mapped to checking via a mask of / ones at the tail (for ) or head (for ) of the mask word and comparing against 0 for (which is implicitly done and set as ZERO/EQ flag in CPU flags after the TEST operation, i.e., it boils down to a single instruction) or the mask word for (which boils down to two instructions).
https://rust- Clippy does at least list it as a possible downside of the lint.
This was fixed by
Thanks. Any ETA estimate when it will land in Rust compiler (TBH I have no idea how and how often llvm is pulled)? I just tested with nightly and the code generated is still suboptimal.
Sorry, I also don't know when on Rust side. (I guess hopefully LLVM release would be in few weeks, as you may know )
This will land in Rust nightly around August with the LLVM 17 upgrade. Assigning to myself to check back when it's time.
Godbolt: Fixed by , needs codegen test.

Discussion:
<ins> // compile-flags: -O // min-llvm-version: 17 #![crate_type = "lib"] // CHECK-LABEL: @trailing_zeros_ge #[no_mangle] pub fn trailing_zeros_ge(val: u32) -> bool { // CHECK: %[[AND:.*]] = and i32 %val, 7 // CHECK: %[[ICMP:.*]] = icmp eq i32 %[[AND]], 0 // CHECK: ret i1 %[[ICMP]] val.trailing_zeros() >= 3 } // CHECK-LABEL: @trailing_zeros_gt #[no_mangle] pub fn trailing_zeros_gt(val: u64) -> bool { // CHECK: %[[AND:.*]] = and i64 %val, 15 // CHECK: %[[ICMP:.*]] = icmp eq i64 %[[AND]], 0 // CHECK: ret i1 %[[ICMP]] val.trailing_zeros() > 3 } </ins>
Change:
You get an error like this: I didn't investigate it further. It never worked in the past and I assumed it's due to the old mingw version on CI, but it still doesn't work after and the actual error doesn't look like it's caused by a toolchain version.
It happens only with LLD but i haven't investigated. At MSYS2 we had to remove M68k to maskę it build with LLD but since 1.67 we no longer got this issue:
cc do either of you know what LLD is doing differently compared to LD? is this something rustc controls? It would help to have a minimization smaller than "all of rustc and llvm" ...
I don't know the answer to any of those questions but this issue stopped happening at MSYS2 so it could have been some LLVM 16 change (MSYS2 uses LLVM 15 but backports important patches from LLVM 16) that fixed this problem there.
Looks like we're currently using LLVM 15: label +S-blocked
Yup, I plan to try once is merged.
This is still an issue with LLVM 17.0.5.
There's an ODR violation in M68k's , its base class doesn't have a virtual method while for all other targets including PPC do. So it's not a linker's problem, actually complains about this too, it just reports it as a warning instead of an error. The simplest fix is to rename the structure (instead of adding virtual methods). I wish I tried to debug this a few years eariler.
Could someone submit this to LLVM? I'm not familiar with their processes. cc
You can simply open pull request to Otherwise I can do it this or next weekend.
Opened a pull request with the fix -
Fixed in

Discussion:
<del> Subproject commit 2c4de6c2492d5530de3f19f41d8f88ba984c2fe2 </del> <ins> Subproject commit 606bc11367b475542bd6228163424ca43b4dbdbc </ins>
Change:
Minimal example What I expected: works. What happens: (check & build work) No response No response
Thanks for the report! I have transferred this to rust-lang/rust as that is where rustdoc issues are tracked.
Seems to be a compiler bug. Adding the relevant tag.
Although the MCVE looks a bit esoteric, it actually comes from using  in an fairly straightforward way. I wouldn't be surprised if others have/will run into this.
Ran on this and found it regressed in The PR () states it's a revert of a previous commit. So maybe it was broken before the commit that needed reverting.
label A-auto-traits A-synthetic-impls
I can no longer reproduce this issue.

Discussion:
<ins> // We used to ICE here while trying to synthesize auto trait impls. // issue: 107715 //@ check-pass pub const N: usize = 1; pub struct MapType<K: Supertrait<V>, V> { _array: K::Array, } pub trait Subtrait: Supertrait<[u8; N]> {} pub trait Supertrait<V> { type Array: AnotherTrait<V>; } pub trait AnotherTrait<V> { const LENGTH: usize; } pub struct Container<S: Subtrait> { _x: MapType<S, [u8; N]>, } </ins>

<ins> // We used to ICE here while trying to synthesize auto trait impls. // issue: 114657 pub trait Foo { type FooType; } pub trait Bar<const A: usize>: Foo<FooType = <Self as Bar<A>>::BarType> { type BarType; } pub(crate) const B: usize = 5; pub trait Tec: Bar<B> {} pub struct Structure<C: Tec> { //~ ERROR the trait bound `C: Bar<5>` is not satisfied _field: C::BarType, //~ ERROR the trait bound `C: Bar<5>` is not satisfied } </ins>

<ins> error[E0277]: the trait bound `C: Bar<5>` is not satisfied --> $DIR/projections-in-super-trait-bound-unsatisfied.rs:16:1 | LL | pub struct Structure<C: Tec> { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `Bar<5>` is not implemented for `C` | help: consider further restricting this bound | LL | pub struct Structure<C: Tec + Bar<5>> { |                             ++++++++ error[E0277]: the trait bound `C: Bar<5>` is not satisfied --> $DIR/projections-in-super-trait-bound-unsatisfied.rs:17:13 | LL |     _field: C::BarType, |             ^^^^^^^^^^ the trait `Bar<5>` is not implemented for `C` | help: consider further restricting this bound | LL | pub struct Structure<C: Tec + Bar<5>> { |                             ++++++++ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0277`. </ins>

<ins> // We used to ICE here while trying to synthesize auto trait impls. // issue: 112828 struct Outer(Inner); struct Inner; unsafe impl<Q: Trait> Send for Inner {} //~^ ERROR the type parameter `Q` is not constrained by the impl trait, self type, or predicates trait Trait {} </ins>

<ins> error[E0207]: the type parameter `Q` is not constrained by the impl trait, self type, or predicates --> $DIR/unconstrained-param-in-impl-ambiguity.rs:7:13 | LL | unsafe impl<Q: Trait> Send for Inner {} |             ^ unconstrained type parameter error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0207`. </ins>
Change:
This was encountered in my project's daily Github Action to compile using the latest Rust nightly. More details can be found here -
We're also hitting this in ICU4X's CI pipeline (which uses combine)
This is likely a duplicate of: This will likely be resolved by: If you wish to verify it fixes this problem, then you may wish to check by compiling with that patch.
This is a duplicate of the currently pinned . Closing to lower signal to noise ratio.

Discussion:
// which is different from how types/const are freshened. | TypeFlags::HAS_TY_FRESH.bits | TypeFlags::HAS_CT_FRESH.bits <del> | TypeFlags::HAS_FREE_LOCAL_REGIONS.bits; </del> <ins> | TypeFlags::HAS_FREE_LOCAL_REGIONS.bits | TypeFlags::HAS_RE_ERASED.bits; </ins> /// Does this have `Projection`? const HAS_TY_PROJECTION           = 1 << 10;

<ins> // build-pass #![crate_type = "lib"] pub trait StreamOnce { type Error; } pub trait ResetStream: StreamOnce { fn reset(&mut self) -> Result<(), Self::Error>; } impl<'a> ResetStream for &'a str where Self: StreamOnce { #[inline] fn reset(&mut self) -> Result<(), Self::Error> { Ok(()) } } </ins>

<ins> // build-pass // compile-flags: -C opt-level=3 #![crate_type = "lib"] pub trait Archive { type Archived; type Resolver; fn resolve(resolver: Self::Resolver, out: *mut Self::Archived); } pub type Archived<T> = <T as Archive>::Archived; pub type Resolver<T> = <T as Archive>::Resolver; pub struct Record<'a> { _payload: &'a [u8], } pub struct ArchivedRecord<'a> where &'a [u8]: Archive, { _payload: Archived<&'a [u8]>, } pub struct RecordResolver<'a> where &'a [u8]: Archive, { _payload: Resolver<&'a [u8]>, } impl<'a> Archive for Record<'a> where &'a [u8]: Archive, { type Archived = ArchivedRecord<'a>; type Resolver = RecordResolver<'a>; fn resolve(_resolver: Self::Resolver, _out: *mut Self::Archived) {} } </ins>

= help: a `loop` may express intention better if this is on purpose = note: `#[warn(unconditional_recursion)]` on by default <del> error[E0275]: overflow evaluating the requirement `Map<&mut Map<&mut Map<&mut Map<..., ...>, ...>, ...>, ...>: Iterator` </del> <ins> error[E0275]: overflow evaluating the requirement `Map<&mut std::ops::Range<u8>, [closure@$DIR/issue-83150.rs:12:24: 12:27]>: Iterator` </ins> | = help: consider increasing the recursion limit by adding a `#![recursion_limit = "256"]` attribute to your crate (`issue_83150`) <ins> = note: required for `&mut Map<&mut std::ops::Range<u8>, [closure@$DIR/issue-83150.rs:12:24: 12:27]>` to implement `Iterator` = note: 65 redundant requirements hidden </ins> = note: required for `&mut Map<&mut Map<&mut Map<&mut Map<&mut Map<&mut Map<&mut Map<..., ...>, ...>, ...>, ...>, ...>, ...>, ...>` to implement `Iterator` = note: the full type name has been written to '$TEST_BUILD_DIR/recursion/issue-83150/issue-83150.long-type-hash.txt'
Change:
In-scope trait aliases bring into scope (methods of) the aliased trait and all of its supertraits. I can understand the rationale for bringing (methods of) the aliased trait into scope (namely to , but also bringing into scope (methods of) that trait's supertraits is both inconsistent (compared with bringing the aliased trait itself into scope) and surprising: . (For the avoidance of doubt, only the methods are brought into scope—not the trait itself: thus, in the above example with the alias uncommented, one cannot use an unqualified ). cc label A-resolve A-traits C-bug F-traitalias <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
From cursory inspection, the following (originally from , cc looks suspect:
claim

Discussion:
let trait_ref = self.tcx.mk_trait_ref(trait_def_id, trait_substs); if self.tcx.is_trait_alias(trait_def_id) { <del> // For trait aliases, assume all supertraits are relevant. let bounds = iter::once(ty::Binder::dummy(trait_ref)); self.elaborate_bounds(bounds, |this, new_trait_ref, item| { let new_trait_ref = this.erase_late_bound_regions(new_trait_ref); </del> <ins> // For trait aliases, recursively assume all explicitly named traits are relevant for expansion in traits::expand_trait_aliases( self.tcx, iter::once((ty::Binder::dummy(trait_ref), self.span)), ) { let bound_trait_ref = expansion.trait_ref(); for item in self.impl_or_trait_item(bound_trait_ref.def_id()) { if !self.has_applicable_self(&item) { self.record_static_candidate(CandidateSource::Trait( bound_trait_ref.def_id(), )); } else { let new_trait_ref = self.erase_late_bound_regions(bound_trait_ref); </ins> <del> let (xform_self_ty, xform_ret_ty) = this.xform_self_ty(&item, new_trait_ref.self_ty(), new_trait_ref.substs); this.push_candidate( Candidate { xform_self_ty, xform_ret_ty, item, import_ids: import_ids.clone(), kind: TraitCandidate(new_trait_ref), }, false, ); }); </del> <ins> let (xform_self_ty, xform_ret_ty) = self.xform_self_ty( &item, new_trait_ref.self_ty(), new_trait_ref.substs, ); self.push_candidate( Candidate { xform_self_ty, xform_ret_ty, item, import_ids: import_ids.clone(), kind: TraitCandidate(new_trait_ref), }, false, ); } } } </ins> } else { debug_assert!(self.tcx.is_trait(trait_def_id)); if self.tcx.trait_is_auto(trait_def_id) {

<ins> // Regression test for #107747: methods from trait alias supertraits were brought into scope // // check-pass #![feature(trait_alias)] use std::fmt; trait Foo: fmt::Debug {} trait Bar = Foo; #[derive(Debug)] struct Qux(bool); impl fmt::Display for Qux { fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { self.0.fmt(f) } } fn main() {} </ins>