jiebi/CodeConvo huggingface dataset:
Change:
fn clone(&self) -> Box<rtio::RtioTcpStream + Send> { box TcpWatcher { handle: self.handle, <del> stream: StreamWatcher::new(self.handle), </del> <ins> stream: StreamWatcher::new(self.handle, false), </ins> home: self.home.clone(), refcount: self.refcount.clone(), read_access: self.read_access.clone(),

Discussion:
When using libgreen on Windows (verified not to occur with libnative) when I'm reading from a TcpStream and the remote host closes the stream (specifically I'm closing the client by pressing ctrl + c), the server silently terminates with no error messages. It appears SIGSEGV is being called. The code I was writing which caused this issue can be found here: Using Windows 8.1 x64 with latest Rust nightly. Attempts to backtrace using gdb have failed:
cc
I have acquired a backtrace by attaching gdb to a running process rather than running the process from gdb to begin with (why this works I have no idea)
After debugging with visual studio I figured out the exact line causing the segfault. At it is . here is a null reference, which was transmuted from getting the data of the handle, which is apparently 0. I don't know what is setting it to 0 though.
It appears even sending packets to the connection causes it to die. Has anyone even tested libgreen on Windows with TCP?
I have determined the cause of the bug to be a race condition. Specifically every time I open up a connection, is called 3 times and is called once. If the 3 new streams all occur before the read call, the pointer remains non-zero. If one of them occurs after the read call, then the pointer becomes zero, and the read callback segfaults. I have verified this through multiple runs and statements everywhere.
To further expand, is called when a TcpStream is created, and also everytime I clone the . Since cloning a is the only way to share it across tasks (it doesn't impl ), I had to spawn two tasks, one to read and one to write. Because I spawned the reading one first it would start a read before I cloned the tcp for the writing task, and once I cloned it, the data pointer got reset so the data pointer the read callback received was null thereby causing the segfault.
Yes, no commit gets pushed to master unless it passes all tests on windows, and that includes many networking tests. Do you have a small test case which reproduces this bug? It's likely that there's just some different callback-invoking behavior on windows than on unix that was accidentally not dealt with.
Here is a minimal code example:
Change:
extern "C" { fn g_free(p: *mut ()); } <ins> #[link(name = "glib-2.0")] extern "C" { fn g_free2(p: *mut ()); } </ins>

Discussion:
Hi there, In we use to try and keep our crate's linking instructions up-to-date across supported platforms. We've noticed that in some build configurations the output can change in surprising ways. For instance, using rustc nightly (1.70.0) on Windows (x8664-pc-windows-msvc) in a configuration driven by we see many consecutive duplicate libraries in the output. I understand duplicates are to be expected, and can be meaningful on some platforms, but seeing so many consecutive repeats seems unexpected and unlikely to be meaningful for the build process. Is this perhaps a regression? Or are we making a mistake by relying on the stability of this output across versions/build configurations? This feature is as having a known prefix to "make it easier to fetch the output." leading to the idea that it is expected to be machine consumable. I tried this code: I expected to see this happen: A list produced, with some duplicates (e.g. multiple ), but not many consecutive duplicates. E.g.: Instead, this happened: A list with many consecutive duplicates is produced: </detailsrustc nightly (1.70.0) on Windows (x8664-pc-windows-msvc) in a configuration. rustc nightly (1.70.0) on Windows (x8664-pc-windows-msvc) in a configuration. Project: Build task: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Hm, I thought we usually removed consecutive duplicates but apparently only in release. A workaround would be to do so manually. For the msvc targets all duplicates can be removed so long as the order is preserved. This isn't true of many other targets though. It would be much better to have a proper fix though.
Thanks for the quick reply :-) That's we landed on for the short term :+1: Great, thanks for clarifying.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
claim
Error: Parsing assign command in failed: ...' assign' ''... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
Thanks !
Change:
return tcx.has_typeck_tables(outer_def_id); } <del> let id = tcx.hir().as_local_hir_id(def_id).unwrap(); primary_body_of(tcx, id).is_some() </del> <ins> if let Some(id) = tcx.hir().as_local_hir_id(def_id) { primary_body_of(tcx, id).is_some() } else { false } </ins> } fn used_trait_imports(tcx: TyCtxt<'_>, def_id: DefId) -> &DefIdSet {

Discussion:
When running in the subdirectory, a call to with causes the following ICE: I'm not exactly sure what additional information to provide? I filed an issue with , and was forwarded here since it is an ICE.
I've minimized it a bit: It still uses external crates but the example itself is very small.
compile it with: Although is behind a feature gate it will ICE without the feature gate! modify labels: F-typealiasimpltrait ICE code:
Change:
error: use of unstable library feature 'test': `bench` is a part of custom test frameworks which are unstable <del> --> $DIR/bench.rs:1:3 </del> <ins> --> $DIR/bench.rs:3:3 </ins> | LL | #[bench] |   ^^^^^

Discussion:
Hi there, I'm updating rust-sgx-sdk (solving rust-sgx-sdk ) to use latest rust nightly compiler to help the error info more ergonomic by the help of . However, the compiler always panics. Your help would be very much helpful. The current code is at . To reproduce this bug, please checkout branch and build sgxtstd as follows: And the reproducible failure info is: : rustc 1.40.0-nightly ( 2019-10-03) binary: rustc commit-hash: commit-date: 2019-10-03 host: x8664-unknown-linux-gnu release: 1.40.0-nightly LLVM version: 9.0 Backtrace:
It'd be helpful to have a more minimal example here I suspect -- for example, at least reducing to a single crate. cc since this deals with diagnostic machinery
It seems like this was introduced a month ago in , CC
I think I find the solution on my side: the removal of .
A working branch is baidu/rust-sgx-sdk : test-2019-10. Failing branch is librustc-bug-report. After I enable , the compiler starts to fail.
The minimum sample is as follows: and compile by
Fixed in
Cool!
Change:
.question-mark { color: #ff9011; } </style> "#; <ins> #[test] fn test_html_highlighting() { let src = include_str!("fixtures/sample.rs"); let html = { let mut out = String::new(); write_code(&mut out, src); format!("{}<pre><code>{}</code></pre>n", STYLE, out) }; expect_file!["fixtures/sample.html"].assert_eq(&html); } #[test] fn test_dos_backline() { let src = "pub fn foo() {rn println!("foo");rn }rn"; let mut html = String::new(); write_code(&mut html, src); expect_file!["fixtures/dos_line.html"].assert_eq(&html); } </ins>

Discussion:
I tried to document and publish my Windows crate to github pages. Things went pretty smooth until I opened the source code view. As you can see below, a newline is appended to each line doc comment, also no line number for each line: ! Here the render page on gh-pages: Beware that it has no version control for the generated doc. But the link here may work for a limited time before github purge the cache: Also here the the CI script I used: The same code published on is normal: : x86_64-pc-windows-msvc rustc 1.48.0-nightly ( 2020-09-04) modify labels: T-rustdoc
Could be related to normalization depending on the git checkout settings of the runner.
I set before , maybe this is my misconfigure somehow.
Try adding and possibly to make those files end with the right character.
Thanks Andy, I tried as you told but still the issue remains.
Oh, I meant for the source files, you might need to reconfigure git before checking out the source (and that's likely just a workaround, this seems likely to be a bug in rustdoc's handling of in source files).
Thank you, problem is solved in . I am pretty sure this issue is a duplicate of another, but I cannot find it. You could close this issue if you see fit.
(keywords cause I keep failing to search for this: dos line endings)
This is a recent regression, it was introduced sometime between and . I suspect is related, cc
The issue is that is being marked as a doc-comment:
I guess this means is being marked as a ? I don't see why it would.
My test was wrong.
This is not actually correct - it was a blank line in the original source code. The issue is that rustdoc used to strip in newlines, but no longer does. Here's 1.47: and 1.48:
Change:
return self.lower_path_ty(t, qself, path, ParamMode::Explicit, itctx); } TyKind::ImplicitSelf => { <del> let hir_id = self.lower_node_id(t.id); </del> <ins> let hir_id = self.next_id(); </ins> let res = self.expect_full_res(t.id); let res = self.lower_res(res); hir::TyKind::Path(hir::QPath::Resolved(

Discussion:
<!-- 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 rustc this runs in a couple ms: with rustc this seems to hang somewhere in ( I killed the process after waiting for 5 minutes :upsidedownface: )
reduced: RIP
I think this is caused by cc
Clearly a well tested feature :stuckouttongue: I'll take a look.
The old code looked like this: The new code looks like this: because is no longer optional. The infinite recursion happens because the call returns a that is the same as the . When I printed that ID out it looks like this: An easy fix is to check if is the same as and return if so. But I don't know if that's just papering over a deeper problem. Is it an underlying bug that can return the same node it is given?
Change:
assert_eq!(&*rc2, cstr); assert_eq!(&*arc2, cstr); } <ins> #[test] fn cstr_const_constructor() { const CSTR: &'static CStr = unsafe { CStr::from_bytes_with_nul_unchecked(b"Hello, world!0") }; assert_eq!(CSTR.to_str().unwrap(), "Hello, world!"); } </ins> }

Discussion:
The current implementation of is not valid in a const context, but it can easily be tweaked so that it is:
At this point you can just enable the feature gate and use . There's no need for unions anymore
I thought was explicitly not going to become as per the discussion in .
Alternatively, why can't we make DST constructors work for simple wrappers like this? Why can't it be, e.g. &CStr{ bytes: *bytes } Where it looks kind of like the opposite of a deref coercion, and the compiler just reinterprets the fat pointer? This would eliminate the need for any besides what's necessary for the API contract.
Yes I would like such constructors, too. But that needs and RFC and probably has a lot of caveats that we want to think about. I did not know about that issue. I commented there.
Change:
<del> Subproject commit 47848665966fc7393cb6f898077994f6dec2b591 </del> <ins> Subproject commit c9e2e89ed3aa5a3be77143aa0c86906b4138374a </ins>

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: runs infinitely Instead, this happened: return directly The is set to :
According to and , rustc doesn't emit , which means the loop generated by the tail call shouldn't be removed(I guess).
This was apparently working in 1.58 and regressed in 1.59. label regression-from-stable-to-stable
Small reproducer:
From a cursory look, probably due to:
From cargo bisect: Probably related to
I'm tagging this as , as discussed in the . The following reproduction is concerning: This exits with an , which is not good. Presumably, is returning even though it returns . One of many ways in which this can likely be unsound.
Upstream fix: Upstream backport issue:
Reopening to beta-nominate. This regression is a nasty miscompilation that can silently induce unsoundness in valid code, given a certain opt-level setting, and is not platform-specific. The patch to LLVM to fix this is quite small:
As per T-compiler meeting (), lowering priority of this issue since has been there for a long time and the "illegal hardware instruction" mentioned is the we generate intentionally here. label +P-high -P-critical
Closing this as the beta backport has happened.
Change:
let self_and_input_tys: Vec<Ty> = self_ty.into_iter().chain(input_tys).collect(); <del> let mut lifetimes_for_params: Vec<(String, Vec<ty::Region>)> = Vec::new(); </del> // Second, if there was exactly one lifetime (either a substitution or a // reference) in the arguments, then any anonymous regions in the output // have that lifetime. <del> if implied_output_region.is_none() { let mut self_and_input_tys_iter = self_and_input_tys.iter(); if self_ty.is_some() { </del> <ins> let lifetimes_for_params = if implied_output_region.is_none() { let input_tys = if self_ty.is_some() { </ins> // Skip the first argument if `self` is present. <del> drop(self_and_input_tys_iter.next()) } for (input_type, input_pat) in self_and_input_tys_iter.zip(input_pats.into_iter()) { let mut accumulator = Vec::new(); ty::accumulate_lifetimes_in_type(&mut accumulator, *input_type); lifetimes_for_params.push((input_pat, accumulator)); } if lifetimes_for_params.iter().map(|&(_, ref x)| x.len()).sum() == 1 { implied_output_region = Some(lifetimes_for_params.iter() .filter_map(|&(_, ref x)| if x.len() == 1 { Some(x[0]) } else { None }) .next().unwrap()); } } </del> <ins> self_and_input_tys.slice_from(1) } else { self_and_input_tys.slice_from(0) }; </ins> <del> let param_lifetimes: Vec<(String, uint)> = lifetimes_for_params.into_iter() .map(|(n, v)| (n, v.len())) .filter(|&(_, l)| l != 0) .collect(); </del> <ins> let (ior, lfp) = find_implied_output_region(input_tys, input_pats); implied_output_region = ior; lfp } else { vec![] }; </ins> let output_ty = match decl.output { ast::Return(ref output) if output.node == ast::TyInfer => ty::FnConverging(this.ty_infer(output.span)), ast::Return(ref output) => <del> ty::FnConverging(match implied_output_region { Some(implied_output_region) => { let rb = SpecificRscope::new(implied_output_region); ast_ty_to_ty(this, &rb, &**output) } None => { // All regions must be explicitly specified in the output // if the lifetime elision rules do not apply. This saves // the user from potentially-confusing errors. let rb = UnelidableRscope::new(param_lifetimes); ast_ty_to_ty(this, &rb, &**output) } }), </del> <ins> ty::FnConverging(convert_ty_with_lifetime_elision(this, implied_output_region, lifetimes_for_params, &**output)), </ins> ast::NoReturn(_) => ty::FnDiverging };

Discussion:
HRTB doesn't correctly implement lifetime elision for notation. See the test .
Nominating.
notes that this can be fixed backwards compatibly, and agrees. P-high, not 1.0.
Well, sort of -- I mean lifetime elision broke code, but almost only bad code. The problem is that people can use to satisfy the signature and then clients get to assume any lifetime they want.
Change:
// used generic parameters is a bug of evaluation, so checking for it // here does feel somewhat sensible. if !self.features().generic_const_exprs && ct.substs.has_non_region_param() { <del> assert!(matches!(self.def_kind(ct.def), DefKind::AnonConst)); </del> <ins> assert!(matches!( self.def_kind(ct.def), DefKind::InlineConst | DefKind::AnonConst )); </ins> let mir_body = self.mir_for_ctfe(ct.def); if mir_body.is_polymorphic { let Some(local_def_id) = ct.def.as_local() else { return };

Discussion:
<!-- 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. --interestingly the code compiles as soon as I remove and just make it a boring <!-- 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</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regression in nightly-2023-06-01 Regression in cc
just needs to check for inline const along with anon consts in
claim do you mean literally just adding ? Seems to fix the ICE on my end
Change:
let st = match style { ast::StrStyle::Cooked => (format!(""{}"", st.escape_debug())), ast::StrStyle::Raw(n) => { <del> (format!( "r{delim}"{string}"{delim}", delim = "#".repeat(n as usize), string = st )) </del> <ins> format!("r{delim}"{string}"{delim}", delim = "#".repeat(n as usize), string = st) </ins> } }; self.word(st)

Discussion:
I'd be interested in handling this. Looking at , it looks fairly straightforward -- however it does look like there could be some ambiguity with return values in blocks (e.g. ) Would we want to disambiguate lints, or would it be fine to use the same lint diagnostic for both cases?
what sort of ambiguity do you mean? I'd expect a single lint on in your example (note that we about unused ).
To use your original example, Both and are , since they represent the implicit return at the end of a block. I was wondering if we'd care about the case, and if we did, if it made sense to treat it the same as . If you naively add a match arm to the visitor, you get the same diagnostic for both.
Yes, both and should be linted here.
Change:
adj ), ); <ins> *entry.get_mut() = adj; </ins> } } <del> *entry.get_mut() = adj; </del> } }

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: broken MIR in DefId(0:20 ~ o[fbbd]::{impl}::eq) (Terminator { sourceinfo: SourceInfo { span: 7:10 (), scope: scope[3] }, kind: 21 = <! as PartialEq::eq(move 22, move 23) -[return: bb9, unwind: bb18] }): bad arg (&'?38 ! <- !): NoSolution', 'error: internal compiler error: broken MIR in DefId(0:20 ~ o[fbbd]::{impl}::eq) (Terminator { sourceinfo: SourceInfo { span: 7:10 (), scope: scope[3] }, kind: 21 = <! as PartialEq::eq(move 22, move 23) -[return: bb9, unwind: bb18] }): bad arg (&'?38 ! <- !): NoSolution' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: error: internal compiler error: broken MIR in DefId(0:20 ~ mvce[954a]::{impl}::eq) (Terminator { sourceinfo: SourceInfo { span: 7:10 (), scope: scope[3] }, kind: 21 = <! as PartialEq::eq(move 22, move _23) -[return: bb9, unwind: bb18] }): bad arg (&'?38 ! <- !

): NoSolution --
Regression in nightly-2023-05-23 commit[0] 2023-05-21: Auto merge of - MU001999:fix/issue-, r=cjgillot commit[1] 2023-05-21: Auto merge of - Zoxc:query-structs-trim, r=cjgillot commit[2] 2023-05-22: Auto merge of - lukas-code:strike, r=notriddle commit[3] 2023-05-22: Auto merge of - the8472:filter-map-chunk, r=thomcc commit[4] 2023-05-22: Auto merge of - matthiaskrgr:rollup-qd4b2vu, r=matthiaskrgr commit[5] 2023-05-22: Auto merge of - Jules-Bertholet:document-pin-layout, r=thomcc commit[6] 2023-05-22: Auto merge of - compiler-errors:triple-check, r=Nilstrieb commit[7] 2023-05-22: Auto merge of - marc0246:arc-new-uninit-bloat, r=thomcc commit[8] 2023-05-22: Auto merge of - lcnr:recursion-depth, r=matthewjasper commit[9] 2023-05-22: Auto merge of - Dylan-DPC:rollup-7jqydzg, r=Dylan-DPC ERROR: no CI builds available between and within last 167 days cc
Minimized:
Minimized even more: (I independently found the same bug while running crater with the fallback being )
Change:
// option. This file may not be copied, modified, or distributed // except according to those terms. <del> #![allow(non_upper_case_globals)] pub const box_field_refcnt: uint = 0u; pub const box_field_drop_glue: uint = 1u; pub const box_field_body: uint = 4u; </del> <ins> pub const BOX_FIELD_DROP_GLUE: uint = 1u; pub const BOX_FIELD_BODY: uint = 4u; </ins> /// The first half of a fat pointer. /// - For a closure, this is the code address.

Discussion:
There are three versions of these layouts for functions, traits, and slices, but the compiler relies on these being the same. We should replace them with a single layout: and or something. While we're at it, we should probably find uses of len/length names in the DST code and replace it with something more generic.
I merged the constants. Could you elaborate on the length names? Are there more constants like these?
What still needs to be done here, if anything?
Looks done.
Change:
/// # Examples /// /// ``` <del> /// use std::f32; </del> /// let v = f32::from_bits(0x41480000); <del> /// let difference = (v - 12.5).abs(); /// assert!(difference <= 1e-5); </del> <ins> /// assert_eq!(v, 12.5); </ins> /// ``` #[stable(feature = "float_bits_conv", since = "1.20.0")] #[inline]

Discussion:
These feel appropriate to add for completeness, and would simply chain or with the appropriate integer method. I'll add a PR soon. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Byte order conversions on floats themselves make little sense. The conversions should be done before float’s functions are called.
Err, I misread the proposal the first time around...
claim
Change:
<ins> struct ErrorKind; struct Error(ErrorKind); impl Fn(&isize) for Error { //~^ ERROR manual implementations of `Fn` are experimental //~| ERROR associated type bindings are not allowed here fn from() {} //~ ERROR method `from` is not a member of trait `Fn` } fn main() {} </ins>

Discussion:
<!-- 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. --<!-- 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</details
So, will fix this ICE. But the coherence code should probably not be passing escaping bound vars to begin with. As for prioritization, this is an ICE that occurs only after an error that, if fixed, will solve the ICE. I say low or medium.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
didn't fix this ICE; it's actually different than others and utterly broken (as expected)
No longer ICEs since