jiebi/CodeConvo huggingface dataset:
Change:
I believe this should successfully compile, but it currently fails claiming that vec's iterator isn't ExactSizeIterator: Things compile correctly if the bounds are changed to rather than .
It does seem like it should compile... cc
Another instance of this from : fails with
do you know of a workaround for this bug? It's currently blocking me and I'm not entirely sure how else to structure my code.
The only workaround I know of is to remove the lifetime parameter Steven Fackler
I believe this issue I ran in to might be related - . I was trying to put a bound on an associated type from two different types and require them to be , but Rust always just wanted to assume the types must be the same. By creating a separate trait that is implemented without relying on an HRTB, and then using the HRTB around that trait, it did compile. I'm fairly sure this is a bug. rustc ought to still be able to resolve what the associated type actually is and then evaluate traits on that. It seems like it's trying to look for implementations on a hypothetical associated type black box rather than the real type it points to.
Another example, when trying to bind :
Ran into this in one of my own projects, and used this odd workaround (suggested on satck overflow):
Another variation of this issue (as far as I can tell): Fails with:
I just ran into this (): I get the following error on latest stable (1.52.1): The workaround in my case was to pull out the associated type into a type parameter, and require that it be invariant w.r.t. the universally quantified lifetime parameter ():
Fixed by , marking as needs-test because wasn't an ICE and a simple enough example I'd like to have a test for.
This bug might not be completely fixed. Here is another test case that still fails on nightly and beta: EDIT: Made the case a bit smaller:
is the smallest example I can find: This below works: While this doesn't: Can you confirm that the second case works in your PR as well?
is still not fixed on latest nightly. cc EDIT: I suspect that this example is some form of .
Another bug of this kind:

Discussion:
<ins> // check-pass fn foo<T>(t: T) -> usize where for<'a> &'a T: IntoIterator, for<'a> <&'a T as IntoIterator>::IntoIter: ExactSizeIterator, { t.into_iter().len() } fn main() { foo::<Vec<u32>>(vec![]); } </ins>

<ins> // check-pass use std::ops::Deref; struct Data { boxed: Box<&'static i32> } impl Data { fn use_data(&self, user: impl for <'a> FnOnce(<Box<&'a i32> as Deref>::Target)) { user(*self.boxed) } } fn main() {} </ins>
Change:
I believe this should successfully compile, but it currently fails claiming that vec's iterator isn't ExactSizeIterator: Things compile correctly if the bounds are changed to rather than .
It does seem like it should compile... cc
Another instance of this from : fails with
do you know of a workaround for this bug? It's currently blocking me and I'm not entirely sure how else to structure my code.
The only workaround I know of is to remove the lifetime parameter Steven Fackler
I believe this issue I ran in to might be related - . I was trying to put a bound on an associated type from two different types and require them to be , but Rust always just wanted to assume the types must be the same. By creating a separate trait that is implemented without relying on an HRTB, and then using the HRTB around that trait, it did compile. I'm fairly sure this is a bug. rustc ought to still be able to resolve what the associated type actually is and then evaluate traits on that. It seems like it's trying to look for implementations on a hypothetical associated type black box rather than the real type it points to.
Another example, when trying to bind :
Ran into this in one of my own projects, and used this odd workaround (suggested on satck overflow):
Another variation of this issue (as far as I can tell): Fails with:
I just ran into this (): I get the following error on latest stable (1.52.1): The workaround in my case was to pull out the associated type into a type parameter, and require that it be invariant w.r.t. the universally quantified lifetime parameter ():
Fixed by , marking as needs-test because wasn't an ICE and a simple enough example I'd like to have a test for.
This bug might not be completely fixed. Here is another test case that still fails on nightly and beta: EDIT: Made the case a bit smaller:
is the smallest example I can find: This below works: While this doesn't: Can you confirm that the second case works in your PR as well?
is still not fixed on latest nightly. cc EDIT: I suspect that this example is some form of .
Another bug of this kind:

Discussion:
fn main() { foo::<Vec<u32>>(vec![]); } <ins> mod another { use std::ops::Deref; fn test<T, TDeref>() where T: Deref<Target = TDeref>, TDeref: ?Sized, for<'a> &'a TDeref: IntoIterator, for<'a> <&'a TDeref as IntoIterator>::IntoIter: Clone, { } fn main() { test::<Vec<u8>, _>(); } } </ins>

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

Discussion:
/// } /// assert_eq!(buf, [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]); /// ``` <del> #[unstable(feature = "vecdeque_rotate", issue = "56686")] </del> <ins> #[stable(feature = "vecdeque_rotate", since = "1.36.0")] </ins> pub fn rotate_left(&mut self, mid: usize) { assert!(mid <= self.len()); let k = self.len() - mid;

/// # Examples /// /// ``` <del> /// #![feature(vecdeque_rotate)] /// </del> /// use std::collections::VecDeque; /// /// let mut buf: VecDeque<_> = (0..10).collect();

/// } /// assert_eq!(buf, [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]); /// ``` <del> #[unstable(feature = "vecdeque_rotate", issue = "56686")] </del> <ins> #[stable(feature = "vecdeque_rotate", since = "1.36.0")] </ins> pub fn rotate_right(&mut self, k: usize) { assert!(k <= self.len()); let mid = self.len() - k;

#![feature(repeat_generic_slice)] #![feature(try_reserve)] #![feature(unboxed_closures)] <del> #![feature(vecdeque_rotate)] </del> #![deny(rust_2018_idioms)] use std::hash::{Hash, Hasher};
Change:
If I use document comment that doesn't document anything in function, it will raise error: But if I use this in trait, the error confuses me.
From , if I use blank document comment but not in the end, it doesn't raise E0585 error. so should we adjust the error message of E0585 or adjust the parser?
When expecting an identifier, the parser will check if the non-identifier found was a documentation comment and emit E0585: An option would be to modify to check for doc comments in the same manner and complain that it isn't documenting anything (which should always be true, as by definition it should only be happening on parts of the parser that do not expect a doc comment):
will do
I don't have a lot of time right now, in case someone else wants to fix this you are free to go ahead.
Can I take a shot at this? I'm new to rust.
feel free to do so! If you look at the linked PR I believe was in the right track.
I was trying to change the function. I thought of checking if the current token is a , next token is a and the previous token is not an , then raise a . But PrevToken does not have an . So do we proceed this way or proceed in the direction of the linked PR?
you can potentially modify the following and to track but I feel that might be overkill. Why do you need ot modify the fn? The code that wrote seems correct to me, if the after identifying the bad doc comment is removed.

Discussion:
self.expect(&token::OpenDelim(token::Brace))?; let mut trait_items = vec![]; while !self.eat(&token::CloseDelim(token::Brace)) { <ins> if let token::DocComment(_) = self.token { if self.look_ahead(1, |tok| tok == &token::Token::CloseDelim(token::Brace)) { let mut err = self.diagnostic().struct_span_err_with_code( self.span, "found a documentation comment that doesn't document anything", DiagnosticId::Error("E0584".into()), ); err.help("doc comments must come before what they document, maybe a  comment was intended with `//`?", ); err.emit(); self.bump(); continue; } } </ins> let mut at_end = false; match self.parse_trait_item(&mut at_end) { Ok(item) => trait_items.push(item),

<ins> trait User{ fn test(); /// empty doc //~^ ERROR found a documentation comment that doesn't document anything } fn main() {} </ins>

<ins> error[E0584]: found a documentation comment that doesn't document anything --> $DIR/doc-inside-trait-item.rs:3:5 | LL |     /// empty doc |     ^^^^^^^^^^^^^ | = help: doc comments must come before what they document, maybe a comment was intended with `//`? error: aborting due to previous error For more information about this error, try `rustc --explain E0584`. </ins>
Change:
Minimized as best I could: With Full error:
cc
Cc
Even more minimal example:
Const eval is drunk (note the gap of relocations between the second and fourth element and again after the fourth elemen): Validation is doing everything correctly

Discussion:
relocations .iter() .map(|&(offset, reloc)| { <del> (offset + dest.offset - src.offset + (i * size * relocations.len() as u64), reloc) </del> <ins> // compute offset for current repetition let dest_offset = dest.offset + (i * size); ( // shift offsets from source allocation to destination allocation offset + dest_offset - src.offset, reloc, ) </ins> }) ); }

<ins> // compile-pass fn main() { let _ = &[("", ""); 3]; } const FOO: &[(&str, &str)] = &[("", ""); 3]; const BAR: &[(&str, &str); 5] = &[("", ""); 5]; const BAA: &[[&str; 12]; 11] = &[[""; 12]; 11]; </ins>
Change:
This can be reproduced in a centos 5 docker container, such as the one provided by python's pypa: The last command produces the following error: Versions: : : : : crashes with the same output as above
Some bisection reveals that this is a regression from actually, and I suspect the most likely candidate of that rollup is cc As to why these symbols are just now showing up, I'm not sure...
Ok I've confirmed is the cause of this bug. I don't really know how this is showing up though as none of the symbols which use are even referenced from the file: None of those symbols are even used from or LLVM or... anywhere it seems. I have no idea what's putting that into some symbol table that needs to be resolved. This may be some LLD change though because if I disable ThinLTO for LLVM itself then these symbol references seem to go away...
Ok I've bisected this to , which makes sense sort of because that's injecting references to all builtins, even if we're not actually using them. I'll follow up with LLVM later tomorrow
Or actually, I've gone ahead and opened an to get the ball rolling there. This is also a beta regression as well, so I'm retagging as such. I believe the only solution we have for now on this is to turn off ThinLTO, so I'm going to send a PR to do that.
Er turns out this is likely already fixed at , so I can try out building that locally
This seems to have regressed again: https://travis- with this Dockerfile: Relevant excerpt:
Indeed! This should be fixed in

Discussion:
source shared.sh <del> LLVM=7.0.0 </del> <ins> # Currently these commits are all tip-of-tree as of 2018-12-16, used to pick up # a fix for rust-lang/rust#56849 LLVM=032b00a5404865765cda7db3039f39d54964d8b0 LLD=3e4aa4e8671523321af51449e0569f455ef3ad43 CLANG=a6b9739069763243020f4ea6fe586bc135fde1f9 </ins> mkdir clang cd clang <del> curl https://releases.llvm.org/$LLVM/llvm-$LLVM.src.tar.xz |  xz -d |  tar xf - cd llvm-$LLVM.src </del> <ins> curl -L https://github.com/llvm-mirror/llvm/archive/$LLVM.tar.gz |  tar xzf - --strip-components=1 </ins> mkdir -p tools/clang <del> curl https://releases.llvm.org/$LLVM/cfe-$LLVM.src.tar.xz |  xz -d |  tar xf - -C tools/clang --strip-components=1 </del> <ins> curl -L https://github.com/llvm-mirror/clang/archive/$CLANG.tar.gz |  tar xzf - --strip-components=1 -C tools/clang </ins> mkdir -p tools/lld <ins> curl -L https://github.com/llvm-mirror/lld/archive/$LLD.tar.gz |  tar zxf - --strip-components=1 -C tools/lld </ins> <del> curl https://releases.llvm.org/$LLVM/lld-$LLVM.src.tar.xz |  xz -d |  tar xf - -C tools/lld --strip-components=1 mkdir ../clang-build cd ../clang-build </del> <ins> mkdir clang-build cd clang-build </ins> # For whatever reason the default set of include paths for clang is different # than that of gcc. As a result we need to manually include our sysroot's

INC="$INC:/usr/include" hide_output  <del> cmake ../llvm-$LLVM.src  </del> <ins> cmake ..  </ins> -DCMAKE_C_COMPILER=/rustroot/bin/gcc  -DCMAKE_CXX_COMPILER=/rustroot/bin/g++  -DCMAKE_BUILD_TYPE=Release
Change:
Internal compiler error happens compiling weird code with traits and associated consts. I tried this code: I expected to see this happen: compiler not to crash Instead, this happened: compiler crashed with: Playground nightly: Playground stable:
Regression seems to have happened in 1.26; Testing this with works but it doesn't with 1.26.
error: internal compiler error: Type parameter (T/1) out of range when substituting (root type=Some(T)) substs=[T] thread 'main' panicked at 'Box<Any', note: Run with for a backtrace.
the example do not ICE any more from version 1.34.0 see
I'd like to work on this (specifically to add the tests). I've tested and can confirm as that the example does not trigger an ICE anymore. Tested on:

Discussion:
<ins> // build-pass // Regression test for #56870: Internal compiler error (traits & associated consts) use std::fmt::Debug; pub trait Foo<T> { const FOO: *const u8; } impl <T: Debug> Foo<T> for dyn Debug { const FOO: *const u8 = <T as Debug>::fmt as *const u8; } pub trait Bar { const BAR: *const u8; } pub trait Baz { type Data: Debug; } pub struct BarStruct<S: Baz>(S); impl<S: Baz> Bar for BarStruct<S> { const BAR: *const u8 = <dyn Debug as Foo<<S as Baz>::Data>>::FOO; } struct AnotherStruct; #[derive(Debug)] struct SomeStruct; impl Baz for AnotherStruct { type Data = SomeStruct; } fn main() { let _x = <BarStruct<AnotherStruct> as Bar>::BAR; } </ins>
Change:
The logging section of the 0.6 docs ( ) doesn't specify how you log messages. This link is broken: It is not broken in the 0.5 docs, but I believe the API has changed.

Discussion:
error!("This is an error log") warn!("This is a warn log") info!("this is an info log") <del> debug!("This is a dubug log") </del> <ins> debug!("This is a debug log") </ins> } ```
Change:
This is a tracking issue for . Added in . Feature gate: . Related feature: in .
Did you mean in the first sentence?
Fixed.
The lint in Clippy should be updated to suggest this instead when the type is copiable.
So we a newtype because that's what we usually do. However, in this case, we could simply reuse and implement copied as: Are there notable reasons not to do this that I'm missing? Doing so would substantially decrease the cost of this feature for the standard library.
type wouldn't have the guarantees that does, as it calls the method, which can have side-effects (it shouldn't, but it's not something we can depend on). Although I suppose we currently DO expose specialization in structure when implementation is incompatible with implementation. This seems like a bug, so I will fix that in a separate PR.
See .
The comment about the type belongs in Since I see no objection to : 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] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), 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.
Am I correct that this now awaits for a stabilization PR?
Yes.
Stabilization PR is up:

Discussion:
/// # Examples /// /// ``` <del> /// #![feature(copied)] /// </del> /// let x = 12; /// let opt_x = Some(&x); /// assert_eq!(opt_x, Some(&12)); /// let copied = opt_x.copied(); /// assert_eq!(copied, Some(12)); /// ``` <del> #[unstable(feature = "copied", issue = "57126")] </del> <ins> #[stable(feature = "copied", since = "1.35.0")] </ins> pub fn copied(self) -> Option<T> { self.map(|&t| t) }

/// # Examples /// /// ``` <del> /// #![feature(copied)] /// </del> /// let mut x = 12; /// let opt_x = Some(&mut x); /// assert_eq!(opt_x, Some(&mut 12)); /// let copied = opt_x.copied(); /// assert_eq!(copied, Some(12)); /// ``` <del> #[unstable(feature = "copied", issue = "57126")] </del> <ins> #[stable(feature = "copied", since = "1.35.0")] </ins> pub fn copied(self) -> Option<T> { self.map(|&mut t| t) }

#![feature(box_syntax)] #![feature(cell_update)] <del> #![feature(copied)] </del> #![feature(core_private_bignum)] #![feature(core_private_diy_float)] #![feature(dec2flt)]
Change:
For just a few weeks now, I am seeing many cases where rustbuild rebuilds stage 0 libstd (and hence rebuilds everything) even though nothing changed there. I have not yet tried to reproduce this in a clean dir (that would take forever due to all the rebuilding), but the steps are roughly as follows: Start with a clean dir The last step will rebuild everything even though nothing changed. The timing coincides a little with libstd depending on crates io, but that could be mere coincidence. Cc
Hm, I tried in a clean dir and cannot reproduce. I could have sworn I saw this multiple times. I'll reopen if I can reproduce later.
I see this too, it doesn't reproduce with clean build. To reproduce you need to Run Make some changes to libcore or liballoc (?) (not necessarily yourself, but for example by rebasing on master). Run again. Run again, which should be no-op, but it will actually start building almost everything starting with liballoc.
I have confirmed that it's indeed can be reproduced by touching libcore.
This has been bugging me, too. I bisected the regression to . cc I don't fully understand why, but for some reason Cargo thinks that one of liballoc's dependencies has changed, but I don't see any of them being different. I'll keep poking to better understand why the fingerprint check is failing. The following is a relatively quick repro: The second build should be fresh, but it isn't.
I have posted a proposed fix for this.

Discussion:
# source tarball for a stable release you'll likely see `1.x.0` for rustc and # `0.x.0` for Cargo where they were released on `date`. <del> date: 2018-12-09 </del> <ins> date: 2019-01-04 </ins> rustc: beta cargo: beta
Change:
rustc should not compile with any warnings. Some warnings are currently denied, but not all: see , for instance, where a warning got through.
stage 0 libcore/std never denied warnings as far as I know

Discussion:
cargo.env("RUSTC_VERBOSE", self.verbosity.to_string()); <del> // in std, we want to avoid denying warnings for stage 0 as that makes cfg's painful. if self.config.deny_warnings && !(mode == Mode::Std && stage == 0) { </del> <ins> if self.config.deny_warnings { </ins> cargo.env("RUSTC_DENY_WARNINGS", "1"); }
Change:
I find the error message confusing and possibly incorrect when attempting to use as a unary operator: In current Rust stable and nightly, I get: The "help" is misleading because it is suggesting using to "perform bitwise negation." But this is not really what ~ performs. which perform different things. I think this message would be best changed to "perform bitwise NOT" or "perform bitwise one's complement"
is referred to as “bitwise not”, “binary complement” and “bitwise negation” among many other names, so the current diagnostic is valid. Not sure where the confusion might arise here, because “bitwise” implies that the operation is… well… bitwise.
would be my preferred phrasing...

Discussion:
self.struct_span_err(span_of_tilde, "`~` cannot be used as a unary operator") .span_suggestion_short( span_of_tilde, <del> "use `!` to perform bitwise negation", </del> <ins> "use `!` to perform bitwise not", </ins> "!".to_owned(), Applicability::MachineApplicable )

--> $DIR/issue-41679-tilde-bitwise-negation-attempt.rs:2:13 | LL |     let x = ~1; <del> |             ^ help: use `!` to perform bitwise negation </del> <ins> |             ^ help: use `!` to perform bitwise not </ins> error: aborting due to previous error
Change:
After +
src/bootstrap changes from should probably be backported to beta
I think this can be closed now

Discussion:
let trim_chars: &[_] = &[' ', '=']; let value = line[(idx + 1)..] <del> .trim_left_matches(trim_chars) </del> <ins> .trim_start_matches(trim_chars) </ins> .split(';') .map(PathBuf::from);

Command::new(&build.initial_rustc).arg("--version").arg("--verbose")); let local_release = local_version_verbose .lines().filter(|x| x.starts_with("release:")) <del> .next().unwrap().trim_left_matches("release:").trim(); </del> <ins> .next().unwrap().trim_start_matches("release:").trim(); </ins> let my_version = channel::CFG_RELEASE_NUM; if local_release.split('.').take(2).eq(my_version.split('.').take(2)) { build.verbose(&format!("auto-detected local-rebuild {}", local_release));