jiebi/CodeConvo huggingface dataset:
Code change:
// are contravariant while return-position lifetimes are // covariant). _marker: PhantomData<fn(&'a ()) -> &'a ()>, <ins> // Ensure `Context` is `!Send` and `!Sync` in order to allow // for future `!Send` and / or `!Sync` fields. _marker2: PhantomData<*mut ()>, </ins> } impl<'a> Context<'a> {

Related discussion:
text: (NOT A CONTRIBUTION) Waker supports wakebyref, and so it is possible to pass to another thread and wake it from that thread. This functionality would not be possible without Waker being Sync. Supporting wakers that are either not Send or not Sync will best be done by adding new APIs to Context and a new LocalWaker type.
Forgive me the naive question, but how does a type work with ? As I understand, requires , as a concrete type not a trait, so this would also require a trait? At this point we have two completely incompatible async systems... Which is only useful if is not cheap to clone, and has the burden of another lifetime bound. It surprises me that the docs don't say anything about the intended cost of .
(NOT A CONTRIBUTION) Future::poll does not take Waker as an argument, Future::poll takes Context. Context could have the ability to set a LocalWaker, so that an executor could set this. Reactors which operate on the same thread as the future that polls them could migrate to using the LocalWaker argument instead of Waker. Here is a pre-RFC that someone wrote with a possible API: Commentary like this is both factually wrong and not helpful for the mood of the thread.
Code change:
self.check_pat_walk(&field.pat, field_ty, def_bm, true); } <ins> let mut unmentioned_fields = variant.fields .iter() .map(|field| field.ident.modern()) .filter(|ident| !used_fields.contains_key(&ident)) .collect::<Vec<_>>(); </ins> if inexistent_fields.len() > 0 { let (field_names, t, plural) = if inexistent_fields.len() == 1 { (format!("a field named `{}`", inexistent_fields[0].1), "this", "")

Related discussion:
text: With a single typo in a match arm, we generate three separate errors: We should collect all these errors into a single diagnostic:
could you share sample code to exactly reproduce above diagnostic?
I will raise another PR to address the case where we are unnecessarily throwing .
Code change:
<del> // check-fail // edition:2021 // known-bug: #88908 // This should pass, but seems to run into a TAIT bug. #![feature(type_alias_impl_trait)] use std::future::Future; trait Stream { type Item; } struct Empty<T>(T); impl<T> Stream for Empty<T> { type Item = (); } fn empty<T>() -> Empty<T> { todo!() } trait X { type LineStream<'a, Repr>: Stream<Item = Repr> where Self: 'a; type LineStreamFut<'a,Repr>: Future<Output = Self::LineStream<'a, Repr>> where Self: 'a; fn line_stream<'a,Repr>(&'a self) -> Self::LineStreamFut<'a,Repr>; } struct Y; impl X for Y { type LineStream<'a, Repr> = impl Stream<Item = Repr>; type LineStreamFut<'a, Repr> = impl Future<Output = Self::LineStream<'a, Repr>> ; fn line_stream<'a, Repr>(&'a self) -> Self::LineStreamFut<'a, Repr> { async {empty()} } } fn main() {} </del>

Related discussion:
text: <!-- 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. --Playing around with (the not yet stable) and features I stumbled over the below problem, where type parameters to nested TAIT/GAT with lifetime parameters cause a "this type parameter needs to be std::marker::Sized" compiler error. The following code fails to compile with below compiler error (): In contrast, the following code, without lifetime type parameters compiles without any error. <!-- 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. --:
This gives a different error. Minimized:
GATs issue triage: not blocking. Seems like a TAITs bug; not sure there's anything for GATs to change here.
Compiles just fine now.
I guess this issue can just be closed if there's a test already?
I think test needs to be moved to correct place?
Hello, first time contributing to rust. I was trying to resolve this issue and after looking at the test I am a little confused. To me it looks like the test code is failing correctly and I can't understand where the TAIT bug is. has a concrete type whereas the function is generic over . So to me it looks like the raised error is correct. Changing the implementation to makes the code compile. I am sorry if I am missing something here. If the test is correct then would moving the test to resolve this issue? I also don't think relates to this test.
Yeah, I messed up my minimization. The test should just use the original MCVE in the OP. And that is indeed fixed.
For clarity: this can be closed when the current known-bug test is moved to the main directory for GAT tests and changed to use the OP MCVE.
Code change:
use crate::traits; use rustc_hir as hir; use rustc_hir::lang_items::LangItem; <del> use rustc_middle::ty::{self, Ty, TyCtxt, TypeVisitableExt}; </del> <ins> use rustc_middle::ty::{ self, Ty, TyCtxt, TypeSuperVisitable, TypeVisitable, TypeVisitableExt, TypeVisitor, }; </ins> use rustc_middle::ty::{GenericArg, GenericArgKind, GenericArgsRef}; use rustc_span::def_id::{DefId, LocalDefId, CRATE_DEF_ID}; use rustc_span::{Span, DUMMY_SP};

Related discussion:
text: we should change the following function to use a instead of Using a walker causes the control-flow to be a lot more complicated and given that this code is soundness-critical, we should make sure it's as easy to understand as possible <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Code change:
<ins> // Copyright 2015 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. // Regression test for issue #22655: This test should not lead to // infinite recursion. unsafe impl<T: Send + ?Sized> Send for Unique<T> { } pub struct Unique<T:?Sized> { pointer: *const T, } pub struct Node<V> { vals: V, edges: Unique<Node<V>>, } fn is_send<T: Send>() {} fn main() { is_send::<Node<&'static ()>>(); } </ins>

Related discussion:
text: EDIT: Removed talk of variance, since it doesn't seem to be the cause and it was unnecessarily longer due to it. It seems to me like is an attempt to introduce the second approach from the of RFC 738. It seems to me that the commit is actually a breaking change, because it broke my code without my changing it. Consider this reduced example (thanks to for helping me to reduce it further). This overflows on the recursive requirement evaluation: I attempted to bump the recursion limit to 2046 even and it just told me to try again with 4096, so I figure it's just going to infinitely recurse if allowed. This only seems to happen if I use a reference, so I think that has something to do with it. came up with an example that actually hangs rustc completely when using a recursive type: The real-world scenario that led me to this bug was a with keys:
cc
My suspicion (which I removed from the first post because I'm not quite sure if it's the reason) is that it has to do with variance. Creating my own similar to the one in rust but with a instead of a , OR with instead of seemed to solve the issue, but again I'm not sure if that's the reason. I figured it was because is ok to have as a covariant but must be an invariant, from my limited understanding of variance.
(More) reduced test case (reduced in that it's isolated from the stdlib): there is in fact an interaction with variance. The problem is that the "infinite cycle" detection doesn't seem to be kicking in here because an endless set of new region variables are being generated. This is probably due to the variance of . I have to think on this a second.
(Er, the variance of various things. :)
So I've kind of thought this through. I think the right fix is to enhance the trait matching system to understand that there is in fact no need to keep generating new constraints. This seems to be a bit complicated (it interacts with, among other things, ). The short-term pragmatic fix is probably to modify MarkerTrait to be invariant, not contravariant. This is stricter than necessary but probably not terrible. The implication is that if one knows that e.g. holds, that alone would not be enough to conclude that .
Code change:
<ins> // Copyright 2015 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. // Regression test for issue #22655: This test should not lead to // infinite recursion. unsafe impl<T: Send + ?Sized> Send for Unique<T> { } pub struct Unique<T:?Sized> { pointer: *const T, } pub struct Node<V> { vals: V, edges: Unique<Node<V>>, } fn is_send<T: Send>() {} fn main() { is_send::<Node<&'static ()>>(); } </ins>

Related discussion:
text: It is probably possible for us to loosen this in the future, even after 1.0, though strictly speaking it would not be backwards compatible. (I guess a more limited fix would just be to change the variance of and specifically.) (The reason it is not 100% backwards compat is because impls that are not overlapping for an invariant trait can overlap for a contravariant trait; but this is unlikely to occur except for with object types.)
I plan to work around this problem for now by changing the definition of . The underlying issue has been splintered off into .
Code change:
ClosureKind::Coroutine(CoroutineKind::Desugared(_, CoroutineSource::Block)), .. } = move_spans <ins> && can_suggest_clone </ins> { self.suggest_cloning(err, ty, expr, None, Some(move_spans)); <del> } else if self.suggest_hoisting_call_outside_loop(err, expr) { </del> <ins> } else if self.suggest_hoisting_call_outside_loop(err, expr) && can_suggest_clone { </ins> // The place where the type moves would be misleading to suggest clone. // #121466 self.suggest_cloning(err, ty, expr, None, Some(move_spans));

Related discussion:
text: ... and trying to use afterwards, which triggers Example: currently yields I suggest that it should also contain
AsRef is a library trait, so IMO we should not do that. Also to me "value moved here" is pretty much the "you need to use this as reference".
While this might be obvious to us, I've had students struggling strongly with these errors. When I tell them "just add an ampersand", they're like "Oh, that makes total sense". I don't see that as reason not to do it. Could you elaborate?
This should also handle , , .
and aren't as clear, since the object will be modified, so the user might also want to , but that can later be signalled through and/or multiple suggestions
Obvious way of doing this would involve making a language item or otherwise special in some other way. To me it is pretty clear that language and the standard library should be as independent as possible and IME a diagnostic is a pretty minor gain for the special casing involved. One could imagine a similar diagnostic independent of library traits (e.g. always suggest a reference for "value moved here" if there’s a trait implementation for also), but then the problem of suggestion not being always correct kicks in. So, I will not oppose a change that implements this without making any more of the libstd/libcore special and is always correct, but I have no idea how anybody even begin approaching this problem.
I fully agree that that is not desirable In clippy we have similar diagnostics which in this case would simply check for (see for all the paths that we resolve manually).
Triage: this still produces the same error message. Given the concerns voiced above, should this issue stay open? I suppose we could leave this open should someone come up with a clever way to handle this without special casing , but that seems unlikely.
We have diagnostic items nowadays, so we can make a diagnostic item and detect in in these situations. Though I'm not sure how easy it is to detect. The error may get reported far too late
Current :
Code change:
} fn write_valid_utf8_to_console(handle: c::HANDLE, utf8: &str) -> io::Result<usize> { <ins> debug_assert!(!utf8.is_empty()); </ins> let mut utf16 = [MaybeUninit::<u16>::uninit(); MAX_BUFFER_SIZE / 2]; <del> let mut len_utf16 = 0; for (chr, dest) in utf8.encode_utf16().zip(utf16.iter_mut()) { *dest = MaybeUninit::new(chr); len_utf16 += 1; } // Safety: We've initialized `len_utf16` values. let utf16: &[u16] = unsafe { MaybeUninit::slice_assume_init_ref(&utf16[..len_utf16]) }; </del> <ins> let utf8 = &utf8[..utf8.floor_char_boundary(utf16.len())]; let utf16: &[u16] = unsafe { // Note that this theoretically checks validity twice in the (most common) case // where the underlying byte sequence is valid utf-8 (given the check in `write()`). let result = c::MultiByteToWideChar( c::CP_UTF8,                      // CodePage c::MB_ERR_INVALID_CHARS,         // dwFlags utf8.as_ptr() as c::LPCCH,       // lpMultiByteStr utf8.len() as c::c_int,          // cbMultiByte utf16.as_mut_ptr() as c::LPWSTR, // lpWideCharStr utf16.len() as c::c_int,         // cchWideChar ); assert!(result != 0, "Unexpected error in MultiByteToWideChar"); // Safety: MultiByteToWideChar initializes `result` values. MaybeUninit::slice_assume_init_ref(&utf16[..result as usize]) }; </ins> let mut written = write_u16s(handle, &utf16)?;

Related discussion:
text: I don't think anyone has worked on optimizing this so I'm sure there's plenty of optimization potential. The results from I got from an AMD Ryzen 5 3600 machine are:
Mmh, thanks I'll also push some benchmarks for testing other cases later, since there are plenty of other cases than just "bulk-converting a bunch of text". Thanks! Nicole
Code change:
<ins> trait Trait<Type> { type Type; fn one(&self, val:  impl Trait<Type: Default>); //~^ ERROR trait takes 1 generic argument but 0 generic arguments were supplied fn two<T: Trait<Type: Default>>(&self) -> T; //~^ ERROR trait takes 1 generic argument but 0 generic arguments were supplied fn three<T>(&self) -> T where T: Trait<Type: Default>,; //~^ ERROR trait takes 1 generic argument but 0 generic arguments were supplied } fn main() {} </ins>

Related discussion:
text: <!-- [31mICE[0m: Rustc '--crate-type=lib -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error[E0107]: trait takes 1 generic argument but 0 generic arguments were supplied', 'error: internal compiler error[E0107]: trait takes 1 generic argument but 0 generic arguments were supplied' 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: --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc :thinking:
claim
Code change:
/// /// [`to_ascii_lowercase`]: #method.to_ascii_lowercase #[stable(feature = "ascii_methods_on_intrinsics", since = "1.23.0")] <del> #[rustc_const_unstable(feature = "const_make_ascii", issue = "130698")] </del> <ins> #[rustc_const_stable(feature = "const_make_ascii", since = "CURRENT_RUSTC_VERSION")] </ins> #[inline] <ins> #[cfg_attr(bootstrap, rustc_allow_const_fn_unstable(const_mut_refs))] </ins> pub const fn make_ascii_lowercase(&mut self) { // FIXME(const-hack): We would like to simply iterate using `for` loops but this isn't currently allowed in constant expressions. let mut i = 0;

Related discussion:
text: Feature gate: This is a tracking issue for marking the and methods in , , , and as "const." [x] Implementation for : [x] Implementation for : [x] Implementation for and : [x] Final comment period (FCP) [x] Stabilization PRNone yet.
fcp merge / have been stable in const since 1.52. / are unblocked now by the stabilization of
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [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.
Can the methods be included in this? Similarly const stable / since 1.52.
Yes, that sounds like a good idea. I'll try adding another PR later.
:bell: This is now entering its final comment period, as per the . :bell:
stabilises this.
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. This will be merged soon.
Code change:
<ins> fn main() { super(); //~ ERROR failed to resolve: there are too many leading `super` keywords } </ins>

Related discussion:
text: <!-- 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. --I tried to call default trait implementation from overriden method. Googling was not so useful as wanted so I started playing with "super" keyword and found this bug. Bug appears both on stable and nightly <!-- 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 --
Bisected:
Relevant code: In case it helps, the merges in nightly-2020-06-05 were , , , , , and . Playground:
Error from just before the regression was introduced (run with ):
Assigning and removing as ) in the prioritization working group.
claim
Code change:
safety: Safety::Safe, }), }); <del> let source_info = SourceInfo { span, scope: OUTERMOST_SOURCE_SCOPE }; // Some MIR passes will expect the number of parameters to match the // function declaration. for _ in 0..num_params { local_decls.push(LocalDecl::with_source_info(ty, source_info)); } </del> cfg.terminate(START_BLOCK, source_info, TerminatorKind::Unreachable); let mut body = Body::new( <del> MirSource::item(def.to_def_id()), </del> <ins> MirSource::item(def_id.to_def_id()), </ins> cfg.basic_blocks, source_scopes, local_decls, IndexVec::new(), <del> num_params, </del> <ins> inputs.len(), </ins> vec![], span, coroutine_kind, <del> Some(err), </del> <ins> Some(guar), </ins> ); <del> body.coroutine.as_mut().map(|gen| gen.yield_ty = Some(ty)); </del> <ins> body.coroutine.as_mut().map(|gen| gen.yield_ty = yield_ty); </ins> body }

Related discussion:
text: <!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code (): Somehow in the second case we think that is unconstrained even though it doesn't seem to contain more or less type information than the first case. Note also that this does not error if I use RPIT instead.
I think in the second example mir building doesn't generate code for the trailing expression because it's statically known as dead code. But I thought we were keeping around the typeck types nowadays, and typeck should be the same for both functions
I don't think that's it, same error if I put the match in a branch ():
In fact this doesn't need an empty type at all:
I think we're generating bogus MIR or THIR because of that empty match -- Are you sure the bug doesn't exist on the THIR/MIR building side, (hacked to dump the instead of )
Oh I'm sure of nothing I just assumed an unreachable in a branch would not affect anything else
So: If there's a match error, we end up constructing a failure MIR body. This will prevent us from inferring the opaque later on. edit: that last sentence was a lie Let me see if I can cook up a quick fix.
Code change:
Ok(amount as usize) } <del> #[allow(unused)] </del> fn utf16_to_utf8(utf16: &[u16], utf8: &mut [u8]) -> io::Result<usize> { <del> let mut written = 0; for chr in char::decode_utf16(utf16.iter().cloned()) { match chr { Ok(chr) => { chr.encode_utf8(&mut utf8[written..]); written += chr.len_utf8(); } Err(_) => { // We can't really do any better than forget all data and return an error. return Err(io::const_io_error!( io::ErrorKind::InvalidData, "Windows stdin in console mode does not support non-UTF-16 input;  encountered unpaired surrogate", )); } } </del> <ins> debug_assert!(utf16.len() <= c::c_int::MAX as usize); debug_assert!(utf8.len() <= c::c_int::MAX as usize); let result = unsafe { c::WideCharToMultiByte( c::CP_UTF8,                    // CodePage c::WC_ERR_INVALID_CHARS,       // dwFlags utf16.as_ptr(),                // lpWideCharStr utf16.len() as c::c_int,       // cchWideChar utf8.as_mut_ptr() as c::LPSTR, // lpMultiByteStr utf8.len() as c::c_int,        // cbMultiByte ptr::null(),                   // lpDefaultChar ptr::null_mut(),               // lpUsedDefaultChar ) }; if result == 0 { // We can't really do any better than forget all data and return an error. Err(io::const_io_error!( io::ErrorKind::InvalidData, "Windows stdin in console mode does not support non-UTF-16 input;  encountered unpaired surrogate", )) } else { Ok(result as usize) </ins> } <del> Ok(written) </del> } impl IncompleteUtf8 {

Related discussion:
text: I don't think anyone has worked on optimizing this so I'm sure there's plenty of optimization potential. The results from I got from an AMD Ryzen 5 3600 machine are:
Mmh, thanks I'll also push some benchmarks for testing other cases later, since there are plenty of other cases than just "bulk-converting a bunch of text". Thanks! Nicole
Code change:
<ins> error: expected one of `!` or `::`, found `<eof>` --> $DIR/test-compile-fail2.rs:3:1 | 3 | fail | ^^^^ expected one of `!` or `::` error: aborting due to previous error </ins>

Related discussion:
text: I have a no_std crate that imports std when testing: However, I get this error during testing: Allocating on the heap during testing does appear to work, so I'm assuming this is just a case of the warning still being emitted.
I have the same issue. Any update?
builds the crate both as a library (for doctests) and as a test executable. You only pull in std for the test executable, so the error message could be coming from building as a library.
I have the same issue, error message seems to be spurious
Yeah, the error message is emitted when building the library. Funnily enough, it does not cause the build to fail. That is, still continues running and then exits with success (0). Sadly, there is currently no way to link in a default allocator (or for that matter) for doctests. There is the unstable feature that provides , but I don't see how to achieve something similar without relying on unstable features. I simply use until this is fixed.
Related:
modify labels: +T-rustdoc
Error: Parsing label command in failed: labels +T-rustdo... Please let know if you're having trouble with this bot.
If you don't put inside the doctest it will be linked against even when testing a crate, you can think of each doctest as a separate crate. If you do want a different allocator you can add a static like in a normal binary. Even though this error message is printed the doc tests should still be running.
Also see the error is basically spurious.