jiebi/CodeConvo huggingface dataset:
Code change:
I think this is the fourth beta I'm having to re-figure-out how all this works and figure out how to ignore their failures on beta. can we just exclude these tools from toolstate until this is figured out?
I'm slightly confused, why would these tools need to be disabled/their submodule update if they were building on master? Isn't the beta just the current master branch + some tweaks for --version output and no unstable features? The release in March actually prevented the merge of any PRs on master that would break a tool. So I thought the idea was to fix all tools in that week. Or is this about beta backports breaking tools?
I don't think we've had a beta yet whether either clippy or miri were passing tests and fails the build if any tool fails to build on beta. We also do not want to release either of these tools to stable/beta yet.
neither of these tools has a step, so there's no danger in that (the last beta) didn't have clippy issues. Since we have grace period of a week, I can easily get in a working clippy within that week (which then won't be broken until the beta). My issue is mainly that I don't really know when it begins ;) Maybe we can ping the tool authors once a day that their tool needs to be fixed for the upcoming beta?
My point with this issue is that we shouldn't automate ourselves into a hole where tools we do not want to ship block releases. That should not require authors to fix tools, we should simply ignore failures or have an easy way of disabling them. Right now producing a beta is pain as you have to resend it to bors multiple times after re-learning that these are blocking the release. We do not ship miri/clippy but a successful clippy compilation affects how rls is compiled, which should not be happening on beta/stable.
The code that influences rls is explicitly skipped on beta/stable, so the rls is completely free of clippy on beta/stable for miri I agree, but for clippy, aren't we trying to move to a model where we actually dist it on stable, so I'd call having it ready for stable some form of proof of concept for the distributing part.
Ok sure yes rls is protected but I feel like this is missing my point. Miri isn't ready. Clippy isn't ready. They're blocking beta releases. That shouldn't happen.

Related discussion:
text: exit 0 fi <del> if grep -q fail "$TOOLSTATE_FILE"; then exit 4 fi </del> <ins> # abort compilation if an important tool doesn't build # (this code is reachable if not on the nightly channel) status_check "beta_required" </ins>
Code change:
When testing a local rebuild in Fedora -- using rustc 1.26.0 as stage0 to build rustc 1.26.0 again -- I ran into this ICE: The "slice index starts at 1 but ends at 0" comes from here: With GDB I found that is completely empty! Stepping through from the very beginning, does get the right argc and argv, calling appropriately. But the addresses of and are not where accesses later from , so that just sees and . It turns out that the bootstrap was causing my to load the freshly-built libraries, rather than its own in . The bootstrap wrapper does try to set a libdir at the front of that path, but it uses , here , so that doesn't help. This only hits local-rebuild, because normal prior-release stage0 builds have different library metadata.
Is this fixed? cc
Sorry, yes, fixed by .

Related discussion:
text: // FIXME: Temporary fix for https://github.com/rust-lang/cargo/issues/3005 // Force cargo to output binaries with disambiguating hashes in the name <del> cargo.env("__CARGO_DEFAULT_LIB_METADATA", &self.config.channel); </del> <ins> let metadata = if compiler.stage == 0 { // Treat stage0 like special channel, whether it's a normal prior- // release rustc or a local rebuild with the same version, so we // never mix these libraries by accident. "bootstrap" } else { &self.config.channel }; cargo.env("__CARGO_DEFAULT_LIB_METADATA", &metadata); </ins> let stage; if compiler.stage == 0 && self.local_rebuild {
Code change:
For type names only, submodules can't apparently see non-pub types defined in the parent module. So, this code: ... generates this error:
Now it at least tells you that is private: Though, it doesn't need to display the error twice and could do better than .
linking to for unified tracking of resolve
Closing as a dupe of , this would be allowed with the rules in that bug.

Related discussion:
text: <del> Subproject commit 8b7f7e667268921c278af94ae30a61e87a22b22b </del> <ins> Subproject commit 329923edec41d0ddbea7f30ab12fca0436d459ae </ins>
Code change:
This issue might be related to , which has been fixed in playground link: Backtrace:
removing the argument inside the closure gives a different ICE. Interestingly stable refuses to compile this, but beta and nightly ICE's playground: Backtrace:
UPDATE: now also ICE's in stable.
Now no longer ICE's since 1.32.
The ICE doesn't appear on the latest nightly via the above playground link, marked as E-needstest

Related discussion:
text: <ins> #![feature(const_raw_ptr_to_usize_cast)] fn main() { [(); &(static |x| {}) as *const _ as usize]; //~^ ERROR: closures cannot be static //~| ERROR: type annotations needed [(); &(static || {}) as *const _ as usize]; //~^ ERROR: closures cannot be static //~| ERROR: evaluation of constant value failed } </ins>
Code change:
This issue might be related to , which has been fixed in playground link: Backtrace:
removing the argument inside the closure gives a different ICE. Interestingly stable refuses to compile this, but beta and nightly ICE's playground: Backtrace:
UPDATE: now also ICE's in stable.
Now no longer ICE's since 1.32.
The ICE doesn't appear on the latest nightly via the above playground link, marked as E-needstest

Related discussion:
text: <ins> error[E0697]: closures cannot be static --> $DIR/issue-52432.rs:4:12 | LL |     [(); &(static |x| {}) as *const _ as usize]; |            ^^^^^^^^^^ error[E0697]: closures cannot be static --> $DIR/issue-52432.rs:7:12 | LL |     [(); &(static || {}) as *const _ as usize]; |            ^^^^^^^^^ error[E0282]: type annotations needed --> $DIR/issue-52432.rs:4:20 | LL |     [(); &(static |x| {}) as *const _ as usize]; |                    ^ consider giving this closure parameter a type error[E0080]: evaluation of constant value failed --> $DIR/issue-52432.rs:7:10 | LL |     [(); &(static || {}) as *const _ as usize]; |          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ "pointer-to-integer cast" needs an rfc before being allowed inside constants error: aborting due to 4 previous errors Some errors have detailed explanations: E0080, E0282, E0697. For more information about an error, try `rustc --explain E0080`. </ins>
Code change:
This issue might be related to , which has been fixed in playground link: Backtrace:
removing the argument inside the closure gives a different ICE. Interestingly stable refuses to compile this, but beta and nightly ICE's playground: Backtrace:
UPDATE: now also ICE's in stable.
Now no longer ICE's since 1.32.
The ICE doesn't appear on the latest nightly via the above playground link, marked as E-needstest

Related discussion:
text: <ins> // check-pass #![allow(dead_code)] trait Structure<E>: Sized where E: Encoding { type RefTarget: ?Sized; type FfiPtr; unsafe fn borrow_from_ffi_ptr<'a>(ptr: Self::FfiPtr) -> Option<&'a Self::RefTarget>; } enum Slice {} impl<E> Structure<E> for Slice where E: Encoding { type RefTarget = [E::Unit]; type FfiPtr = (*const E::FfiUnit, usize); unsafe fn borrow_from_ffi_ptr<'a>(_ptr: Self::FfiPtr) -> Option<&'a Self::RefTarget> { panic!() } } trait Encoding { type Unit: Unit; type FfiUnit; } trait Unit {} enum Utf16 {} impl Encoding for Utf16 { type Unit = Utf16Unit; type FfiUnit = u16; } struct Utf16Unit(pub u16); impl Unit for Utf16Unit {} type SUtf16Str = SeStr<Slice, Utf16>; struct SeStr<S, E> where S: Structure<E>, E: Encoding { _data: S::RefTarget, } impl<S, E> SeStr<S, E> where S: Structure<E>, E: Encoding { pub unsafe fn from_ptr<'a>(_ptr: S::FfiPtr) -> Option<&'a Self> { panic!() } } fn main() { const TEXT_U16: &'static [u16] = &[]; let _ = unsafe { SUtf16Str::from_ptr((TEXT_U16.as_ptr(), TEXT_U16.len())).unwrap() }; } </ins>
Code change:
This issue might be related to , which has been fixed in playground link: Backtrace:
removing the argument inside the closure gives a different ICE. Interestingly stable refuses to compile this, but beta and nightly ICE's playground: Backtrace:
UPDATE: now also ICE's in stable.
Now no longer ICE's since 1.32.
The ICE doesn't appear on the latest nightly via the above playground link, marked as E-needstest

Related discussion:
text: <ins> // check-pass #![allow(dead_code)] trait Structure<E>: Sized where E: Encoding { type RefTarget: ?Sized; type FfiPtr; unsafe fn borrow_from_ffi_ptr<'a>(ptr: Self::FfiPtr) -> Option<&'a Self::RefTarget>; } enum Slice {} impl<E> Structure<E> for Slice where E: Encoding { type RefTarget = [E::Unit]; type FfiPtr = (*const E::FfiUnit, usize); unsafe fn borrow_from_ffi_ptr<'a>(_ptr: Self::FfiPtr) -> Option<&'a Self::RefTarget> { panic!() } } trait Encoding { type Unit: Unit; type FfiUnit; } trait Unit {} enum Utf16 {} impl Encoding for Utf16 { type Unit = Utf16Unit; type FfiUnit = u16; } struct Utf16Unit(pub u16); impl Unit for Utf16Unit {} struct SUtf16Str { _data: <Slice as Structure<Utf16>>::RefTarget, } impl SUtf16Str { pub unsafe fn from_ptr<'a>(ptr: <Slice as Structure<Utf16>>::FfiPtr) -> Option<&'a Self> { std::mem::transmute::<Option<&[<Utf16 as Encoding>::Unit]>, _>( <Slice as Structure<Utf16>>::borrow_from_ffi_ptr(ptr)) } } fn main() { const TEXT_U16: &'static [u16] = &[]; let _ = unsafe { SUtf16Str::from_ptr((TEXT_U16.as_ptr(), TEXT_U16.len())).unwrap() }; } </ins>
Code change:
This issue might be related to , which has been fixed in playground link: Backtrace:
removing the argument inside the closure gives a different ICE. Interestingly stable refuses to compile this, but beta and nightly ICE's playground: Backtrace:
UPDATE: now also ICE's in stable.
Now no longer ICE's since 1.32.
The ICE doesn't appear on the latest nightly via the above playground link, marked as E-needstest

Related discussion:
text: <ins> #![feature(type_alias_impl_trait)] type Closure = impl FnOnce(); //~ ERROR: type mismatch resolving fn c() -> Closure { || -> Closure { || () } } fn main() {} </ins>
Code change:
This issue might be related to , which has been fixed in playground link: Backtrace:
removing the argument inside the closure gives a different ICE. Interestingly stable refuses to compile this, but beta and nightly ICE's playground: Backtrace:
UPDATE: now also ICE's in stable.
Now no longer ICE's since 1.32.
The ICE doesn't appear on the latest nightly via the above playground link, marked as E-needstest

Related discussion:
text: <ins> error[E0271]: type mismatch resolving `<[closure@$DIR/issue-63279.rs:6:5: 6:28] as std::ops::FnOnce<()>>::Output == ()` --> $DIR/issue-63279.rs:3:1 | LL | type Closure = impl FnOnce(); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected opaque type, found () | = note: expected type `Closure` found type `()` = note: the return type of a function must have a statically known size error: aborting due to previous error For more information about this error, try `rustc --explain E0271`. </ins>
Code change:
This issue might be related to , which has been fixed in playground link: Backtrace:
removing the argument inside the closure gives a different ICE. Interestingly stable refuses to compile this, but beta and nightly ICE's playground: Backtrace:
UPDATE: now also ICE's in stable.
Now no longer ICE's since 1.32.
The ICE doesn't appear on the latest nightly via the above playground link, marked as E-needstest

Related discussion:
text: <ins> #![feature(fn_traits, unboxed_closures)] fn test<F: for<'x> FnOnce<(&'x str,)>>(_: F) {} struct Compose<F,G>(F,G); impl<T,F,G> FnOnce<(T,)> for Compose<F,G> where F: FnOnce<(T,)>, G: FnOnce<(F::Output,)> { type Output = G::Output; extern "rust-call" fn call_once(self, (x,): (T,)) -> G::Output { (self.1)((self.0)(x)) } } struct Str<'a>(&'a str); fn mk_str<'a>(s: &'a str) -> Str<'a> { Str(s) } fn main() { let _: for<'a> fn(&'a str) -> Str<'a> = mk_str; // expected concrete lifetime, found bound lifetime parameter 'a let _: for<'a> fn(&'a str) -> Str<'a> = Str; //~^ ERROR: mismatched types test(|_: &str| {}); test(mk_str); // expected concrete lifetime, found bound lifetime parameter 'x test(Str); //~ ERROR: type mismatch in function arguments test(Compose(|_: &str| {}, |_| {})); test(Compose(mk_str, |_| {})); // internal compiler error: cannot relate bound region: //   ReLateBound(DebruijnIndex { depth: 2 }, //     BrNamed(DefId { krate: 0, node: DefIndex(6) => test::'x }, 'x(65))) //<= ReSkolemized(0, //     BrNamed(DefId { krate: 0, node: DefIndex(6) => test::'x }, 'x(65))) test(Compose(Str, |_| {})); } </ins>
Code change:
This issue might be related to , which has been fixed in playground link: Backtrace:
removing the argument inside the closure gives a different ICE. Interestingly stable refuses to compile this, but beta and nightly ICE's playground: Backtrace:
UPDATE: now also ICE's in stable.
Now no longer ICE's since 1.32.
The ICE doesn't appear on the latest nightly via the above playground link, marked as E-needstest

Related discussion:
text: <ins> error[E0308]: mismatched types --> $DIR/issue-30904.rs:20:45 | LL |     let _: for<'a> fn(&'a str) -> Str<'a> = Str; |                                             ^^^ expected concrete lifetime, found bound lifetime parameter 'a | = note: expected type `for<'a> fn(&'a str) -> Str<'a>` found type `fn(&str) -> Str<'_> {Str::<'_>}` error[E0631]: type mismatch in function arguments --> $DIR/issue-30904.rs:26:10 | LL | fn test<F: for<'x> FnOnce<(&'x str,)>>(_: F) {} |    ----    -------------------------- required by this bound in `test` ... LL | struct Str<'a>(&'a str); | ------------------------ found signature of `fn(&str) -> _` ... LL |     test(Str); |          ^^^ expected signature of `for<'x> fn(&'x str) -> _` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0308`. </ins>
Code change:
I've some code reading a stream from stdin. Wanted to wrap it in a Cursor to have it keep track of the number of bytes read already instead of having to do it manually, but started getting odd compiler errors. Since works just fine with (and ) shouldn't it work just the same with ? () Errors:
A Cursor is meant as a wrapper to Vec<u8or &mut [u8] to be able to write to them. The compiler error says that StdinLock cant be converted to a slice.
That's not how I understood it from the documentation. to me that suggests the main purpose is to provide Seek implementation. If it's only meant to wrap Vec or [u8] I think it would avoid misunderstandings to say so out right. Again suggesting Cursor is fairly generic about underlying I/O object. (FWIW if asked to name some I/O objects, I'd be pressed to consider Vec and [u8] as such.) ... The compiler error is confusing as at no point is there any (obvious) attempt to convert StdinLock into a slice. It's only ever used through the Read trait. Though looking more closely I now see the fine print later on () so I guess one could argue this is just a minor documentation issue (+ user error.) I'd still argue the behavior is surprising. StdinLock implements Read, so does Cursor, there's no obvious reason why Cursor<StdinLockwouldn't. I can sort of understand why it's currently that way, and can imagine some problems there may be generalizing it, but can't quite see any fundamental reasons for Cursor to be restricted to only Vec and [u8] and the documentation is vague enough to make that seem like a bug / unintended omission rather than intentional design / limitation.
It is a docs bug. The entire purpose of Cursor is to take a buffer of bytes and turn that into a reader by adding a cursor indicating the current position in the buffer.
Made a PR to suggest some documentation changes to better describe the intention. I do wonder though if the guard should also be included for , it could capture the problem more accurately where it's happening?
There probably should have been an bound on , but we can't add it now.

Related discussion:
text: use cmp; use io::{self, Initializer, SeekFrom, Error, ErrorKind}; <del> /// A `Cursor` wraps another type and provides it with a </del> <ins> /// A `Cursor` wraps an in-memory buffer and provides it with a </ins> /// [`Seek`] implementation. /// <del> /// `Cursor`s are typically used with in-memory buffers to allow them to /// implement [`Read`] and/or [`Write`], allowing these buffers to be used /// anywhere you might use a reader or writer that does actual I/O. </del> <ins> /// `Cursor`s are used with in-memory buffers, anything implementing /// `AsRef<[u8]>`, to allow them to implement [`Read`] and/or [`Write`], /// allowing these buffers to be used anywhere you might use a reader or writer /// that does actual I/O. </ins> /// /// The standard library implements some I/O traits on various types which /// are commonly used as a buffer, like `Cursor<`[`Vec`]`<u8>>` and
Code change:
I've some code reading a stream from stdin. Wanted to wrap it in a Cursor to have it keep track of the number of bytes read already instead of having to do it manually, but started getting odd compiler errors. Since works just fine with (and ) shouldn't it work just the same with ? () Errors:
A Cursor is meant as a wrapper to Vec<u8or &mut [u8] to be able to write to them. The compiler error says that StdinLock cant be converted to a slice.
That's not how I understood it from the documentation. to me that suggests the main purpose is to provide Seek implementation. If it's only meant to wrap Vec or [u8] I think it would avoid misunderstandings to say so out right. Again suggesting Cursor is fairly generic about underlying I/O object. (FWIW if asked to name some I/O objects, I'd be pressed to consider Vec and [u8] as such.) ... The compiler error is confusing as at no point is there any (obvious) attempt to convert StdinLock into a slice. It's only ever used through the Read trait. Though looking more closely I now see the fine print later on () so I guess one could argue this is just a minor documentation issue (+ user error.) I'd still argue the behavior is surprising. StdinLock implements Read, so does Cursor, there's no obvious reason why Cursor<StdinLockwouldn't. I can sort of understand why it's currently that way, and can imagine some problems there may be generalizing it, but can't quite see any fundamental reasons for Cursor to be restricted to only Vec and [u8] and the documentation is vague enough to make that seem like a bug / unintended omission rather than intentional design / limitation.
It is a docs bug. The entire purpose of Cursor is to take a buffer of bytes and turn that into a reader by adding a cursor indicating the current position in the buffer.
Made a PR to suggest some documentation changes to better describe the intention. I do wonder though if the guard should also be included for , it could capture the problem more accurately where it's happening?
There probably should have been an bound on , but we can't add it now.

Related discussion:
text: } impl<T> Cursor<T> { <del> /// Creates a new cursor wrapping the provided underlying I/O object. </del> <ins> /// Creates a new cursor wrapping the provided underlying in-memory buffer. </ins> /// <del> /// Cursor initial position is `0` even if underlying object (e. /// g. `Vec`) is not empty. So writing to cursor starts with /// overwriting `Vec` content, not with appending to it. </del> <ins> /// Cursor initial position is `0` even if underlying buffer (e.g. `Vec`) /// is not empty. So writing to cursor starts with overwriting `Vec` /// content, not with appending to it. </ins> /// /// # Examples ///
Code change:
Reproduced on versions: - Isolated example to reproduce: Actual error: Mentioned suggestion about "wrap into " is incorrect at all. There we should deref the value from the . - - Expected error: (something like this)
Here's where the suggestion gets issued: The motivation was to solve (where a -expression appears in tail position, which seemed likely to be a common mistake), but it turns out that there are other situations where we run into a type mismatch between match arms of a desugared expression. We regret the error.
Here's another case of this:
I see what's happening, we're only checking wether the error came from a desugaring, disregarding the types involved. It should be possible to check that information as well, even if the suggestion is only provided when it's a where everything but the error type matches. (I think it's ok if the supplied error cannot be converted to the expected error, as this suggestion exposes newcomers to a non-obvious construct at least.)
Clippy to detect this that we might want to uplift ...
(But for now I'm just going to remove the suggestion.)

Related discussion:
text: err.span_label(arm_span, msg); } } <del> hir::MatchSource::TryDesugar => { // Issue #51632 if let Ok(try_snippet) = self.tcx.sess.source_map().span_to_snippet(arm_span) { err.span_suggestion_with_applicability( arm_span, "try wrapping with a success variant", format!("Ok({})", try_snippet), Applicability::MachineApplicable, ); } } </del> <ins> hir::MatchSource::TryDesugar => {} </ins> _ => { let msg = "match arm with an incompatible type"; if self.tcx.sess.source_map().is_multiline(arm_span) {
Code change:
Reproduced on versions: - Isolated example to reproduce: Actual error: Mentioned suggestion about "wrap into " is incorrect at all. There we should deref the value from the . - - Expected error: (something like this)
Here's where the suggestion gets issued: The motivation was to solve (where a -expression appears in tail position, which seemed likely to be a common mistake), but it turns out that there are other situations where we run into a type mismatch between match arms of a desugared expression. We regret the error.
Here's another case of this:
I see what's happening, we're only checking wether the error came from a desugaring, disregarding the types involved. It should be possible to check that information as well, even if the suggestion is only provided when it's a where everything but the error type matches. (I think it's ok if the supplied error cannot be converted to the expected error, as this suggestion exposes newcomers to a non-obvious construct at least.)
Clippy to detect this that we might want to uplift ...
(But for now I'm just going to remove the suggestion.)

Related discussion:
text: <del> // Copyright 2018 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. // run-rustfix #![allow(dead_code)] fn missing_discourses() -> Result<isize, ()> { Ok(1) } fn forbidden_narratives() -> Result<isize, ()> { Ok(missing_discourses()?) //~^ ERROR try expression alternatives have incompatible types //~| HELP try wrapping with a success variant } fn main() {} </del>