jiebi/CodeConvo huggingface dataset:
Change:
pub struct SaveContext<'l, 'tcx> { tcx: TyCtxt<'tcx>, tables: &'l ty::TypeckTables<'tcx>, <ins> /// Used as a fallback when nesting the typeck tables during item processing /// (if these are not available for that item, e.g. don't own a body) empty_tables: &'l ty::TypeckTables<'tcx>, </ins> access_levels: &'l AccessLevels, span_utils: SpanUtils<'tcx>, config: Config,

Discussion:
I wasn't sure if it was right to report this here or elsewhere, so here it is for now... Trying to compile with works, but running the from the same toolchain results in the following:
looks like
cc
triage: P-high. Removing nomination label.
Easy way to reproduce. empty project to dependencies RLS Errors: And
although supposedly this has been fixed a couple of days ago, latest nightly rls still crashes on petgraph:
Chances are this has been fixed with Could you please update to the newest nightly now and see if you can reproduce this?
yes this is fixed now, thanks!

RLS cannot build my project, which uses gstreamer. Compiling it normally with rustc works fine. Affected project for reference: I launched RLS manually with
Probably unearthed by
cc
Recompiled everything with , same issue.
works fine.
I’m sure it’s what - it’s an unearthed bug when you pass -Zsave-analysis, hence why it crashes only when using RLS.
I have the same error when using rust nightly and directly or indirectly referencing the crate. The project builds fine but crashes. Steps to reproduce: Create a new project Add to the Run Downgrading to and makes the error go away.
pre-triage: not sure what priority to assign to this. Probably P-high but I want to discuss with team. Leaving I-nominated unprioritized for now.
triage: P-high. Cc (can you take point on this?)
Yup, assigning to myself, shouldn’t be hard to fix
What assistance from others, if any, could help you resolve this issue?
Minimal reproducer (based on petgraph ICE):
Is anyone else available you can offload this bug to?
visiting for triage. Assigning to self to remember to look into this later
So I have a fix that does not ICE but doesn't seem to actually 'fix' the behaviour. The problem is that we can't nest typeck tables for because it doesn't have one because it doesn't have a body; however we hit the assertion when trying to resolve member type when resolving a qualified path using because the DefId paths don't properly match. The fix that I have is not to try to nest when a given NodeId doesn't have associated typecktables but instead use an empty table approach (e.g. used in privacy code). This means we don't hit the assertion but IIUC we can't properly resolve a qualified path this way. I think long-term the solution would be to traverse HIR directly rather than doing so using AST (that's another case where we have a mismatch of nested DefIds for which we can't get typeck tables to properly resolve a ). I'll submit the PR with the fix later today.
Change:
<ins> trait Zero { const ZERO: Self; } impl Zero for String { const ZERO: Self = String::new(); } fn foo() { match String::new() { Zero::ZERO ..= Zero::ZERO => {}, //~^ ERROR only `char` and numeric types are allowed in range patterns _ => {}, } } fn bar() { match Zero::ZERO { Zero::ZERO ..= Zero::ZERO => {}, //~^ ERROR type annotations needed [E0282] _ => {}, } } fn main() { foo(); bar(); } </ins>

Discussion:
currently throws E0029: while it should infer the constant to be . modify labels: +T-compiler +A-inference claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I don't think this is incorrect. doesn't refer to a specific constant, it's just an abstract associated constant. works fine.
Hmm, does work, though. But does not. It does seem inconsistent that works and doesn't.
is just , so type inference should kick in here. In fact you can write and inference works just fine. The issue only happens when used in range patterns. I am prototyping a fix right now and it seems that the issue is just that E0029 check happens a little bit early (before unification is performed).
Change:
struct Foo<T> { x: Id!(T) <del> //~^ ERROR: type macros are experimental (see issue #27336) </del> <ins> //~^ ERROR: type macros are experimental (see issue #27245) </ins> } fn main() {

Discussion:
Tracking issue for rust-lang/rfcs
The feature gate for this points at , should it point here instead?
How is this going? Is anything on fire yet?
Is there any review/stability status on this feature by any chance?
Any update on this?
cc This seems like a constrained extension to macros, that we could consider stabilising.
There's an issue re interaction with deriving, see , but I think it's minor.
Going to FCP for this feature seems good to me. If people are using it successfully (or have found bugs!) please say so :-)
+1 to stabilising. There are still a few issues with type macros, but just bugs, and nothing major that I'm aware of.
Did the lang team decide to FCP or wait?
We went to FCP. Apologies for the dropped administrative work recently -- all of the Mozilla folks just traveled to London for a week and the preparations for that resulted in some balls being dropped.
This feature is in its final comment period for stabilization (in 1.11).
rustc 1.11 still reports type macros as unstable. Is there any chance of having this feature stabilized in 1.12?
Yes, it's ready for immediate stabilization. Anyone should feel free to open a stabilization PR and ping me on it.
Indeed I am slow in writing it up, but the team decided formally to stabilize this feature (as commented). Horray!
I am tagging the issue with E-mentor because I would be happy to mentor someone through the process of implementing a stabilization PR.
I don't have experience with rustc internals, but I'd be happy to try to implement the stabilization PR. :-)
ok, basically all you have to do is to modify in and basically remove the from this code: you also need to change this declaration from and move it to be "accepted" (there is a section of "accepted" features below in the file):
Also remove from any tests that mention it.
Ok, I've removed the check on the feature gate in , updated the tests and moved the declaration in . Just two questions: 1) should I bump the version number in the declaration to ? (or maybe , it's not clear to me if this commit will be backported to the current beta) 2) should I reference this issue in the commit message? I've put " for now, I don't know if this convention is ok for this project. Thanks!
Change:
* [Helpful Links and Information](#helpful-links-and-information) If you have questions, please make a post on [internals.rust-lang.org][internals] or <del> hop on the [Rust Discord server][rust-discord], [Rust Zulip server][rust-zulip] or [#rust-internals][pound-rust-internals]. </del> <ins> hop on the [Rust Discord server][rust-discord] or [Rust Zulip server][rust-zulip]. </ins> As a reminder, all contributors are expected to follow our [Code of Conduct][coc].

Discussion:
There are still of IRC in the repo. Removing them is not a priority but it will avoid confusion for newcomers.
Should these places be replaced with references to the rust discord server, or just be removed outright?
Probably replaced. Gonna update title.
Opened to address this.
This is horrible. Replacing IRC with Discord.. :/
If you haven't read about it yet, is the post from April.
Yeah I read already. I'd remove the mention of any particular discussion channel, instead of putting Discord in. I can't wait for Matrix to become more mature so the Rust project can use it. Falling back to Discord is quite bad for a FOSS project.
IMO we should just mirror subreddit solution and point to Discord.
Change:
}) .collect(); <del> let params: Vec<&hir::Param<'_>> = self </del> <ins> let mut params: Vec<&hir::Param<'_>> = self </ins> .tcx .hir() .body(fn_node.body_id()?)

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at /rust/deps/itertools- 'itertools: .zipeq() reached end of one iterator before the other'', 'thread 'rustc' panicked at /rust/deps/itertools- 'itertools: .zipeq() reached end of one iterator before the other'' 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: [typeck] type-checking [analysis] running analysis passes on this crate -- label +F-cvariadic +F-fndelegation <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
lol
Thanks! I will take a look. (I'm glad we the check!)
another one that does not need delegation I think
claim
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. // compile-flags: -Z parse-only struct Foo { x: isize, } impl Foo { fn hi(&self) -> bool { true } } fn main() { while || Foo { x: 3    //~ ERROR expected type, found `3` }.hi() { //~ ERROR expected one of `.`, `;`, `?`, `}`, or an operator, found `{` println!("yo"); } } </ins>

Discussion:
Currently is parsed as . I think it should be parsed as , to be consistent with handling of other similar "open" binary and prefix expressions (lambdas can be viewed as a form of a prefix expression). Consider these expressions: They are parsed as The last two cases seem to be different from others and wrong. on IRC suggested that this behavior could have been introduced accidentally during transition from lambdas with blocks as bodies to lambdas with arbitrary expressions as bodies. If this is a bug, fixing it can render some previously valid programs invalid, but this seems rater unlikely, as bare lambdas rarely end up in conditionals. It is possible though:
cc
Oh and I didn't mean I had introduced the distinction accidentally but rather that before I made that simplification, the code was block-oriented so the need for it to obey typical expression rules may have been overlooked and I didn't think about it (to consider fixing it).
Change:
ty: Ty<'tcx>, span: Span, ) -> Option<Vec<traits::PredicateObligation<'tcx>>> { <ins> // Handle the "livelock" case (see comment above) by bailing out if necessary. let ty = match ty.kind { ty::Infer(ty::TyVar(_)) => { let resolved_ty = infcx.shallow_resolve(ty); if resolved_ty == ty { // No progress, bail out to prevent "livelock". return None; } resolved_ty } _ => ty, }; </ins> let mut wf = WfPredicates { infcx, param_env, body_id, span, out: vec![], item: None }; <del> if wf.compute(ty) { debug!("wf::obligations({:?}, body_id={:?}) = {:?}", ty, body_id, wf.out); let result = wf.normalize(); debug!("wf::obligations({:?}, body_id={:?}) ~~> {:?}", ty, body_id, result); Some(result) } else { None // no progress made, return None } </del> <ins> wf.compute(ty); debug!("wf::obligations({:?}, body_id={:?}) = {:?}", ty, body_id, wf.out); let result = wf.normalize(); debug!("wf::obligations({:?}, body_id={:?}) ~~> {:?}", ty, body_id, result); Some(result) </ins> } /// Returns the obligations that make this trait reference

Discussion:
returns if it can't make progress on an inference variable, and the original obligation should be retried later. However, doesn't check that return type and may (incorrectly) return no obligations. On I suggested this: I'm pretty sure now that it would've prevented this bug. <hr/Looking at the users, only uses this function, and only for the user-specified bounds, so it's possible inference variables are impossible to find (unless normalization introduces them, I guess?). It might be fine to just create obligation for the instead of bailing out (see below, this is the same as moving out of ) It's true that can't be found as the first type in the recursive call, but is a , and it uses . (EDIT: Read the code more carefully and the check is , so while it's not an early like I would prefer, it does seem to only trigger on the root type) However, a few other things call and it would be fine for them to create an obligation rather than erroring out, so maybe itself should do that check? cc
changes the return type of to a and discards it using . Might cause us to be slightly more cautious in the future.
I'm working on a fix that makes itself never bail out, so the check is done in , hopefully that will also work nicely for consts. EDIT: opened .
Change:
// operation panics, `hole` will get dropped and automatically write the element back // into the slice. let mut tmp = mem::ManuallyDrop::new(ptr::read(v.get_unchecked(len - 1))); <del> let mut hole = CopyOnDrop { src: &mut *tmp, dest: v.get_unchecked_mut(len - 2) }; ptr::copy_nonoverlapping(v.get_unchecked(len - 2), v.get_unchecked_mut(len - 1), 1); </del> <ins> let v = v.as_mut_ptr(); let mut hole = CopyOnDrop { src: &mut *tmp, dest: v.add(len - 2) }; ptr::copy_nonoverlapping(v.add(len - 2), v.add(len - 1), 1); </ins> for i in (0..len - 2).rev() { <del> if !is_less(&*tmp, v.get_unchecked(i)) { </del> <ins> if !is_less(&*tmp, &*v.add(i)) { </ins> break; } // Move `i`-th element one place to the right, thus shifting the hole to the left. <del> ptr::copy_nonoverlapping(v.get_unchecked(i), v.get_unchecked_mut(i + 1), 1); hole.dest = v.get_unchecked_mut(i); </del> <ins> ptr::copy_nonoverlapping(v.add(i), v.add(i + 1), 1); hole.dest = v.add(i); </ins> } // `hole` gets dropped and thus copies `tmp` into the remaining hole in `v`. }

Discussion:
Similar to I tried this code: I expected to see this happen: Miri does not detect UB Instead, this happened: Miri detects UB (experimentally) <!-- 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<summaryBacktrace</summary<p</p</details
cc
FWIW, I have now detected this bug through the tests in and .
Looks like the problem is in this line: re-borrows an on the entire slice, thus invalidation previously created pointers. So this is yet another instance of
Actually, just to be sure, are we interested in patching out all such instances of this in std/alloc/core? I know I personally would like the standard library to be clean against Miri with so that I can check libraries for stacked borrows issues. I just did a quick skim now that I understand the rules and I think I can spot a few other issues, so I'm not sure if these were deliberately left in, or if I'm just the first person to be looking this carefully.
So far we fixed various issues of this sort that people noticed, but there was never a concerted effort to find all of them. So they were not deliberately left in, just not found yet. Whether we want to fix them all is up to who ultimately decide about the std library implementation.
So far the fixes have been localized enough that it's been easy to take them (eg ). If anything comes up that requires drastic changes to fix then there might be a conversation about it, but for simple ones that don't increase maintenance burden I think they'll be happily accepted.
Change:
<ins> const fn foo(a: i32) -> Vec<i32> { vec![1, 2, 3] //~ ERROR heap allocations are not allowed in const fn } fn main() {} </ins>

Discussion:
<short summary of the bugReturning from a const fn causes internal compiler error, with the message 'bad input type for cast'. I tried this code: Minimal example Original example I expected to see this happen: program compiles and prints 'Hello 1' or I get a compiler error. Instead, this happened: ICE
that gives the exact backtrace above.
Relavent code: The types here are and .
The actual bug would be here then, right?
Not quite sure, but the real bug is that we allow the keyword in const fn XD I already have a fix since yesterday, but the german bahn didn't give me electricity so my notebook died while tests were running
no ICE fix from the ICE? :p
Change:
"itertools 0.7.8 (registry+https://github.com/rust-lang/crates.io-index)", "lazy_static 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)", "regex 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)", <ins> "walkdir 2.2.5 (registry+https://github.com/rust-lang/crates.io-index)", </ins> ] [[package]]

Discussion:
ARC is beginning to infect more and more types, and they each must have a clone method, but there is no trait to implement.
related
Along with this, we should provide a default implementation of Clonable for all copyable types.
Closing this now that has been implemented. There are no doubt some types left that should have a implementation, but they can be dealt with on a case-by-case basis.
Change:
<ins> error: expected one of `,` or `>`, found keyword `as` --> $DIR/issue-84831.rs:5:13 | LL |     std::<_ as _>; |             ^^ expected one of `,` or `>` | help: expressions must be enclosed in braces to be used as const generic arguments | LL |     std::<{ _ as _ }>; |           ^        ^ error[E0423]: expected value, found crate `std` --> $DIR/issue-84831.rs:2:5 | LL |     std::<0>; |     ^^^^^^^^ not a value error[E0423]: expected value, found crate `std` --> $DIR/issue-84831.rs:5:5 | LL |     std::<_ as _>; |     ^^^^^^^^^^^^^ not a value error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0423`. </ins>

Discussion:
Crashes when running . <!-- 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 nightly-2020-10-28 between ... Does occur since 1.49 modify labels: A-meta regression-from-stable-to-stable
This is an error-ICE case, with a nice error as well. <details<summaryfull build output</summary</details
modify labels -I-prioritize +P-medium As discussed in the prioritization working group
Minimized
Interesting thing… my minimized example only regresses at ( to ), however I can confirm the regression at ( to ) for the original example. AFAICT possibly .
Ah, that makes sense… the later regression is due to . Using takes it back to .
Edit: Probably not the underlying problem, see comments below.
label -A-meta +A-frontend
Nevermind, further minimization to puts the regression point earlier than .
The (error -error+ICE) regression of the example happens at . cc <details<summaryCompiler output/backtrace</summaryon on (with backtrace)
As a reminder: Please add [both][0] code [snippets][1] as testcases in the final PR. They seem to be triggered differently, therefore it shouldn't hurt to add them both. [0]: [1]:
Change:
<ins> // ignore-tidy-filelength </ins> use core::borrow::Borrow; use core::cmp::Ordering; use core::fmt::Debug;

Discussion:
Associative maps ( and ) in Rust are currently missing two methods to get owning iterators to their keys or values. We have to get key-value reference pairs, to get key-value mutable reference pairs and to get owned key-value pairs. I'd expect and to offer a similar trio of methods (with an exception for of course). is there, but the variants are missing for seemingly no good reason. As an example implementation (but perhaps we can do better):
I would accept a PR to introduce unstable intokeys() and intovalues().
Hi, I’m interested in working on this but I have a question regarding the implementation. I guess we can implement this in two ways. First one is implementing like the example in the first comment, like returning . And the second option is to return a struct of its own (like a mixture of and / structs) instead of returning . We can name them IntoKeys and IntoValues and they can be responsible of implementing the trait. I feel like performance wise they are same, since map and custom struct both will be evaluated lazily when we iterate over. But there might be a rule to always return a proper type in the rust std code that I don't know. So I think I’m okay implementing either way but wanted to ask just in case. What do you think?
For the public API I would prefer this implemented using dedicated IntoKeys and IntoValues iterator types. They can be implemented internally as wrappers around Map<IntoIter<K, Vif that simplifies things.
Thanks for the answer Created a PR for this and you as a reviewer. Would you mind taking a look at it when you have time?
Change:
<ins> // run-rustfix // https://github.com/rust-lang/rust/issues/79076 use std::cmp::PartialEq; #[derive(Clone, Eq)] //~ ERROR [E0277] pub struct Struct<T>(T); impl<T: Clone, U> PartialEq<U> for Struct<T> where U: Into<Struct<T>> + Clone { fn eq(&self, _other: &U) -> bool { todo!() } } fn main() {} </ins>

Discussion:
Let's say I want my struct to be comparable with anything that can be converted into the struct itself, but the actual comparison requires : () Errors:
For reference,
Change:
}; // Remove utf-8 BOM if any. <del> // FIXME #12884: no efficient/safe way to remove from the start of a string // and reuse the allocation. let mut src = if src.starts_with("u{feff}") { String::from(&src[3..]) } else { String::from(&src[..]) }; </del> <ins> if src.starts_with("u{feff}") { src.drain(..3); } </ins> // Append 'n' in case it's not already there. // This is a workaround to prevent CodeMap.lookup_filemap_idx from

Discussion:
cc
The rfc says It also includes an example which depends on usize: However RangeArgument only implements the first four. Furthermore as things stand it does not appear possible to accept RangeArgument<usizeand usize simultaneously, because dispatch doesn't consider the trait bound and reports that conflicting implementations exist.
Yes, was explicit about these issues. I forsee a new RFC to finish off drain and maybe the RangeArgument trait.
I believe this has
Change:
<ins> // compile-flags: --crate-type lib pub struct S { pub val: string::MyString, } pub fn test(s: S) { dbg!(s.cap) //~ ERROR: no field `cap` on type `S` [E0609] } pub(crate) mod string { pub struct MyString { buf: MyVec, } struct MyVec { cap: usize, } } </ins>

Discussion:
Lets consider the following code () : Here, we try to access a property on an object of type . Up to the 1.50 version, the error message was the following : However, since Rust 1.51 and onward, the diagnostic message changed to this: While there is indead a property on the struct, this can't be accessed like that, applying the compiler suggestion implies making the property of public, which is not possible. The compiler should not look at non- properties when searching for properties with a matching name for diagnostic purposes. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
label +A-diagnostics
Related issue: