jiebi/CodeConvo huggingface dataset:
Change:
ty::InstanceDef::CloneShim(..) => return true }; <del> return match tcx.hir.get_if_local(def_id) { Some(Node::ForeignItem(..)) => { false // foreign items are linked against, not codegened. } Some(_) => true, None => { if tcx.is_reachable_non_generic(def_id) || tcx.is_foreign_item(def_id) || is_available_upstream_generic(tcx, def_id, instance.substs) { // We can link to the item in question, no instance needed // in this crate false } else { if !tcx.is_mir_available(def_id) { bug!("Cannot create local mono-item for {:?}", def_id) } true } } }; </del> <ins> if tcx.is_foreign_item(def_id) { // We can always link to foreign items return false; } if def_id.is_local() { // local items cannot be referred to locally without monomorphizing them locally return true; } if tcx.is_reachable_non_generic(def_id) || is_available_upstream_generic(tcx, def_id, instance.substs) { // We can link to the item in question, no instance needed // in this crate return false; } if !tcx.is_mir_available(def_id) { bug!("Cannot create local mono-item for {:?}", def_id) } return true; </ins> fn is_available_upstream_generic<'a, 'tcx>(tcx: TyCtxt<'a, 'tcx, 'tcx>, def_id: DefId,

Discussion:
Adding to 's definition works around the ICE. Also, the bug doesn't trigger if is an non- , so it's not just that is inlined cross-crate, but -specific behavior is also involved. cc
Still happens on the latest nightly. cc It doesn't block , but the workaround in that PR is a bit ugly.
I have a fix in
Change:
<ins> // Regression test for <https://github.com/rust-lang/rust/issues/104851> /// @set foo = "$.index[*][?(@.name=='Foo')].id" pub type Foo = i32; // @is "$.index[*][?(@.name=='demo')].inner.decl.output.kind" '"resolved_path"' // @is "$.index[*][?(@.name=='demo')].inner.decl.output.inner.id" $foo pub fn demo() -> Foo { 42 } </ins>

Discussion:
Produces json (abridged) which is correct, but fails for this modify labels: +A-rustdoc-json +A-testsuite +T-rustdoc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This was found while working on , as it causes jsondoclint to fail for core (in addition to it catching the linked issue)
Change:
// Rewrite all `DICompileUnit` pointers to the `DICompileUnit` specified. See // the comment in `back/lto.rs` for why this exists. extern "C" void <del> LLVMRustLTOPatchDICompileUnit(LLVMModuleRef Mod, DICompileUnit *Unit) { </del> <ins> LLVMRustThinLTOPatchDICompileUnit(LLVMModuleRef Mod, DICompileUnit *Unit) { </ins> Module *M = unwrap(Mod); // If the original source module didn't have a `DICompileUnit` then try to

Discussion:
As of the 2021-09-23 nightly, rustc has stopped producing debug output for variables in a specific combination of circumstances: The variable is It is defined in a lib crate. The lib crate is included in a bin crate. The bin crate is built with . We noticed this after bumping past 09-23 to the 2021-10-27 nightly, when our debugger broke. The static is still being included in the ELF output (both allocated space, and represented correctly in the symtab), but is missing from DWARF. Bisecting indicates 2021-09-23 as the culprit (09-22 works). Here is a repro case that I've reduced that works on linux x86-64, at least, and probably other DWARF platforms. modify labels: +regression-from-stable-to-nightly -regression-untriaged
Bumping to regression-stable-to-beta, because 2021-09-23 is a 1.57 nightly. But would be good to confirm this reproduces on beta.
points at (). That being a rollup, looks the most relevant.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
I think this may be a duplicate of . Please test on a current nightly, and when goes out it should have the backport via . It's still possible that introduced its own problem, but maybe it just exacerbated the LLVM issue.
It looks to me like the problem still reoccurs on the current nightly: <details<summaryFor completeness, here is a transcript showing the behavior that is expected, from nightly-2021-09-22</summary</details
This appears to still be reproducing as of ; we're stuck on because basically anything newer breaks our debugger.
So, after working out how to build a toolchain that includes our cross target and rust-lld and whatnot locally, I've tested today's mainline with a revert for PR , commit -- which had previously identified as the likely culprit. I can confirm that DWARF output for our statics on thumbv7em and kin is restored after that commit is reverted. Shall I prepare a PR?
Change:
let should_panic; let ignore; let edition; <del> if let Some(Event::Start(Tag::CodeBlock(kind))) = event { let parse_result = match kind { CodeBlockKind::Fenced(ref lang) => { LangString::parse_without_check(&lang, self.check_error_codes, false) } CodeBlockKind::Indented => Default::default(), }; if !parse_result.rust { return Some(Event::Start(Tag::CodeBlock(kind))); } compile_fail = parse_result.compile_fail; should_panic = parse_result.should_panic; ignore = parse_result.ignore; edition = parse_result.edition; </del> <ins> let kind = if let Some(Event::Start(Tag::CodeBlock(kind))) = event { kind </ins> } else { return event; <del> } let explicit_edition = edition.is_some(); let edition = edition.unwrap_or(self.edition); </del> <ins> }; </ins> let mut origtext = String::new(); for event in &mut self.inner {

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. --Repro: text /// aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa /// rust /// bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb /// Rustdoc output: ! It seems that only code block with language are affected. cc
A quick test showed that the bug was introduced in (i.e.: works fine)
label +regression-from-stable-to-nightly
Thanks, I'll fix it in the next hours.
In case you want to take a look to the fix, it's .
Change:
check_ty(cx, &*input.ty); } if let ast::Return(ref ret_ty) = decl.output { <del> check_ty(cx, &**ret_ty); </del> <ins> let tty = ast_ty_to_normalized(cx.tcx, ret_ty.id); if !tty.is_nil() { check_ty(cx, &ret_ty); } </ins> } }

Discussion:
made the lint trigger for tuples, but as far as I understand, returning is equivalent to returning cvoid, and therefore should be allowed. Here is an example:
Yes, stupid mistake; I'll fix it. (As a workaround, you can write .)
since was merged i'm closing
Change:
let ret = f(self); let last_token = if self.token_cursor.stack.len() == prev { &mut self.token_cursor.frame.last_token <ins> } else if self.token_cursor.stack.get(prev).is_none() { // This can happen due to a bad interaction of two unrelated recovery mechanisms with // mismatched delimiters *and* recovery lookahead on the likely typo `pub ident(` // (#62881). return Ok((ret?, TokenStream::new(vec![]))); </ins> } else { &mut self.token_cursor.stack[prev].last_token };

Discussion:
I'm getting an internal compiler error on the following program (found by ): I'm seeing the error on stable, beta, and nightly. As with , the error occurs on () but not on (). , the proposed fix for , does not fix this error. cc
Change:
# If we're running perf then set this environment variable # to put the benchmarks into 'hard mode' ifeq ($(MAKECMDGOALS),perf) <del> RUST_BENCH=1 export RUST_BENCH </del> <ins> export RUST_BENCH=1 </ins> endif TEST_LOG_FILE=tmp/check-stage$(1)-T-$(2)-H-$(3)-$(4).log

Discussion:
While trying 'make check' on the latest revision (id mentioned in attachments), I get a bunch of failures in gdb debuginfo tests. Along with this, I see that 'make check' itself errors out and does not continue further. Here is how the system info looks: Also, the last few lines of output from the problem described above: I mentioned this issue in #rust last evening and was advised to file it as an issue. Please let me know if I can help resolve this issue by providing more information or trying a different setting/config.
This looks like a locale-related issue, given: vs. the expected (, vs . for floating point values).
cc
Yes, I've had that issue too and changing the systemwide number format fixed it. But we should see if we can't make our test suite independent of the system's locale... Thanks for the detailed bug report!
If this is the kind of bug that a newbie can handle, I'll try to fix it. I started with rust just some minutes ago and am going through the guide at the moment. On 21-09-14 20:30, Michael Woerister wrote:
Sure, if you want to give it a try, just go ahead. If you need any help you can post questions right here.
Here's my first attempt at solving this (works fine for me): However, I am not sure if this is a good way to do it. I'll eagerly wait for you folks to review it and see what could be improved (if needed).
:+1:
Change:
<ins> error[E0381]: use of possibly uninitialized variable: `e` --> $DIR/issue-62107-match-arm-scopes.rs:3:11 | LL |     match e { |           ^ use of possibly uninitialized `e` error: aborting due to previous error For more information about this error, try `rustc --explain E0381`. </ins>

Discussion:
ICE with the borrow checker on nightly. Tried on stable/beta and it correctly errors with in nightly, I get : Backtrace:
Reduced: cc
Bisected this one to and , that is, PR . cc
Change:
#![feature(repeat_generic_slice)] #![feature(try_reserve)] #![feature(unboxed_closures)] <del> #![feature(vecdeque_rotate)] </del> #![deny(rust_2018_idioms)] use std::hash::{Hash, Hasher};

Discussion:
Currently if you want to rotate a VecDeque n elements to the left or right, you'd have to write something like this: I wonder if it would be possible to add 2 functions: rotateleft(mid: usize) rotateright(mid: usize) You then only have to write: This would be equal to slice's and . It could probably be implemented on a lower level than with pop's and pushes for a little more efficiency.
Ooh, I like this -- is a circular buffer internally, so it should be doable with at most two . EDIT: PR
PR is r+'d, so I turned this into a tracking issue.
I've since the feature replaced any code that used the pop - push technique with the rotate methods. This was fairly easy to do. It's been a few months now, are there any issue's preventing this from landing stable?
fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [ ] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
Is "left" or "right" the word we want to use here? Previously we have deprecated () of in favor of and so that we do not assume the string is laid out from left to right. Here we seem to assume is to while is to ? Are we able to use some words that express the and without assuming a left-to-right layout?
As discussed here, we have to use those names to stay consistent with the slice rotate_{left |right} methods
, sorry I missed that. That makes sense.
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
Change:
<ins> // Copyright 2014 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. // compile-flags: --extern std= // error-pattern: is not a file fn main() {} </ins>

Discussion:
This looks like , but I'm running . The error message was With this stacktrace: I'm on an i686 Ubuntu 14.04.1 LTS Vagrant VM (the ) on OS X 10.9.5
Actually, I just took another look at the command line, and it had . That's probably where the value came from, but I don't know if it's the expected error message.
Yep, this should definitely have a better error message.
Do you happen to have a code example that triggers this?
I don't have code, but specifying a value for seemed to fix the problem, so I think that's it.
fixing it now.
Change:
<ins> error: malformed `coverage` attribute input --> $DIR/bad-attr-ice.rs:10:1 | LL | #[coverage] | ^^^^^^^^^^^ | help: the following are the possible correct uses | LL | #[coverage(off)] | LL | #[coverage(on)] | error[E0658]: the `#[coverage]` attribute is an experimental feature --> $DIR/bad-attr-ice.rs:10:1 | LL | #[coverage] | ^^^^^^^^^^^ | = note: see issue #84605 <https://github.com/rust-lang/rust/issues/84605> for more information = help: add `#![feature(coverage_attribute)]` to the crate attributes to enable = note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0658`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '-Cinstrument-coverage -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: unexpected value of coverage attribute', 'error: internal compiler error: unexpected value of coverage attribute' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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: [coverageattron] checking for on [mirbuilt] building MIR for -- label +F-coverageattribute
Regression in
Change:
inner.cap, inner.buf.cast::<T>(), inner.end as *const T, <del> inner.cap * mem::size_of::<I::Src>() / mem::size_of::<T>(), </del> <ins> // SAFETY: the multiplication can not overflow, since `inner.cap * size_of::<I::SRC>()` is the size of the allocation. inner.cap.unchecked_mul(mem::size_of::<I::Src>()) / mem::size_of::<T>(), </ins> ) };

Discussion:
I tried this code: I expected to see this happen: Both and should get optimized to just return the input unchanged. Instead, this happened: unwrapcopy get's optimized as espected: unwrapclone fails to get optimized and compiles into a loop: Originally I thought that behavior was caused by the underlying type not implementing Copy but Drop seems to be the actual culprit. <!-- 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. --: </p</details
This reminds me of the do-nothing-loop from . That's not quite true, e.g. this also optimizes even though is not : So it's likely due to and the compiler fails to see that the drop can't happen.
Change:
<ins> #![feature(trait_alias)] // Enabled to reduce stderr output, but can be triggered even if disabled. trait Trait {} trait WithType { type Ctx; } trait Alias<T> = where T: Trait; impl<T> WithType for T { type Ctx = dyn Alias<T>; //~^ ERROR the size for values of type `(dyn Trait + 'static)` cannot be known at compilation time } fn main() {} </ins>

Discussion:
The following code panics the compiler:
backtrace: <details</details
~Likely diagnostic related :-/~ Disregard that.
Slightly reduced: can also be , but I though this will remove one more warning, so it's worth using here ^^
triage: P-medium. removing nomination label. reasoning: you get the feature flag diagnostic, including the span of the offending code and the suggestion of what to write. So this is reasonable for users to deal with, even with the ICE. (as opposed to cases where the ICE occurs without any useful output for the user.)
Change:
match self.expr_ty.kind { ty::FnDef(..) => { // Attempt a coercion to a fn pointer type. <del> let f = self.expr_ty.fn_sig(fcx.tcx); </del> <ins> let f = fcx.normalize_associated_types_in( self.expr.span, &self.expr_ty.fn_sig(fcx.tcx), ); </ins> let res = fcx.try_coerce( self.expr, self.expr_ty,

Discussion:
() Errors: Seems like this should work.
The following works: Switching to be of type itself. Adding , and then switching to be of type
Huh, what if you cast it to ? That works, right?
Adding an intermediate cast to does make it work.
So having a projection in the type, blocks the cast from happening? That's a bit weird. cc
The fnsig function on fn item types is returning unnormalized types directly from the tcx. Defined in The relevant call-site is at
Change:
<ins> // check-pass #![feature(existential_type)] existential type A: Iterator; fn def_a() -> A { 0..1 } pub fn use_a() { def_a().map(|x| x); } fn main() {} </ins>

Discussion:
Encountered this when working on test cases for an RFC: cc This seems related to other issues.
I'm confused. Either this was fixed since yesterday's nightly (it still ICEs on nightly but works locally on master), or something really odd is going on
Is that the upstream master? Otherwise maybe someone merged a PR or something..
This still ICEs on nightly.
This now compiles successfully on the latest nightly.
Change:
|     | |     help: parentheses are required to parse this as an expression: `({ 3 })` <del> error: aborting due to 10 previous errors </del> <ins> error: aborting due to 9 previous errors </ins> Some errors have detailed explanations: E0308, E0614. For more information about an error, try `rustc --explain E0308`.

Discussion:
This example : (The example above was reduced from one involving , found by This regression was likely introduced by , due to the definition of : That function lists all of the operators that can't start an expression, but only continue it. () is incorrectly included, as is parsed the same as at the start of an expression. cc
I've left some comments on (a partial fix for a regression that seems similar to this, but more specific), e.g.: As per , should've never returned for , preventing the regression.
Assigning as and removing .
Change:
if let Some(item) = tcx.opt_associated_item(def_id.into()) && let ty::AssocKind::Const = item.kind && let ty::ImplContainer = item.container <del> && let Some(trait_item) = item.trait_item_def_id </del> <ins> && let Some(trait_item_def_id) = item.trait_item_def_id </ins> { <del> let args = tcx.impl_trait_ref(item.container_id(tcx)).unwrap().instantiate_identity().args; Some(tcx.type_of(trait_item).instantiate(tcx, args)) </del> <ins> let impl_def_id = item.container_id(tcx); let impl_trait_ref = tcx.impl_trait_ref(impl_def_id).unwrap().instantiate_identity(); let args = ty::GenericArgs::identity_for_item(tcx, def_id).rebase_onto( tcx, impl_def_id, impl_trait_ref.args, ); tcx.check_args_compatible(trait_item_def_id, args) .then(|| tcx.type_of(trait_item_def_id).instantiate(tcx, args)) </ins> } else { Some(fcx.next_ty_var(span)) }

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. --(reduced) (original) This code is very similar to closed issue . The only difference is in line 17 which was in previous issue and now it's <!-- 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 --
label -needs-triage F-genericconstitems claim
Change:
} #[test] <ins> fn test_into_iter() { // Empty iter { let d: RingBuf<int> = RingBuf::new(); let mut iter = d.into_iter(); assert_eq!(iter.size_hint(), (0, Some(0))); assert_eq!(iter.next(), None); assert_eq!(iter.size_hint(), (0, Some(0))); } // simple iter { let mut d = RingBuf::new(); for i in range(0i, 5) { d.push_back(i); } let b = vec![0,1,2,3,4]; assert_eq!(d.into_iter().collect::<Vec<int>>(), b); } // wrapped iter { let mut d = RingBuf::new(); for i in range(0i, 5) { d.push_back(i); } for i in range(6, 9) { d.push_front(i); } let b = vec![8,7,6,0,1,2,3,4]; assert_eq!(d.into_iter().collect::<Vec<int>>(), b); } // partially used { let mut d = RingBuf::new(); for i in range(0i, 5) { d.push_back(i); } for i in range(6, 9) { d.push_front(i); } let mut it = d.into_iter(); assert_eq!(it.size_hint(), (8, Some(8))); assert_eq!(it.next(), Some(8)); assert_eq!(it.size_hint(), (7, Some(7))); assert_eq!(it.next_back(), Some(4)); assert_eq!(it.size_hint(), (6, Some(6))); assert_eq!(it.next(), Some(7)); assert_eq!(it.size_hint(), (5, Some(5))); } } #[test] </ins> fn test_from_iter() { use std::iter; let v = vec!(1i,2,3,4,5,6,7);

Discussion:
There's currently no method on . This might have been missed during collections reform, or was never implemented.
Change:
let (const_context, min_const_fn) = match tcx.hir().body_owner_kind(id) { hir::BodyOwnerKind::Closure => (false, false), hir::BodyOwnerKind::Fn => { <del> (is_const_fn(tcx, def_id.to_def_id()), is_min_const_fn(tcx, def_id.to_def_id())) </del> <ins> (tcx.is_const_fn_raw(def_id.to_def_id()), is_min_const_fn(tcx, def_id.to_def_id())) </ins> } hir::BodyOwnerKind::Const | hir::BodyOwnerKind::Static(_) => (true, false), };

Discussion:
Some operations, such as raw pointer comparisons, require when inside a const context. To my knowledge, none of these operations have been const-stabilized. Accordingly, the fails to compile due to a missing unsafe block. However, the check does not run for functions. The following : This is an easy problem to fix, but the root cause here is poor naming. Specifically, should be renamed and should be . We have had other issues due to this in the past. cc to weigh in on the renaming.
Yeah I recall being confused by those names in the past, too. Definite :+1: for changing them. As for concrete proposals, I don't actually remember what these queries are doing, but your suggestions sound reasonable. :)
Oh, the names are different than in the email I got because you edited.^^ So does take the context (feature flags etc) into account? The name sounds like it would. What about , to make it a bit shorter?
Damn. I was hoping no one would catch me :smile:. would indeed take feature flags into account to mirror the current behavior of . I originally had , but that's not really correct, since it would also return if the function was unstable but the requisite feature flags were set.