jiebi/CodeConvo huggingface dataset:
Code change:
#[stable(feature = "ip_u32", since = "1.1.0")] impl From<u32> for Ipv4Addr { <ins> /// It performs the conversion in network order (big-endian). </ins> fn from(ip: u32) -> Ipv4Addr { Ipv4Addr::new((ip >> 24) as u8, (ip >> 16) as u8, (ip >> 8) as u8, ip as u8) }

Related discussion:
text: The conversion traits are implemented for conversion between and , but it is not clear what byte order is used.
It is network order, but that should be documented on the impl.
doc team triage: this would make a great first PR. I am happy to mentor anyone who wants to tackle this issue.
I'd like to, is someone else working on this?
nope, please do! Ping me if you need any help
Code change:
#![feature(doc_spotlight)] #![cfg_attr(test, feature(update_panic_count))] #![cfg_attr(windows, feature(const_atomic_ptr_new))] <ins> #![cfg_attr(windows, feature(used))] </ins> #![default_lib_allocator]

Related discussion:
text: nightly-2017-10-24 contains a libtest with bad DWARF: I can reproduce this if I recompile libtest locally: The problem can be fixed by disabling thinlto (and keeping the codegen units is ok). I noticed this with nightly-2017-10-24 because it is the first nightly compiled with thinlto, but the problem also occurs if I compile libtest with thinlto enabled using earlier compilers (eg nightly-2017-10-17). Inspecting the DWARF, a DIE at that local ref offset does exist in another codegen unit, so the problem seems to be that we should be using a global ref instead.
cc'ing since he's been poking around in LLVM's DWARF generation code recently.
Sorta smells like an LLVM bug -- but hard to say. Who should investigate?
triage: P-medium if you are able to investigate as part of ThinLTO work would be great.
It's likely that this is the cause of , which even if the underlying segfault were fixed would likely prevent backtraces from happening on OSX.
This is unfortunately not "automagically fixed" if we upgrade to LLVM 5
Making progress. First up, minimized Rust source code via creduce to get: Next up let's see if we can reduce it to one object file: Ok looks like only one object file is invalid! Let's take a look the LLVM IR: Ok let's see what's happening by minimizing the LLVM IR: yielding which I . I checked out LLVM trunk, , and looks like the error is still on LLVM trunk.
I'm not sure at this point if this is an LLVM bug, a rustc bug, or a ThinLTO bug. I've managed to extract what I believe is a for this which reproduces the error. I'm hoping fixing that IR will fix all other related issues to this at this point in time. For those of you more familiar with debug information (probably everyone other than me!) mind taking a look at that IR? Does it look "obviously wrong"? If it's "obviously wrong" I can try to work backwards to figure out what piece of the pipeline introduced such a wrong piece, but if it looks correct I can open an LLVM bug saying that we think it may be broken (and maybe they'll say it's "obviously wrong"!)
Code change:
#![feature(doc_spotlight)] #![cfg_attr(test, feature(update_panic_count))] #![cfg_attr(windows, feature(const_atomic_ptr_new))] <ins> #![cfg_attr(windows, feature(used))] </ins> #![default_lib_allocator]

Related discussion:
text: cc
Er, I went ahead and to go ahead and broaden the search.
The DWARF is definitely badly formed: it's using a unit-relative offset to reference the parameter type, when it should be using a section-relative offset because the type is in a different unit. The bad offset is occurring for a parameter to subprogram in . The problem is that subprograms and share the same , but have different units ( and ). Based on some print debugging, it appears that LLVM doesn't handle this case. So and are constructed in unit , but when is constructed, it reuses the existing DIE as its parent, and so it also ends up in unit . So my guess is that when the parameter is constructed, it uses the unit that was specified to determine if the parameter and type are in the same unit, and thus gets it wrong.
thanks for the info! I know basically nothing about DWARF though and malformed whatnots, so the IR here is heavily edited by both machines (creduce/bugpoint) and me (to make it more readable). My assumption is that if LLVM accepts IR and generates an object file it shouldn't yield such a dwarfdump error, but are you thinking that given possibly valid LLVM IR the dwarfdump error is possible? If so that may make reduction far more difficult... Or do you think that this looks like upstream LLVM needs to get updated?
I don't think the editing of the IR caused the problem. I'll check later, but I think it's quite likely that the same problem occurs for the unedited IR. I don't know if the LLVM developers intend for this to be valid IR, or if they are missing a validation check somewhere. I think they may have never encountered this possibility. clang divides code into units based on files, so I don't think it ever splits code in the same scope across multiple units, whereas I think rust splits code into units quite differently. That's a bit of conjecture on my part though, it might be better to ask someone who knows more (I only know about DWARF, not LLVM or rustc). Reading the LLVM code a bit more, I think it will be possible to fix there by stopping it from sharing the scope (the scope creation is initiated and the sharing check is ). It's also worth reconsidering how rust splits code into units though.
Code change:
#![feature(doc_spotlight)] #![cfg_attr(test, feature(update_panic_count))] #![cfg_attr(windows, feature(const_atomic_ptr_new))] <ins> #![cfg_attr(windows, feature(used))] </ins> #![default_lib_allocator]

Related discussion:
text: It might make sense to ensure all code for a given type is kept in the same unit.
Ah ok that all makes sense. Note though that rustc is very much like clang when it comes to debuginfo/codegen units. The major difference here is that LLVM is doing inlining across codegen units via ThinLTO, and that's likely where these new situations are arising from.
I see, yep my understanding of how rust partitions units was wrong. So when using ThinLTO, the additional units by ThinLTO only contain information needed for the additional inlined functions? Do these inlined functions always share scopes/types with unit , or can we determine when they do? If so, it'd be nice to add them to unit instead of creating additonal units. I think this would get us DWARF that looks the same as that generated for . eg dwarfdump is happy if I run:
interesting! I'd have to look into the internals of ThinLTO to know for sure though. It seems like LLVM isn't ready (maybe?) for multiple codegen units in debug info in one LLVM module (a codegen unit), but it makes sense to me what you're thinking about having all inlined debug info share the same codegen unit information. Now where that change would go in LLVM I'm not entirely sure...
Does firefox use fat LTO? There's been a couple of bugs that have some similarities to this ( and maybe ). Also note that absence of dwarfdump errors doesn't mean the offsets are all okay. dwarfdump is only complaining if the offset is larger than the unit length, but even if it's less it may still incorrectly be a local ref. So there may be more instances that are unnoticed.
cc ^
I can reproduce using normal LTO. Library crate is: Binary crate is: Also here's a thin LTO version that gives smaller IR than the previous Vec test case:
Thanks It definitely sounds like at this point this is an existing bug we've just never hit before. My inclination would be to paper over this if we can. Unfortunately though I don't know how to fix this at the LLVM IR layer. My naive idea would be to just point everything at one codegen unit for each LLVM module (debug-info-wise) but I don't know how to change existing debuginfo of a module.
Code change:
#![feature(doc_spotlight)] #![cfg_attr(test, feature(update_panic_count))] #![cfg_attr(windows, feature(const_atomic_ptr_new))] <ins> #![cfg_attr(windows, feature(used))] </ins> #![default_lib_allocator]

Related discussion:
text: I'm not able to access currently, so not sure exactly what Adrian's suggestions were, but here's a that fixes LLVM to use a global ref when needed. It's not as simple as comparing parent DIEs, because the variable is initially , so the check . I don't have a lot of confidence in the patch, but maybe it's a useful starting point for someone who knows more about LLVM.
awesome thanks! I think LLVM's bugzilla is back now so indicating such.
I've confirmed that applying your patch to LLVM fixes having malformed debug information. Next up I'm confirming that it
Sure enough it fixes the issue! would you be interested in sending the patch upstream?
I prefer if someone who knows more about LLVM could upstream the patch.
Would this be something you could do, You can evaluate the changes to the generated DWARF best, I think.
We do use for Firefox builds, yes.
Sure, I will do this. I think the issue is more an LLVM thing than a DWARF thing, though; not certain I know enough there to say whether the patch is good, but I will at least do the shepherding. Also I wanted to point out that knows quite a bit about DWARF; he's one of the principals on
Actually maybe there's nothing to do here except merge this into rust-llvm?
Yes, I think so. I'll do that.
Cool, thanks!
oh no worries! I've tested it locally now and will submit a PR soon (with another change or two)
Ok, thanks
I've opened up which I think should close this out (and also re-enables ThinLTO in a few locations)
Hi, I get a Dwarf Error with GDB 8.0.1 on one of the files of Rust 1.23.0 that was built was Rust 1.23.0 on Fedora 27, in a build enabled with debuginfo. Is it related to this issue or should I open a new one? Relevant build flags:
yeah I believe that's this issue, it should be fixed in 1.24 though!
Code change:
StyledBuffer { text: vec![], styles: vec![] } } <del> fn replace_tabs(&mut self) { for (line_pos, line) in self.text.iter_mut().enumerate() { let mut tab_pos = vec![]; for (pos, c) in line.iter().enumerate() { if *c == 't' { tab_pos.push(pos); } } // start with the tabs at the end of the line to replace them with 4 space chars for pos in tab_pos.iter().rev() { assert_eq!(line.remove(*pos), 't'); // fix the position of the style to match up after replacing the tabs let s = self.styles[line_pos].remove(*pos); for _ in 0..4 { line.insert(*pos, ' '); self.styles[line_pos].insert(*pos, s); } } } } </del> <ins> pub fn render(&self) -> Vec<Vec<StyledString>> { // Tabs are assumed to have been replaced by spaces in calling code. assert!(self.text.iter().all(|r| !r.contains(&'t'))); </ins> <del> pub fn render(&mut self) -> Vec<Vec<StyledString>> { </del> let mut output: Vec<Vec<StyledString>> = vec![]; let mut styled_vec: Vec<StyledString> = vec![]; <del> // before we render, replace tabs with spaces self.replace_tabs(); </del> for (row, row_style) in self.text.iter().zip(&self.styles) { let mut current_style = Style::NoStyle; let mut current_text = String::new();

Related discussion:
text: The code that truncates long lines doesn't take (hard) tabs into account, so the lines printed are off. Example code: Gives the following error: If you use four spaces instead of each tab it works as expected: cc and cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I thought we were already accounting for tabs, but looking we rely on which considers to not have a width, which we then assume to be 1.
claim
Code change:
<ins> // check-pass fn main() { println!("{:?}", { type T = (); pub fn cloneit(it: &'_ mut T) -> (&'_ mut T, &'_ mut T) where for<'any> &'any mut T: Clone, { (it.clone(), it) } }); } </ins>

Related discussion:
text: <!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --./src/test/ui/impl- or ./src/test/ui/impl-trait/issues/issue- <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailscc I believe this might be caused by
I'll look into it regardless
I was unable to reproduce same error perhaps it already fixed on stable channel try updating your rust compiler onto stable channel
the nightly that contains suspicious commit has not been released yet, there is no point in trying to reproduce this with nightly (or even stable). You'll need something that contains
This is the same issue that I identified in , but the bug identified and fixed in actually caused it to not be triggered until now. The issue here is a "trivial bound" () causing us to not select but in the MIR inliner. The caching bug actually caused the latter branch to happen everywhere, so when that bug was fixed, we started to normalize to in some places, causing this ICE. I bet I could trigger an ICE with a slight modification to this code using the inliner even with reverted. This is probably only triggered by the inliner, but the MIR inliner isn't enabled without being explicitly provided, right?
Code change:
<ins> // check-pass fn main() { println!("{:?}", { type T = (); pub fn cloneit(it: &'_ mut T) -> (&'_ mut T, &'_ mut T) where for<'any> &'any mut T: Clone, { (it.clone(), it) } }); } </ins>

Related discussion:
text: Trying to emulate trivial bounds via generics & associated types panics on stable, beta and nightly. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: Reproducible on beta and nightly <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Bug is not present in 1.51 and appears in 1.52. More precisely, it appeared somewhere between and .
Seems like introduces the regression Probably is the culprit
It seems to affect only traits that are checked by . Changing to fixes the panic.
I wonder if this could be fixed by normalizing the caller-bounds when checking for trivial bounds in WF. Hmm.... might think about this issue later tonight.
I'm putting up a PR soon to fix a whole bunch of impossible-bounds related things. So I'll claim this for the time being. claim
Code change:
("stable", Whitelisted, template!(List: r#"feature = "name", since = "version""#), Ungated), ("unstable", Whitelisted, template!(List: r#"feature = "name", reason = "...", issue = "N""#), Ungated), <del> ("deprecated", Normal, template!(Word, List: r#"/*opt*/ since = "version", /*opt*/ note = "reason"#, NameValueStr: "reason"), Ungated), </del> <ins> ("deprecated", Normal, template!( Word, List: r#"/*opt*/ since = "version", /*opt*/ note = "reason"#, NameValueStr: "reason" ), Ungated ), </ins> ("rustc_paren_sugar", Normal, template!(Word), Gated(Stability::Unstable, "unboxed_closures",

Related discussion:
text: Look for example to It is deprecated, and in source code there is hint what should be used instead: but in generated html documentation there is no hint about
isn't the correct syntax for the attribute. It should be . You can see it work: . This isn't a rustdoc issue. It's an issue with rustc that it doesn't reject .
Code change:
// We don't emit documentation for default items if they appear in the // Implementations on Foreign Types or Implementors sections. if rendering_params.show_default_items { <del> if let Some(t) = trait_ { </del> <ins> if let Some(t) = trait_ && !impl_.is_negative_trait_impl() { </ins> render_default_items( &mut default_impl_items, &mut impl_items, cx, t, <del> i.inner_impl(), </del> <ins> impl_, </ins> &i.impl_item, render_mode, rendering_params,

Related discussion:
text: <p align="center"<img width="400" src=""</pI would prefer if only the negative impl signature were rendered here (and any doc comment on the negative impl). Not even a collapsed-by-default accordion to show the trait's contents. The reader can click the trait's name to see what is in it if they need. Having associated items of a negative impl rendered is inconvenient because something like <kbdCTRL+F</kbdfor "fn position" will land the reader deep in the middle of the big impl showing them APIs that their type does not have. Example of this occurring in standard library documentation:  Mentioning tracking issue.
Code change:
param_mode: ParamMode, itctx: ImplTraitContext, ) -> hir::Ty<'hir> { <ins> // Check whether we should interpret this as a bare trait object. // This check mirrors the one in late resolution.  We only introduce this special case in // the rare occurence we need to lower `Fresh` anonymous lifetimes. // The other cases when a qpath should be opportunistically made a trait object are handled // by `ty_path`. if qself.is_none() && let Some(partial_res) = self.resolver.get_partial_res(t.id) && partial_res.unresolved_segments() == 0 && let Res::Def(DefKind::Trait | DefKind::TraitAlias, _) = partial_res.base_res() { let (bounds, lifetime_bound) = self.with_dyn_type_scope(true, |this| { let bound = this.lower_poly_trait_ref( &PolyTraitRef { bound_generic_params: vec![], trait_ref: TraitRef { path: path.clone(), ref_id: t.id }, span: t.span }, itctx, ); let bounds = this.arena.alloc_from_iter([bound]); let lifetime_bound = this.elided_dyn_bound(t.span); (bounds, lifetime_bound) }); let kind = hir::TyKind::TraitObject(bounds, lifetime_bound, TraitObjectSyntax::None); return hir::Ty { kind, span: self.lower_span(t.span), hir_id: self.next_id() }; } </ins> let id = self.lower_node_id(t.id); let qpath = self.lower_qpath(t.id, qself, path, param_mode, itctx); self.ty_path(id, t.span, qpath)

Related discussion:
text: <!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code with : I expected to see only warning without error, like this: Instead, this happened (extra error E0521 emitted, which is incorrect): If I add in line 3, it compiles without any error or warning: So the E0521 error emitted by the compiler is incorrect. The test code using should only produce warnings without an error. It most recently worked on: 1.63.0-nightly ( 2022-05-18) </p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --
labels:+T-compiler
label A-diagnostics
labels: +regression-from-stable-to-nightly
label -regression-untriaged Bisection: regressed nightly: nightly-2022-06-23 searched commit range: regressed commit: that’s , cc
Seems like, possibly, the code without the explicit (incorrectly) desugars to rather than Edit: Or perhaps it incorrectly desugars to
Here’s another kind of code example that reproduces the issue Which does confirm the idea that this appears to be interpreted like , rather than which would be correct.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Code change:
param_mode: ParamMode, itctx: ImplTraitContext, ) -> hir::Ty<'hir> { <ins> // Check whether we should interpret this as a bare trait object. // This check mirrors the one in late resolution.  We only introduce this special case in // the rare occurence we need to lower `Fresh` anonymous lifetimes. // The other cases when a qpath should be opportunistically made a trait object are handled // by `ty_path`. if qself.is_none() && let Some(partial_res) = self.resolver.get_partial_res(t.id) && partial_res.unresolved_segments() == 0 && let Res::Def(DefKind::Trait | DefKind::TraitAlias, _) = partial_res.base_res() { let (bounds, lifetime_bound) = self.with_dyn_type_scope(true, |this| { let bound = this.lower_poly_trait_ref( &PolyTraitRef { bound_generic_params: vec![], trait_ref: TraitRef { path: path.clone(), ref_id: t.id }, span: t.span }, itctx, ); let bounds = this.arena.alloc_from_iter([bound]); let lifetime_bound = this.elided_dyn_bound(t.span); (bounds, lifetime_bound) }); let kind = hir::TyKind::TraitObject(bounds, lifetime_bound, TraitObjectSyntax::None); return hir::Ty { kind, span: self.lower_span(t.span), hir_id: self.next_id() }; } </ins> let id = self.lower_node_id(t.id); let qpath = self.lower_qpath(t.id, qself, path, param_mode, itctx); self.ty_path(id, t.span, qpath)

Related discussion:
text: ndarray 0.9.1 compiles with rustc 1.61.0 but not with rustc 1.64.0-nightly ( 2022-06-27). Put this into a of a new project: rustc stable <= 1.61.0 compiles the crate fine, rustc nightly gives the following error: modify labels: +regression-from-stable-to-nightly -regression-untriaged
Just adding a note. The issue seems to be an old version of that used to use back in v0.9.1 <details</detailsThe crate from v0.13.0 (released in sept. 2019) compiles fine also on latest Rust nightly
bisection seems to point to commit cc searched nightlies: from nightly-2022-04-01 to nightly-2022-06-28 regressed nightly: nightly-2022-06-23 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details(unsure if this regression may hit other more recent crates)
I've been suspecting this bug for a few days, but unable to reproduce it. I think I have a patch, will confirm once I manage to MCVE.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Code change:
match MyOption::MySome(42) { MyOption::MySome { x: 42 } => (), //~^ ERROR variant `MyOption::MySome` does not have a field named `x` <del> //~| ERROR pattern does not mention field `0` </del> _ => (), } }

Related discussion:
text: With a single typo in a match arm, we generate three separate errors: We should collect all these errors into a single diagnostic:
could you share sample code to exactly reproduce above diagnostic?
I will raise another PR to address the case where we are unnecessarily throwing .
Code change:
/// /// Run a future to completion on the current thread. /// fn block_on<T>(fut: impl Future<Output = T>) -> T { ///     // Pin the future so it can be polled. <del> ///     let mut fut = Box::pin(fut); </del> <ins> ///     let mut fut = pin!(fut); </ins> /// ///     // Create a new context to be passed to the future. ///     let t = thread::current();

Related discussion:
text: The example currently uses , but now that the macro has been stabilized in , it should probably use that instead. This should be an easy contribution for someone who wants to land a first contribution. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
hey can u help me from where i can fix this
Can u tell me how u solve this?
I have already solved this one and it is in the process of being reviewed for merging. If you wish to solve an issue, you need to pick one that has not been assigned yet. Try looking at this:
hey im new to open source, i want to grow in this field . Can i contact with u ?
I am pretty new to this project myself, but please reach out if you have any starter-questions and then I might be able to help you out. There is a chat on https://rust- - I am just "Mads Ravn" in there.
Thanks