jiebi/CodeConvo huggingface dataset:
Change:
let allow_error_code_check = allow_error_code_check.as_bool(); let mut seen_rust_tags = false; let mut seen_other_tags = false; <del> let mut data = LangString::all_false(); </del> <ins> let mut data = LangString::default(); </ins> let mut ignores = vec![]; data.original = string.to_owned();

Discussion:
is not actually allfalse - will return . It would be nice to rename it to at some point (and maybe add while we're at it). cc Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim I'll either get to it before next week is over or when is merged, whichever comes first
Change:
| LL |         K: Borrow<Q>, |            ^^^^^^^^^ required by this bound in `HashMap::<K, V, S>::get` <del> help: consider specifying the generic argument | LL |     opts.get::<Q>(opt.as_ref()); |             +++++ </del> help: consider specifying the type argument in the function call | LL |     opts.get::<Q>(opt.as_ref());

Discussion:
Gives (rustc 1.60.0-nightly 2022-01-30): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim
Change:
[_, _] => return, [_, found_revision, .., extension] => { if !IGNORES.contains(&found_revision) <del> && !expected_revisions.contains(found_revision) </del> <ins> && !expected_revisions.contains(*found_revision) </ins> // This is from `//@ stderr-per-bitwidth` <del> && !(extension == "stderr" && ["32bit", "64bit"].contains(&found_revision)) </del> <ins> && !(*extension == "stderr" && ["32bit", "64bit"].contains(&found_revision)) </ins> { // Found some unexpected revision-esque component that is not a known // compare-mode or expected revision.

Discussion:
Running on my checkout with the current master commit fails with tons of errors. here's the last few screens of messages:
Is the check looking for in the full path? My rustc checkout is in a directory called (it's my 2nd of 3 checkouts), and I suspect tidy gets confused by that.
It does CC
That code should probably use .
Oops, I will try to fix this ASAP
Submitted a fix for this at .
Change:
} /// If possible, suggest replacing `ref` with `ref mut`. <del> fn suggest_ref_mut(tcx: TyCtxt<'_>, binding_span: Span) -> Option<(String)> { let hi_src = tcx.sess.source_map().span_to_snippet(binding_span).unwrap(); </del> <ins> fn suggest_ref_mut(tcx: TyCtxt<'_>, binding_span: Span) -> Option<String> { let hi_src = tcx.sess.source_map().span_to_snippet(binding_span).ok()?; </ins> if hi_src.starts_with("ref") && hi_src["ref".len()..].starts_with(Pattern_White_Space) {

Discussion:
When trying to compile the tests for my I get this error: <details<summary</summary</detailsMy understanding is that the compiler was trying to tell me about a borrow checker error; but I have no idea where to start minimizing this error(sorry).
I have managed to get it down to two files: It doesn't work with a in the , it has to be a different file. is then needed to trigger the ICE.
modify labels: I-ICE A-macros C-Bug T-compiler
cc
Seems to be related to 2018 edition? If I use the nightly-2018-10-01 and execute it doesn't ICE, but with it does ICE. well...
Most likely related to the fact that NLL is active in Rust 2018 then.
Bisecting: Somewhere in
Confirmed. gave me the ICE on 2015 as well (forgot that in the good ol' days nll was not a thing) Also confirmed, that edition 2015 does ICE with on and not on (like edition 2018 did above).
Also ICE with
Change:
<ins> fn a() -> _ { //~^ ERROR the placeholder `_` is not allowed within types on item signatures for return types &a } fn b() -> _ { //~^ ERROR the placeholder `_` is not allowed within types on item signatures for return types &a } 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
That second function can be named anything, for the record. e.g.
Change:
<ins> // check-pass #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash trait Trait<const NAME: &'static str> { type Assoc; } impl Trait<"0"> for () { type Assoc = (); } fn main() { let _: <() as Trait<"0">>::Assoc = (); } </ins>

Discussion:
The code: It produced error: Although RFC not yet implemented, this code must work already. Or I'm wrong and this syntax does not supported by const-generics?
Not sure where you see the ICE, removing that.
This is glitch after the previous 2 issues.. It is not ICE.
To Minimal code: produce error: The variant also give this error.
Now it is ICE:
It's back to the original error.
Now it produce this errors:
The behaviour is now as expected. We just need a test now.
Const Generic RFC leads the code as possible: Is there another issue that is tracking it?
Yes, there are some subtle issues about making sure that constants in types are well-formed. The tracking issue for this is
Change:
<ins> // check-pass #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash trait Trait<const NAME: &'static str> { type Assoc; } impl Trait<"0"> for () { type Assoc = (); } fn main() { let _: <() as Trait<"0">>::Assoc = (); } </ins>

Discussion:
This code ran in the latest nightly(2019-11-19) does not compile: And it prints this error message
Reduced:
that gives a different error, because isn't defined. Perhaps you meant something like:
This appears to be working now.
Change:
} } <del> #[unstable(feature = "iter_once_with", issue = "57581")] </del> <ins> #[stable(feature = "iter_once_with", since = "1.43.0")] </ins> impl<A, F: FnOnce() -> A> DoubleEndedIterator for OnceWith<F> { fn next_back(&mut self) -> Option<A> { self.next() } } <del> #[unstable(feature = "iter_once_with", issue = "57581")] </del> <ins> #[stable(feature = "iter_once_with", since = "1.43.0")] </ins> impl<A, F: FnOnce() -> A> ExactSizeIterator for OnceWith<F> { fn len(&self) -> usize { self.gen.iter().len() } } <del> #[unstable(feature = "iter_once_with", issue = "57581")] </del> <ins> #[stable(feature = "iter_once_with", since = "1.43.0")] </ins> impl<A, F: FnOnce() -> A> FusedIterator for OnceWith<F> {} <del> #[unstable(feature = "iter_once_with", issue = "57581")] </del> <ins> #[stable(feature = "iter_once_with", since = "1.43.0")] </ins> unsafe impl<A, F: FnOnce() -> A> TrustedLen for OnceWith<F> {} /// Creates an iterator that lazily generates a value exactly once by invoking

Discussion:
This is the tracking issue for . Currently in nightly, PR = .
Is this function now ready for stabilization?
I don’t see why not. Tracked here: 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] [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:
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.
I noticed that this iterator has been stabilized a impl which I assume wasn't intentional so I've submitted to remove it.
Change:
if is_visible { field.ty(cx.tcx, substs) } else { <del> // Treat all non-visible fields as nil. They </del> <ins> // Treat all non-visible fields as TyErr. They </ins> // can't appear in any other pattern from // this match (because they are private), // so their type does not matter - but // we don't want to know they are // uninhabited. <del> cx.tcx.mk_nil() </del> <ins> cx.tcx.types.err </ins> } }).collect() }

Discussion:
the compiler unexpectedly panicked. this is a bug. I tried this code (hyper = "0.11.9"): I expected to see this happen: code compiles (two top branches are incompatible) Instead, this happened: compiler crashed; re-ordering two top branches fixes the issue : Backtrace:
Slightly simplified version (it's not valid Rust code -- not all patterns are covered -- but it crashes the compiler): Backtrace with debug logging from rustc (RUSTBACKTRACE=full RUSTLOG=rustcconsteval):
Minified:
Change:
<del> // Copyright 2013 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. extern crate sync; use std::task; use sync::MutexArc; fn test_mutex_arc_nested() { let arc = ~MutexArc::new(1); let arc2 = ~MutexArc::new(*arc); task::spawn(proc() { (*arc2).access(|mutex| { //~ ERROR instantiating a type parameter with an incompatible type }) }); } fn main() {} </del>

Discussion:
contains two sets of methods to access the Arc's wrapped object. and are tagged unsafe as "it is possible to construct a circular reference among multiple Arcs by mutating the underlying data. This creates potential for deadlock, but worse, this will guarantee a memory leak of all involved Arcs." There are also and methods defined when the inner type is freezable as that guarantees the type can't contain a . However, it's still trivially easy to deadlock using the safe methods: It seems that the consensus in was that possibility of deadlock is inherently unsafe, so should and be removed? cc
Perhaps access should fail when it is called by the same task twice? It would be nice if people didn't have to use unsafe blocks just to get normal stuff done.
Nested locks in the same task aren't the only way you can run into deadlock:
I am aware of that, but it seems to me this particular error would be easy and cheap to catch, so if we aren't doing that yet, we probably should. Personally I don't think the possibility of a deadlock should require an unsafe block.
Consensus in the past has been that deadlock is not unsafe (). You can deadlock with pipes too, with just two lines of code. The non- accessors for are unsafe for a totally different reason, which is documented in . Regarding "cheap and easy to catch" - I don't believe we should try to fail in the single-task deadlock case unless we can reliably fail in all deadlock cases (which is not out of the question but requires scheduler support, see ). A user who is used to seeing a failure message from their previous attempts which had deadlocked would be all the more confused when they find their cross-task deadlocking code does not fail.
Is the possibility of memory leakage really considered unsafe? doesn't seem to share that assumption, but I may be missing something there.
Neither or provides a way to leak memory via the safe constructors.
We currently don't officially consider leaks to be , but I think leaking past the lifetime of tasks with references is a very questionable thing to allow.
The box annihilator is not a good solution to rc reference cycles, but it is at least a solution. Cycles of MutexArcs will produce valgrind errors.
now provides a way to leak with the safe constructors.
Change:
names: FxHashMap<Symbol, usize>, } <del> // FIXME: Rustdoc has trouble proving Send/Sync for this. See #106930. #[cfg(parallel_compiler)] unsafe impl Sync for FormatArguments {} #[cfg(parallel_compiler)] unsafe impl Send for FormatArguments {} </del> impl FormatArguments { pub fn new() -> Self { Self {

Discussion:
There is a latent bug in rustdoc that hangs in when is enabled.
From the thread on :
Interestingly, also gets stuck. I believe that runs the beta (non-parallel) rustdoc. So that'd mean that rustdoc gets stuck when documenting parallel rustc, not that parallel rustdoc gets stuck when documenting rustc.
Both of the PRs that are blocked by this issue are changes that change the ast.
It seems it's not an infinite loop, but just bad (exponential?) time complexity somewhere. suggested trying out what happens when explicitly implementing Send and Sync for the new ast node, and that indeed 'fixes' the problem in So this issue has almost nothing to do with parallel compiler. It occurs in regular non-parallel rustdoc. It's just that with , the ast is Send and Sync, and apparently that takes a huge amount of time to prove when documenting rustcmiddle. (Oli is investigating.)
Data point: Adding the following snippet to will not stop it from compiling successfully, even though documenting the crate will never stop. This makes me think the issue is very much rustdoc related, as it appears to get stuck on proving .
WG-prioritization assigning priority () (note: seems not a regression) label -I-prioritize +P-high
cc
and , https://rust-
[Edit] I'm trying to solve this problem and what I'm currently observing is that the does not store all the information when using rustdoc. This causes rustdoc to recalculate many times when collecting auto trait impl and blanket trait impl. I guess it may be that rustdoc does not calculate the trait implementation on some data structures (such as ) in advance, which resulting in too deep recursion
A revealing phenomenon: The following struct in will cause rustdoc to block while proving that is : But when the generics are instantiated, it will not cause blocking: So I guess it is that causes the values in to not be reused. Because this cache needs inserting (predictions, ).
does this happen even with disabled?
If so, this is probably related to . This is how we determine the paramenv:
I can't reproduce this issue , including my local test Have there been any recent changes?
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. #![feature(const_fn)] fn main() {} const fn size_ofs(_: usize) {} const fn size_ofs2(_foo: usize) {} </ins>

Discussion:
Willing to mentor this. Fix is simple, just need to check for . We should also add a run-pass test to ensure that the above code continues to compile. Feel free to ask me if you have further questions!
I've been willing for a long time to start getting involved in some contributions to Rust, so if it's ok for you I would like to give this one a go and make it my first contribution.
Go ahead!
Change:
scrut_ty, if is_variant_list_non_exhaustive { ", which is marked as non-exhaustive" } else { "" } )); <del> if (scrut_ty == cx.tcx.types.usize || scrut_ty == cx.tcx.types.isize) && !is_empty_match && witnesses.len() == 1 && matches!(witnesses[0].ctor(), Constructor::NonExhaustive) { err.note(format!( "`{scrut_ty}` does not have a fixed maximum value, so a wildcard `_` is necessary to match  exhaustively", )); if cx.tcx.sess.is_nightly_build() { err.help(format!( "add `#![feature(precise_pointer_size_matching)]` to the crate attributes to  enable precise `{scrut_ty}` matching", )); </del> <ins> if !is_empty_match && witnesses.len() == 1 { let mut non_exhaustive_tys = FxHashSet::default(); collect_non_exhaustive_tys(&witnesses[0], &mut non_exhaustive_tys); for ty in non_exhaustive_tys { if ty == cx.tcx.types.usize || ty == cx.tcx.types.isize { err.note(format!( "`{ty}` does not have a fixed maximum value, so a wildcard `_` is necessary to match  exhaustively", )); if cx.tcx.sess.is_nightly_build() { err.help(format!( "add `#![feature(precise_pointer_size_matching)]` to the crate attributes to  enable precise `{ty}` matching", )); } } </ins> } } if let ty::Ref(_, sub_ty, _) = scrut_ty.kind() { if !sub_ty.is_inhabited_from(cx.tcx, cx.module, cx.param_env) { err.note("references are always considered inhabited");

Discussion:
Sorry about the long title :sweat_smile: Given the following code (): The current output is: Note how the first diagnostic, emitted when matching on a , contains additional information about why this exhaustive match does not pass the exhaustiveness check. Ideally, this information should be to the second diagnostic as well: modify labels: +A-exhaustiveness-checking +A-patterns +D-terse
Hm, even though has a different size on different architectures, should always be exhaustive, right? Then that code would be accepted, but the following would still error: We could have the error for this say "missing pattern: ", which would also work if there's a around it. That said, pretty sure what you describe also happens for enums too, and there we'll want to do what you suggest.
see also
I forgot this issue existed, but yeah this is a lint we want. I explained a bit about how this might be done in , if anyone wants to tackle this feel free to ping me
Change:
debug!("late_bound_in_ty = {:?}", late_bound_in_ty); for br in late_bound_in_ty.difference(&late_bound_in_trait_ref) { let br_name = match *br { <del> ty::BrNamed(_, name) => name, _ => { span_bug!( binding.span, "anonymous bound region {:?} in binding but not trait ref", br ); } </del> <ins> ty::BrNamed(_, name) => format!("lifetime `{}`", name), _ => "an anonymous lifetime".to_string(), </ins> }; // FIXME: point at the type params that don't have appropriate lifetimes: // struct S1<F: for<'a> Fn(&i32, &i32) -> &'a i32>(F); //                         ----  ----     ^^^^^^^ <del> struct_span_err!( </del> <ins> let mut err = struct_span_err!( </ins> tcx.sess, binding.span, E0582, <del> "binding for associated type `{}` references lifetime `{}`,  </del> <ins> "binding for associated type `{}` references {},  </ins> which does not appear in the trait input types", binding.item_name, br_name <del> ) .emit(); </del> <ins> ); if let ty::BrAnon(_) = *br { // The only way for an anonymous lifetime to wind up // in the return type but **also** be unconstrained is // if it only appears in "associated types" in the // input. See #62200 for an example. In this case, // though we can easily give a hint that ought to be // relevant. err.note("lifetimes appearing in an associated type are not considered constrained"); } err.emit(); </ins> } } }

Discussion:
The following code causes an error () Errors:
Reduced:
seems like this bug dates at least to when was stabilized in 1.26.0
bug dates back to at least nightly-2017-10-15 and perhaps earlier. It seems reasonable right now to assume its been present ever since was introduced.
I'm going to have to do some background reading to remember what we are supposed to do in a case like this. If you remove the occurrences of you get the same ICE behavior, and that behavior dates all the way back to rust 1.10.0:
triage: P-medium. Removing nomination. Assigning to self.
I just ran into this on 1.41.1. Attempted to minimize what I was doing and ended up basically identical to Centril's above.
If it helps, this slightly modified snippet produces no ICE but a very odd error: In that code is , so it seems like something isn't being fully expanded somewhere?
Seems related to note that in needs to be generic to compile, but the output type can be changed to
Change:
self.visit_expr(elem); self.resolve_anon_const(ct, AnonConstKind::ConstArg(IsRepeatExpr::Yes)); } <ins> ExprKind::ConstBlock(ref expr) => { self.resolve_anon_const_manual(false, AnonConstKind::InlineConst, |this| { this.visit_expr(expr) }); } </ins> ExprKind::Index(ref elem, ref idx, _) => { self.resolve_expr(elem, Some(expr)); self.visit_expr(idx);

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'no entry found for key'', 'thread 'rustc' panicked at 'no entry found for key'' File: --auto-reduced (treereduce-rust): original: 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: [mirbuilt] building MIR for [checkunsafety] unsafety-checking -- label +F-genericconstexprs
Huhu, the master artifacts -v is super confusing since the nightly date is incorrect I don't think cargo-bisect-rustc would work on that. Anyway it's ofc, nothing much else has landed since the nightly was cut. label -F-genericconstexprs +F-inline_const
ah, I would just look at the commit hash given by rustc :sweat_smile:
Change:
EnterCriticalSection(&_cs); _holding_thread = GetCurrentThreadId(); #else <del> if (timeout_in_ns == 0) { </del> <ins> if (timeout_in_ms == 0) { </ins> CHECKED(pthread_cond_wait(&_cond, &_mutex)); } else { timeval time_val;

Discussion:
I'm working on implementing for (in ), and am running into the need for an equivalent of  for /. With the current internals for , I believe the implementation could be very similar; namely: Is this something that could be in line with ?
I think this was in , but can you confirm that the one you're looking for was there?
Ah, yes, that looks perfect! Thanks.
Change:
<ins> // check-pass #![feature(impl_trait_in_bindings)] #![allow(incomplete_features)] struct A<'a>(&'a ()); trait Trait<T> {} impl<T> Trait<T> for () {} pub fn foo<'a>() { let _x: impl Trait<A<'a>> = (); } fn main() {} </ins>

Discussion:
This snippet is found in . Reduced: :
Nitpick: There's no need to put the two into different functions, you can put them both in .
Like , when using an anonymous binding (), the above code :
No longer ICEs since

With specialization, it is possible to define a default associated type that does not fulfill its trait bounds. Here is a minimal example, that surely should not compile, but does with rustc 1.35.0-nightly: Unsurprisingly, adding the main function causes an ICE. Error message and backtrace (compiled at the playground):
Triage: the latest nightly rejects the code, marking as E-needs-test.

This code generates an ICE with this message. Replacing by makes the code to compile and run fine, which is strange because ! does not implements . By removing the specialization the compiler refuses to compile the code with the error:
The ICE has been fixed in the latest nightly, marked as E-needstest
Thanks Indeed, the example compiles fine in nightly ( 2019-11-12), however, replacing the main function by these two generates the same ICE.
ah, thanks for the update! I confirmed it ()
Triage: the ICE doesn't occur anymore with the latest nightly, marking as E-needs-test.

I was attempting to figure out the feature landscape for , and I found this ICE when playing with it and specialization:
The given code builds fine on current nightly.
This is still an ICE on current nightly when not .
This code compiles without a problem whether I do or using current nightly: . Tested on Windows 10 x64 and Ubuntu x64.
Really? But on the playground, the ICE still appears. Can you check the above link?
Yes, I get an ICE in the playground when I just build.
It does ICE when using instead of .
You need or , not . It seems like a still ICE to me.
Triage: the latest nightly rejects the code without an ICE. Marking as E-needs-test.