jiebi/CodeConvo huggingface dataset:
Code change:
/// Composite function which sets LLVM attributes for function depending on its AST (#[attribute]) /// attributes. <del> pub fn from_fn_attrs(cx: &CodegenCx<'ll, '_>, llfn: &'ll Value, id: DefId) { let codegen_fn_attrs = cx.tcx.codegen_fn_attrs(id); </del> <ins> pub fn from_fn_attrs( cx: &CodegenCx<'ll, '_>, llfn: &'ll Value, id: Option<DefId>, ) { let codegen_fn_attrs = id.map(|id| cx.tcx.codegen_fn_attrs(id)) .unwrap_or(CodegenFnAttrs::new()); </ins> inline(llfn, codegen_fn_attrs.inline); <ins> // The `uwtable` attribute according to LLVM is: // //     This attribute indicates that the ABI being targeted requires that an //     unwind table entry be produced for this function even if we can show //     that no exceptions passes by it. This is normally the case for the //     ELF x86-64 abi, but it can be disabled for some compilation units. // // Typically when we're compiling with `-C panic=abort` (which implies this // `no_landing_pads` check) we don't need `uwtable` because we can't // generate any exceptions! On Windows, however, exceptions include other // events such as illegal instructions, segfaults, etc. This means that on // Windows we end up still needing the `uwtable` attribute even if the `-C // panic=abort` flag is passed. // // You can also find more info on why Windows is whitelisted here in: //      https://bugzilla.mozilla.org/show_bug.cgi?id=1302078 if !cx.sess().no_landing_pads() || cx.sess().target.target.options.requires_uwtable { attributes::emit_uwtable(llfn, true); } </ins> set_frame_pointer_elimination(cx, llfn); set_probestack(cx, llfn);

Related discussion:
text: and are both broken on s390x since Rust 1.28. When is built without debuginfo, the tests hang with their backtracing processes stuck in a loop. With debuginfo, it fails with output like: I believe the problem is this part of : where doesn't identify that is a 64-bit platform. See also alexcrichton/backtrace-rs. I plan to update that here when it's published, and make a similar fix in .
fixes the backtrace when is built with debuginfo, but I'm still getting a hang without. In GDB, it looks like the unwinder gets to the that catches panics, then loops unwinding that same PC forever. This part of the regression is older -- happens on 1.27.2 as well, but 1.26.2 is fine. Binaries from the older version don't appear to have a distinct symbol at all, but maybe that's just inlined differently. I'm bisecting for that hang now.
Bisecting pointed me at (cc which attributes to all functions. For s390x the base features actually include a removal, . But it doesn't look like the features are applied to the synthesized (), and as a result it doesn't get inlined anymore since it has more features (w/ ) than the callee. We probably should apply target-features to as well. I don't know why the non-inlined can't be unwound -- maybe we need to force ? By default GDB backtrace stops at crate , but tries to go further: Maybe Rust's could have a similar defensive check, at least.
Nice find Definitely makes sense to me, and this should be fixed up (at least the business) in
With , , and , I believe we have this fixed.
Code change:
<ins> error[E0785]: cannot define inherent `impl` for a dyn auto trait --> $DIR/issue-85026.rs:5:6 | LL | impl dyn AutoTrait {} |      ^^^^^^^^^^^^^ impl requires at least one non-auto trait | = note: define and implement a new trait or type instead error[E0785]: cannot define inherent `impl` for a dyn auto trait --> $DIR/issue-85026.rs:8:6 | LL | impl dyn Unpin {} |      ^^^^^^^^^ impl requires at least one non-auto trait | = note: define and implement a new trait or type instead error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0785`. </ins>

Related discussion:
text: Given the following code (): The current output is: This is rather confusing. It's not immediately clear what the difference between and this working code is (): Since is accepted, the user might be confused why would be considered a nominal type when isn't. The real reason why is an error is because it is an block for . Ideally the output should look like:
It seems like this only happens with auto traits. Regular traits already emit E0116 in this case (): Note that this still happens with auto traits in the same crate, but in this case wouldn't be applicable (): The diagnostic is still confusing in this case and could be rewritten to explicitly point out that is not allowed. modify labels: +D-confusing +F-auto_traits
Code change:
<del> error[E0277]: the trait bound `&'static mut (): Clone` is not satisfied --> $DIR/issue-93008.rs:5:5 | LL |     &'static mut (): Clone, |     ^^^^^^^^^^^^^^^^^^^^^^ the trait `Clone` is not implemented for `&'static mut ()` | = help: see issue #48214 = help: add `#![feature(trivial_bounds)]` to the crate attributes to enable error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </del>

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:
<del> error[E0277]: the trait bound `&'static mut (): Clone` is not satisfied --> $DIR/issue-93008.rs:5:5 | LL |     &'static mut (): Clone, |     ^^^^^^^^^^^^^^^^^^^^^^ the trait `Clone` is not implemented for `&'static mut ()` | = help: see issue #48214 = help: add `#![feature(trivial_bounds)]` to the crate attributes to enable error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </del>

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:
Some(f) => f, None => return DummyResult::any(sp) }; <del> let file = cx.resolve_path(file, sp); </del> <ins> let file = match cx.resolve_path(file, sp) { Ok(f) => f, Err(mut err) => { err.emit(); return DummyResult::any(sp); }, }; </ins> match cx.source_map().load_binary_file(&file) { Ok(bytes) => { base::MacEager::expr(cx.expr_lit(sp, ast::LitKind::ByteStr(Lrc::new(bytes))))

Related discussion:
text: to reproduce the fault this can be used: will result in this ICE: thread 'rustc' panicked at 'cannot resolve relative path in non-file source ', note: Run with RUSTBACKTRACE=1 environment variable to display a backtrace. error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: rustc 1.36.0 ( 2019-07-03) running on x86_64-unknown-linux-gnu the question is what is the path that shall be used when the code is from stdin maybe some temp file name in the currrent working dir.
This ICE also occurs when using and , which makes sense as they use the same mechanism under the hood (, , meaning it also .
While poking at this I also noticed that items are silently ignored, and filed .
Code change:
return Success(PrefixFound(containing_module, i)); } <ins> fn resolve_crate_var(&mut self, mut crate_var_ctxt: SyntaxContext) -> Module<'a> { while crate_var_ctxt.source().0 != SyntaxContext::empty() { crate_var_ctxt = crate_var_ctxt.source().0; } let module = self.invocations[&crate_var_ctxt.source().1].module.get(); if module.is_local() { self.graph_root } else { module } } </ins> // AST resolution // // We maintain a list of value ribs and type ribs.

Related discussion:
text: When on latest rust nightly , you get an ICE when compiling .
Its a pretty recent regression, it can't be reproduced with .
Okay, managed to minimize it: Looks like a regression of . cc any ideas on this?
Yeah, this was caused by an oversight in -- fixed in .
Code change:
<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { let a = std::sys::imp::process::process_common::StdioPipes { ..panic!() }; //~^ ERROR failed to resolve. Could not find `imp` in `sys` [E0433] //~^^ ERROR module `sys` is private [E0603] } </ins>

Related discussion:
text: I was playing around with some code which can be found and is attached below. When I click on output I get the following output: I don't have a rust installation locally right now, so I cannot create the backtrace. I'll add it later today. The code which triggers this:
Stack trace: (There is no ICE with (nothing generated either due to type error). Perhaps playpen should use instead.)
You can get backtrace on playpen here: !
Looks like this has been fixed recently
Code change:
<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { let a = std::sys::imp::process::process_common::StdioPipes { ..panic!() }; //~^ ERROR failed to resolve. Could not find `imp` in `sys` [E0433] //~^^ ERROR module `sys` is private [E0603] } </ins>

Related discussion:
text: I was in the middle of making a big changes to some code when this panic occurred. I was expecting a lot of compiler errors but got a compiler panic instead! :fearful: I ran the build with and the panic still occurred. Run to get this. Here's the full output with : Since I was in the middle of editing, there's no commit to point to, so I just attached my source code as is so you have something to debug. When you download it and run , the compiler should panic. The repo is called . I don't know how to narrow this issue down, or else I would try to find a smaller example for you. Hope this is good enough.
Some context for the change that caused this: Before this error happened, I changed the file . I split into two structs, and . I was relying on the compiler to find all the places where that change would effect things, and it seems that something went wrong in the compiler while trying to do that.
Once I fix that, everything works again. No more compiler panic. So it seems to have something to do with when I split up that struct. All the messed up pattern matches caused a panic. (Actually just fixing 2 broken pattern matches fixed the problem.)
I've just encountered this myself. I managed to reduce it down: It looks like this happens when a closure's body is a single (non-block) expression, and a tuple struct pattern is used somewhere in the expression. A simple workaround (if anyone needs one for some reason), then, is to just make the closure body a block:
Code change:
<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { let a = std::sys::imp::process::process_common::StdioPipes { ..panic!() }; //~^ ERROR failed to resolve. Could not find `imp` in `sys` [E0433] //~^^ ERROR module `sys` is private [E0603] } </ins>

Related discussion:
text: Related code: Compiler panic: Note that everything is fine if I annotate the lifetimes: I am running , the MSVC x64 version.
I just ran into this. Managed to reduce the crash to Explicit lifetimes indeed fix it:
don't know if this helps, but I came up with minimal test case
Code change:
<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { let a = std::sys::imp::process::process_common::StdioPipes { ..panic!() }; //~^ ERROR failed to resolve. Could not find `imp` in `sys` [E0433] //~^^ ERROR module `sys` is private [E0603] } </ins>

Related discussion:
text: Playground Output: Other example (possibly different bug): Output:
I just got the same ICE on linux with both the and builds. My case is essentially the same. You create an iterator of references to sub-elements of some thing which has been passed in by reference. The compiler should figure out that the iterator can only live as long as the original object, but ICEs instead. ()
Code change:
<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { let a = std::sys::imp::process::process_common::StdioPipes { ..panic!() }; //~^ ERROR failed to resolve. Could not find `imp` in `sys` [E0433] //~^^ ERROR module `sys` is private [E0603] } </ins>

Related discussion:
text: Spawned off of There are still some cases where referencing an inaccessible item can cause the compiler to ICE. Here is one crafted example () but if 's module structure is revised then that example may fail to compile without ICE'ing for other reasons, so take care in understanding the issue: the change introduced by is skipping the requirement for stability attributes is slightly too narrow, in that it uses a local notion of pub/non-pub instead of overall accessibility. One simple solution to this may be to just follow the suggestion here and just remove the assertion entirely. (I did not want to adopt that solution for a PR to be backported to beta, but I think it is worth considering doing in nightly alone to resolve this low priority issue.)
Keywords: for better search
Code change:
Change this file to make users of the `download-ci-llvm` configuration download a new version of LLVM from CI, even if the LLVM submodule hasn’t changed. <del> Last change is for: https://github.com/rust-lang/rust/pull/109373 </del> <ins> Last change is for: https://github.com/rust-lang/rust/pull/96971 </ins>

Related discussion:
text: I tried this code: I expected to see this happen: rustc prints the target spec successfully, because it knows it exists: Instead, this happened: rustc fails to load the LLVM specification: Note that this is different from the error we emit for an unrecognized target: Also, this only happens for local builds, because we don't use the LLVM in the component in rustup, only when building rustc from source. ... wtf ??? HEAD is branched from
cc do you know what could be going wrong here?
Thank you for bringing this to my attention. It is possible that the locally builds has enabled , and that prebuilt LLVM does not support LoongArch architecture. It would be great if you could provide specific steps to reproduce. Thank you.
Yes, that's exactly what's happened, I have download-ci-llvm enabled and the prebuilt LLVM differs. Here's steps to reproduce:
The RustDev component builds LLVM here: but I'm not sure how that differs from the component?
I think the difference is that the of ci-llvm does not contain LoongArch, but locally it does. Is it time to update ci-llvm?
Maybe need to bump download-ci-llvm-stamp to pick up the LoongArch enablement?
Thank you for catching that. I was mistaken to think that the cached prebuilt ci-llvm would automatically update over time.
no worries :) it updates every six weeks when we make a new release, or if the submodule is updated, but it's cached until then so it's not constantly re-uploaded on every change to bootstrap.
Is there any way CI could help prevent such problems? Like, complain if gets changed but the stamp file does not, or something like that?
we can use heuristics, but they're only heuristics and I wouldn't want to fail CI on them. That said, having rustbot leave a comment if you touch rustc_llvm or seems reasonable, so the PR author can make a judgement call but also doesn't forget about the stamp.
Code change:
document(w, cx, it)?; if !e.variants.is_empty() { <del> write!(w, "<h2 id='variants' class='variants'>Variants</h2>n")?; </del> <ins> write!(w, "<h2 id='variants' class='variants section-header'> <a href='#variants'>Variants</a></h2>n")?; </ins> for variant in &e.variants { let id = derive_id(format!("{}.{}", ItemType::Variant,

Related discussion:
text: A page like has many things that could be useful to link to. These should be possible to link to by clicking on: [x] The header [x] 's on a page. [x] at the top On it's hit or miss: [x] Examples [x] Associated Types [x] Required Methods [x] Implementors On [x] Provided Methods I don't have any big use cases but when I want to link to these for something like this bug I can't link to any specific line. I gotta say go to vec page, scroll 75% to bottom. Squint hard to see it.
Just ran into this today; I'd really like to have links from the impls in the Implementors section to the source containing the impl.
Triage: we always need more links....
Update: Headers written in docs and (most) auto-generated headers are either fully hyperlinked or have a "section marker" symbol that shows up on hover. Major auto-generated page headers have links in the top of the sidebar of the page. Impl blocks do not have hyperlinks (yet); that's
Since got merged and closed out , that was the last major request on this issue, so i'll close this out. If you think of something else that needs a hyperlinked header, feel free to open a new issue or reopen this one.
Code change:
} } <ins> fn replace_tabs(str: &str) -> String { str.replace('t', "    ") } </ins> fn draw_col_separator(buffer: &mut StyledBuffer, line: usize, col: usize) { buffer.puts(line, col, "| ", Style::LineNumber); }

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:
if w > 2 { val = utf8_acc_cont_byte!(val, s[i + 2]); } if w > 3 { val = utf8_acc_cont_byte!(val, s[i + 3]); } <del> return CharRange {ch: unsafe { transmute(val as u32) }, next: i + w}; </del> <ins> return CharRange {ch: unsafe { transmute(val) }, next: i + w}; </ins> } return multibyte_char_range_at(*self, i);

Related discussion:
text: We need some way to interpret a as UTF-8, using the replacement character for invalid sequences instead of conditions. This would ideally be provided in the form of an .
Could we remove the current condition API in favour of this? It doesn't really seem to offer anything but failing, and we already have an API returning an .
I would be quite pleased if we could do that. Using the condition is rather awkward, and I would rather just have replacement chars myself.
This is a duplicate of , no?
And also the e-mail thread here I think is relevant:
This is an implementation of a mostly complete → UTF-8 decoder
It's only a duplicate if the intended resolution of is to use the replacement char instead of conditions, but it's unclear from the discussion if that's the plan.
I guess my thinking was that a maximally expressive condition-based solution would let one express a replacement char approach using conditions. But I don't actually favor doing that at this point. Or at least, I don't favor making that the only way to accomplish this, since I suspect a more specialized approach will be much nicer to use (both in terms of programmer convenience and in terms of efficiency). So okay, this is not a duplicate of .
Rust needs to support both fatal and replacement error handling modes, it should follow the WHATWG spec simonsapin has said (edit by is WHATWG spec.)
the fatal mode is already handled by the API
well, the current functions in str don't handle decoding buffers in chunks like the proposed encodings API. But yes, it does handle one-off decoding with 'fatal' error handling.
I think we need to improve/extend our API along the lines suggested here for 1.0. Nominating for P-backcompat-lang. (Arguably we could avoid the backwards compatibility hazard by offering a fail-only method for 1.0 and then adding an alternative entry point that provides the more flexible API supporting replacement characters in post 1.0. But I think this case is important enough that we should try to get the primary API method to provide both choices up front. That, or put dynamic fluid support in for representing the state of that choice.)
I submitted a PR for this last night, although I forgot there was an open issue too so I didn't link them. The PR is