jiebi/CodeConvo huggingface dataset:
Change:
#[inline] #[stable(feature = "rust1", since = "1.0.0")] <del> fn is_null(self) -> bool { self as usize == 0 } </del> <ins> fn is_null(self) -> bool { self == 0 as *const T } </ins> #[inline] #[stable(feature = "rust1", since = "1.0.0")]

Discussion:
Consider the following benchmark: Which produces the following output: test _range ... bench: ns/iter (+/- 1033) test assembly ... bench: ns/iter (+/- 248) test enumerate ... bench: ns/iter (+/- 566) test iter ... bench: ns/iter (+/- 465) test position ... bench: ns/iter (+/- 384) is the correct abstraction for this but its code is 50% slower than the naive assembly implementation and 40% slower than .
I'm getting different results: $ rustc --opt-level=3 --test $ ./slowposition --bench running 4 tests test _range ... bench: ns/iter (+/- 8183) test enumerate ... bench: ns/iter (+/- 1615) test iter ... bench: ns/iter (+/- 4164) test position ... bench: ns/iter (+/- ) test result: ok. 0 passed; 0 failed; 0 ignored; 4 measured (the assembly version segfaulted on me).
wow. What platform?
On a macbook. Here's another run without a bunch of stuff in the background screwing up the variance: $ rustc --opt-level=3 --test $ ./slowposition --bench running 4 tests test _range ... bench: ns/iter (+/- 2331) test enumerate ... bench: ns/iter (+/- 2851) test iter ... bench: ns/iter (+/- 3995) test position ... bench: ns/iter (+/- 978)
The IL for -s inner loop is (de-gensymmed) Which looks sane, except for the spurious null check (which remains in the assembly). Benchmarks on my machine:
The spurious null check is the issue – writing a over it in the object code gives ±385 ns/iter on my laptop.
New code: New results: Unacceptable performance.
Change:
} #[test] <ins> fn git_hash() { let mut config = config(); config.git_hash = false; assert!(check_ignore(&config, "// needs-git-hash")); config.git_hash = true; assert!(!check_ignore(&config, "// needs-git-hash")); } #[test] </ins> fn sanitizers() { let mut config = config();

Discussion:
stable is fine: but beta and nightly are no longer showing commit-hash and commit-date information: ` <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
it's weird because the info is still displayed correctly in the very first oneliner-summary, but if there was some tool that reads the data by looking at or we still should display the right thing.
This appears to have been introduced by . The issue is that the macro uses CFGVERDATE/CFGVERHASH which is only set when compiling rustc. One option is to try to share some code with . Another option is to go the other way and get rustc to share some code with .
Mentoring instructions: set in (Maybe we should try to unify those functions so they don't duplicate so much code and problems like this don't happen in the future?)
I think it should be possible to write a run-make test ensuring this works properly.
claim
Hi im starting my journey of contributing to Rust, i found this issue a good starter for myself, do you think you would be open to let me take this chance to get familiar with the code base?
Hey! Go for it!
Alternatively, you could check out . I THINK that might be more straightforward. But I'll let you decide(:
claim
I tried doing this change in Then i did a and tried running this command on the stage2 rustodc But it appears that the commit-hash and commit-date is still unknown. Im wondering if the issue is that is passed as true in This is my first time making changes and testing in this project, please feel free to correct me if im testing / building in the wrong way.
I'd suggest changing to use instead of so it's easier to tell when these variables are unset without having to build a full stage 2 compiler.
Retagging as stable/stable regression, this already shipped in 1.67 as far as I can tell.
Are you still (interested in) working on this issue? I'd like to claim it otherwise.
please go ahead and claim it!
claim
Change:
<ins> fn main() -> Result<(), ()> { a(b(c(d(e( //~^ ERROR cannot find function `a` in this scope //~| ERROR cannot find function `b` in this scope //~| ERROR cannot find function `c` in this scope //~| ERROR cannot find function `d` in this scope //~| ERROR cannot find function `e` in this scope z???????????????????????????????????????????????????????????????????????????????????????? ????????????????????????????????????????????????????????????????????????????????????????? ?????????????????????????????????????????????????????????????????? //~^^^ ERROR cannot find value `z` in this scope ))))) } </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
Regression in /
Perhaps ? :thinking: cc
list of files that reproduce the crash ( is eough) `
I think we should change to a

Found with a From : From : Deep recursion involving ? Regression in nightly-2022-10-07, apparently in rollup . I suspect (
Change:
#[derive(Clone, Copy, Debug, Eq, PartialOrd, Ord)] #[stable(feature = "rust1", since = "1.0.0")] pub struct TypeId { <del> t: u128, </del> <ins> // We avoid using `u128` because that imposes higher alignment requirements on many platforms. // See issue #115620 for more information. t: (u64, u64), </ins> } #[stable(feature = "rust1", since = "1.0.0")]

Discussion:
On Apple Silicon (unlike x8664) is 16-bytes aligned. So it takes extra space with little or no benefit. I looked at generated code, it is the same: (Note just using won't work because it will pass by reference not by value) Additionally the issue with current is that is has different alignment on different platforms. Rust does not provide guarantees about the alignment, but if this was the same everywhere, it'd make life easier. (Practically we encountered this issue when our CI worked fine on Apple x8664 macs, but the program didn't work on Apple Silicon.) rustc 1.74.0-nightly ( 2023-09-05) macOS, Apple Silicon
Note that doesn't have the same alignment on all platforms either. It will be 4-aligned on (some) 32bit platforms.
I might be wrong here, but seems to work, so I believe is . So can't said problem be eliminated by implementing on as well?
already implements . Also does not affect alignment.
If that's the case, how about
That would make hashing and probably equality slower.
on 32 bit system would not be slower
Change:
lub } <ins> /// Like `universal_upper_bound`, but returns an approximation more suitable /// for diagnostics. If `r` contains multiple disjoint universal regions /// (e.g. 'a and 'b in `fn foo<'a, 'b> { ... }`, we pick the lower-numbered region. /// This corresponds to picking named regions over unnamed regions /// (e.g. picking early-bound regions over a closure late-bound region). /// /// This means that the returned value may not be a true upper bound, since /// only 'static is known to outlive disjoint universal regions. /// Therefore, this method should only be used in diagnostic code, /// where displaying *some* named universal region is better than /// falling back to 'static. pub(in crate::borrow_check) fn approx_universal_upper_bound(&self, r: RegionVid) -> RegionVid { debug!("approx_universal_upper_bound(r={:?}={})", r, self.region_value_str(r)); // Find the smallest universal region that contains all other // universal regions within `region`. let mut lub = self.universal_regions.fr_fn_body; let r_scc = self.constraint_sccs.scc(r); let static_r = self.universal_regions.fr_static; for ur in self.scc_values.universal_regions_outlived_by(r_scc) { let new_lub = self.universal_region_relations.postdom_upper_bound(lub, ur); debug!("approx_universal_upper_bound: ur={:?} lub={:?} new_lub={:?}", ur, lub, new_lub); if ur != static_r && lub != static_r && new_lub == static_r { lub = std::cmp::min(ur, lub); } else { lub = new_lub; } } debug!("approx_universal_upper_bound: r={:?} lub={:?}", r, lub); lub } </ins> /// Tests if `test` is true when applied to `lower_bound` at /// `point`. fn eval_verify_bound(

Discussion:
This code: Returns this error: Which is very unhelpful; it should at least in some way point to the line with the . This happens on rustc 1.40.0 ( 2019-12-16). For reference, this is the equivalent non-async error message (much more helpful): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Marking as focus, since improving diagnostics are important to the wg.
Change:
span: Span, id: ast::NodeId) { <del> match fn_kind { visit::FkItemFn(..) | visit::FkMethod(..) => { // ignore nested fn items } visit::FkFnBlock => { visit::walk_fn(self, fn_kind, decl, body, span); self.analyze_closure(id, span, decl, body); } } </del> <ins> visit::walk_fn(self, fn_kind, decl, body, span); self.analyze_closure(id, span, decl, body); </ins> } <ins> // Skip all items; they aren't in the same context. fn visit_item(&mut self, _: &'v ast::Item) { } </ins> } impl<'a,'tcx> euv::Delegate<'tcx> for AdjustBorrowKind<'a,'tcx> {

Discussion:
Doesn't seem to ICE as of rustc 1.4.0-beta.3 ( 2015-10-16)
Yes, it's fixed, and there's a testcase in the tree; I just forgot to close it.
Change:
.filter(|(a, b)| a == b) .count(); let len = sub1.len() - common_default_params; <ins> let consts_offset = len - sub1.consts().count(); </ins> // Only draw `<...>` if there're lifetime/type arguments. if len > 0 {

Discussion:
This code (): results in with missing const arguments in the at the bottom.
Hey guys could I take this on?
Just FYI, same problem with messages involving const generics and matches, e.g. () Also for functions: ()
Interestingly, when I use concrete types for the function example, things display properly: gives ()
you're welcome to look into fixing this! However, I'm not sure what might be causing this problem, so I don't have any suggestions for where to start looking yet.
I spent a few hours doing some digging and I can't find anything yet as well, though I'm as of yet still quite unfamiliar with the code-base. I might have more time tomorrow to look things over again, or maybe the day after.
Change:
.span_err(span, "cannot cast as `bool`, compare with zero instead"); } else if ty::type_is_region_ptr(t_e) && ty::type_is_unsafe_ptr(t_1) { <del> fn is_vec(t: ty::t) -> bool { match ty::get(t).sty { ty::ty_vec(..) => true, ty::ty_ptr(ty::mt{ty: t, ..}) | ty::ty_rptr(_, ty::mt{ty: t, ..}) | ty::ty_box(t) | ty::ty_uniq(t) => { match ty::get(t).sty { ty::ty_vec(_, None) => true, _ => false, } } _ => false } } </del> fn types_compatible(fcx: &FnCtxt, sp: Span, t1: ty::t, t2: ty::t) -> bool { <del> if !is_vec(t1) { </del> <ins> if !ty::type_is_vec(t1) { </ins> // If the type being casted from is not a vector, this special // case does not apply. return false

Discussion:
fails to compile: cc
What does the l-wrong label mean here?
It means that the current behavior of the compiler is incorrect.
Change:
= help: use `//` for a plain comment error: unused doc comment <del> --> $DIR/unused-doc-comments-edge-cases.rs:40:1 </del> <ins> --> $DIR/unused-doc-comments-edge-cases.rs:66:1 </ins> | LL |   /// unused doc comment |   ^^^^^^^^^^^^^^^^^^^^^^

Discussion:
The same warning is produced at other places like statements, expressions, functions etc. For completeness and consistency it should be produced for pattern and expression fields too. No response rustc 1.74.0-nightly ( 2023-09-01) binary: rustc commit-hash: commit-date: 2023-09-01 host: x8664-pc-windows-msvc release: 1.74.0-nightly LLVM version: 17.0.0 rustc version older than 1.74.0 may ICE on this code. The ICE was fixed in 1.74.0 <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
The reason these warnings are not produced is because the lint infrastructure currently exposes no hooks for and , i.e. there are no and methods on (or for that matter). To fix the issue, these methods may have to be here: and then invoked from here: and here: Alternatively, we can emit the warning from the already existing and methods of and not bother with the above changes at all.
Yeah, I would expect this is the best way of doing it.
claim
label -needs-triage
Change:
src: OpTy<'tcx, M::PointerTag>, dest: PlaceTy<'tcx, M::PointerTag>, ) -> InterpResult<'tcx> { <del> if mir_assign_valid_types(src.layout, dest.layout) { </del> <ins> if mir_assign_valid_types(self.tcx.tcx, src.layout, dest.layout) { </ins> // Fast path: Just use normal `copy_op` return self.copy_op(src, dest); }

Discussion:
The following ICEs (example by shows This means that is wrong. It might be possible to also trigger this without nightly features through const_prop.
Baring a way to do the proper structural subtyping check, the only solution I see is to go back to comparing layouts in all cases (as a fallback after types mismatch) -- but does not like this, as far as I recall. Any other proposals?
Change:
fcx.write_ty(id, enum_type); } <ins> type ExprCheckerWithTy = fn(&FnCtxt, &ast::Expr, ty::t); fn check_fn_for_vec_elements_expected(fcx: &FnCtxt, expected: Expectation) -> (ExprCheckerWithTy, ty::t) { let tcx = fcx.ccx.tcx; let (coerce, t) = match expected { // If we're given an expected type, we can try to coerce to it ExpectHasType(t) if ty::type_is_vec(t) => (true, ty::sequence_element_type(tcx, t)), // Otherwise we just leave the type to be resolved later _ => (false, fcx.infcx().next_ty_var()) }; if coerce { (check_expr_coercable_to_type, t) } else { (check_expr_has_type, t) } } </ins> let tcx = fcx.ccx.tcx; let id = expr.id; match expr.node { ast::ExprVstore(ev, vst) => { <ins> let (check, t) = check_fn_for_vec_elements_expected(fcx, expected); </ins> let typ = match ev.node { ast::ExprVec(ref args) => { let mutability = match vst {

Discussion:
fails to compile: cc
What does the l-wrong label mean here?
It means that the current behavior of the compiler is incorrect.
Change:
// For kinds without defaults (i.e., lifetimes), `required == permitted`. // For other kinds (i.e., types), `permitted` may be greater than `required`. if required <= provided && provided <= permitted { <del> return (false, None); </del> <ins> return (reported_late_bound_region_err.unwrap_or(false), None); </ins> } // Unfortunately lifetime and type parameter mismatches are typically styled

Discussion:
Compiler crashes with Also, I wonder what is the right way (or is there any way) to write a with expected behavior. Thanks.
Reduced:
Regression first occurred in 1.30 according to godbolt.
One can leave out the trait in your MCVE, still crashes. Bug was introduced somewhere between ... Sadly that's a very big range, but there are no nightlys available in between and also no bors artifacts because they are older than 167
triage: P-high
Smaller example from :
I was trying to remove as many type parameters as possible, and ended up with this: Removing after still cuases an ICE. Adding a after stops causing the ICE. Removing the also stops causing the ICE. Not sure if it's any more or less helpful, but just putting this here.
claim Looks like that didn't work, either way, I'm taking a look into this issue.
Error: The feature is not enabled in this repository. To enable it add its section in the in the root of the repository. Please let know if you're having trouble with this bot.
Error: The feature is not enabled in this repository. To enable it add its section in the in the root of the repository. Please let know if you're having trouble with this bot.
Change:
Reloc::Model RM, CodeGenOpt::Level OptLevel, bool EnableSegmentedStacks, <del> bool UseSoftFloat) { </del> <ins> bool UseSoftFloat, bool NoFramePointerElim) { </ins> std::string Error; Triple Trip(Triple::normalize(triple)); const llvm::Target *TheTarget = TargetRegistry::lookupTarget(Trip.getTriple(),

Discussion:
We currently build C++ code and Rust with frame pointers on, though we don't actually use them for anything (intended for GC). This is overhead that C and C++ don't usually have so it would be nice to turn on elimination.
I think we'll need them for gc, fwiw
on Linux x86_64 we should be using the DWARFv3 Call Frame Information for walking the stack, although I have no idea if we're emitting it correctly right now (likely on OS X and FreeBSD too). We might be, because gdb uses it and seems to work.
We'll leave it off until we have solutions for GC, which will probably end up being platform specific. libunwind should make it easy on linux and freebsd.
Reopening because this caused a regression in , so reverted in
Change:
} } } #[test] #[ignore(cfg(target_word_size = "32"))] // FIXME(#14064) fn test_read_object_streaming() {

Discussion:
Gives me:
That's because JSON doesn't allow for a trailing comma, I'd imagine.
The specification is clearly wrong here and the decoder should accept trailing commas.
Well, that's not how standards work.
Not sure what you mean by that. I'm not saying that the encoder should produce trailing commas.
There is some precedence for not allowing trailing commas: Go, Chromium, and Firefox reject such json. The specification is still wrong for not allowing them and I see no reason not to parse them.
sad but true. Please feel free to close the issue then.
We could, however, have a better error message.
It shouldn't fail, since it returns a containing possible parse errors.
Change:
} // Conservatively gives up if the dest is an argument, // because there may be uses of the original argument value. <del> if body.local_kind(dest_local) == LocalKind::Arg { </del> <ins> // Also gives up on the return place, as we cannot propagate into its implicit // use by `return`. if matches!( body.local_kind(dest_local), LocalKind::Arg | LocalKind::ReturnPointer ) { </ins> debug!("  Can't copy-propagate local: dest {:?} (argument)", dest_local); continue; }

Discussion:
The terminator conceptually moves out of the return place , but this is not currently reflected by the visitor infrastructure. This can lead to incorrect dataflow solutions for . For example, reports that is dead before a , which is wrong (it must always be live there). These don't currently cause any harm, since use of is fairly limited, but they are an issue for destination propagation / NRVO, which can propagate to arbitrary places in the function and needs to have correct information to do so soundly. The simple fix of calling from within has the problem that the receives a , but the local reads from can not be changed. This can be caught with an assertion, but maybe there is a better solution for this? cc
I think any alternative will be more complex than that simple assertion. Conceptually the should contain a which is always , but then we'd need to have assertions keeping that in place, so you don't gain anything. I don't think we can generalize returning to allow using different places than , which is the only way we'd get around having to assert something somewhere.
Change:
} fn rewrite_result(&self, context: &RewriteContext<'_>, shape: Shape) -> RewriteResult { <del> if let Some(lifetime_str) = rewrite_bound_params(context, shape, &self.bound_generic_params) </del> <ins> let (binder, shape) = if let Some(lifetime_str) = rewrite_bound_params(context, shape, &self.bound_generic_params) </ins> { // 6 is "for<> ".len() let extra_offset = lifetime_str.len() + 6; let shape = shape .offset_left(extra_offset) .max_width_error(shape.width, self.span)?; <del> let path_str = self.trait_ref.rewrite_result(context, shape)?; Ok(format!("for<{lifetime_str}> {path_str}")) </del> <ins> (format!("for<{lifetime_str}> "), shape) </ins> } else { <del> self.trait_ref.rewrite_result(context, shape) </del> <ins> (String::new(), shape) }; let ast::TraitBoundModifiers { constness, asyncness, polarity, } = self.modifiers; let mut constness = constness.as_str().to_string(); if !constness.is_empty() { constness.push(' '); </ins> } <ins> let mut asyncness = asyncness.as_str().to_string(); if !asyncness.is_empty() { asyncness.push(' '); } let polarity = polarity.as_str(); let shape = shape .offset_left(constness.len() + polarity.len()) .max_width_error(shape.width, self.span)?; let path_str = self.trait_ref.rewrite_result(context, shape)?; Ok(format!( "{binder}{constness}{asyncness}{polarity}{path_str}" )) </ins> } }

Discussion:
I tried : I expected to see this happen: nothing Instead, this happened: rustfmt reorders and incorrectly...
cc I imagine this blocks stabilization.
Ah, I definitely forgot to reorder these bounds after we settled the ordering.
Change:
<ins> #![feature(existential_type)] existential type Foo: Fn() -> Foo; //~^ ERROR: cycle detected when processing `Foo` fn crash(x: Foo) -> Foo { x } fn main() { } </ins>

Discussion:
Playing with the nighly's existential types, I stumbled upon a compiler stack overflow: Error message:
A better example might be this: removing the from the existential type decleration just compiles fine
Can you try running the compiler inside gdb and produce a backtrace?
<details<summaryBacktrace:</summary</details
It's recursing in Ideally this should cause cycle errors. But I'm assuming Manually computes this without a query. Maybe we should just make a query? This would solve both the FIXME and this issue.
Both examples now produce a cycle error. So we just need to add the two examples to (if there aren't already tests for these situations)
Change:
crate parent_module: Option<DefId>, crate doc: Symbol, crate kind: DocFragmentKind, <del> crate need_backline: bool, </del> crate indent: usize, }

Discussion:
I expected this change to work: But it causes to panic: <details<summaryBacktrace</summary</detailsI don't have time to look into it right now, but I wouldn't expect it to be too hard to fix and it would reduce the memory usage of rustdoc by quite a lot. I'd suggest starting by adding a bunch of assertions that the old and new behavior of is the same and investigating the assertion failures. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Since would unconditionally add a final newline, shouldn't the note say that (instead of "this can") and the 'pop's be unconditional? Across the entire codebase, there's just one other invocation of 'adddocfragment' (currently line 1087 ); it seems that that doesn't need a newline popped. Instead, I think the last function you modified () should only have a newline popped for the last , as would only be false for the last , as far as I can tell. I made a commit to that effect in the PR above, though I have to resolve the merge conflict somehow.
feel free to try that out and see if it works :) like I said, I don't have time to work on it right now.