jiebi/CodeConvo huggingface dataset:
Change:
<ins> #![allow(dead_code)] #[repr(i128)] //~ ERROR: attribute should be applied to enum struct Foo; #[repr(u128)] //~ ERROR: attribute should be applied to enum struct Bar; fn main() {} </ins>

Discussion:
<!-- 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: I expected to see this happen: compilation failure Instead, this happened: Compiles, outputs "0" <!-- 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. --: Also: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Should be a easy fix. claim
Change:
let method_item = tcx.impl_or_trait_item(def_id); let trait_id = method_item.container().id(); let trait_ref = ty::Binder(substs.to_trait_ref(tcx, trait_id)); <ins> let trait_ref = infer::normalize_associated_type(tcx, &trait_ref); </ins> match common::fulfill_obligation(ccx, DUMMY_SP, trait_ref) { traits::VtableImpl(vtable_impl) => { let impl_did = vtable_impl.impl_def_id;

Discussion:
I don't know whether this was already reported. I get an ICE when running on (also the previous commit, didn't test others). An older version works fine:
cc has Callee in trace.
My guess is or needs to normalize the substitutions/.
Getting the same ICE with but also on while running examples (works fine on 1.8.0).
Just bisected this and got Surely it regressed during the trans refactoring, but as none of the intermediate commits is building it's not exactly sure which change is to blame though. Will help investigating further.
I would try to fix this, already did one-liner fix in according to , both and the minimal testcase in passed without ICE. Will prepare the PR later ;-) (EDIT: It's with stage1. Currently building stage2 and seeing if it can pass all tests. New to compiler writing and maintenance so kindly point out anything you feel like, thanks.)

Testcase currently relying on the most recent ncollide and nphysics3d from When I get some time later today I'll try to reduce it more. Code: Error:
I investigated this further and ended up with the following test case independent from ncollide/nphysics. It causes an ICE on both beta (rustc 1.9.0-beta.2 ( 2016-05-04)) and nigthly (rustc 1.10.0-nightly ( 2016-04-28))( and compiles fine on stable. The ICE will appear with and without . This might be related to . I can try to compile this on master but it will take some time before I can download the repo and compile rustc manually. This will compile fine, without any ICE if we do at least one of the following: Implement the method explicitly on :Remove the associated type in the impl, i.e., replace with (or anything else, including itself instead of ). Remove the cast to a trait-object at the end of the .
Fixed by .
Change:
let method_item = tcx.impl_or_trait_item(def_id); let trait_id = method_item.container().id(); let trait_ref = ty::Binder(substs.to_trait_ref(tcx, trait_id)); <ins> let trait_ref = infer::normalize_associated_type(tcx, &trait_ref); </ins> match common::fulfill_obligation(ccx, DUMMY_SP, trait_ref) { traits::VtableImpl(vtable_impl) => { let impl_did = vtable_impl.impl_def_id;

Discussion:
Testcase currently relying on the most recent ncollide and nphysics3d from When I get some time later today I'll try to reduce it more. Code: Error:
I investigated this further and ended up with the following test case independent from ncollide/nphysics. It causes an ICE on both beta (rustc 1.9.0-beta.2 ( 2016-05-04)) and nigthly (rustc 1.10.0-nightly ( 2016-04-28))( and compiles fine on stable. The ICE will appear with and without . This might be related to . I can try to compile this on master but it will take some time before I can download the repo and compile rustc manually. This will compile fine, without any ICE if we do at least one of the following: Implement the method explicitly on :Remove the associated type in the impl, i.e., replace with (or anything else, including itself instead of ). Remove the cast to a trait-object at the end of the .
Fixed by .
Change:
<ins> // run-rustfix fn main() { const let _FOO: i32 = 123; //~^ ERROR const` and `let` are mutually exclusive let const _BAR: i32 = 123; //~^ ERROR `const` and `let` are mutually exclusive } </ins>

Discussion:
<!-- 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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should inform the user that and are mutually exclusive and suggest the user remove the . <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<ins> // Checks what happens when `public` is used instead of the correct, `pub` // Won't give help message for this case public let x = 1; //~^ ERROR expected one of `!` or `::`, found keyword `let` fn main() { } </ins>

Discussion:
When writing it will suggest and I think nothing should be suggested before it is validated. The statement to be suggested must be checked if it is true or not, if true it is suggested and if not it is not. The issue from: : The current output is: <!-- The following is not always necessary. --Ideally the output should look like: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Oh dear, I didn't think of that while making the PR. A possible solution could be checking if the current token is for initializing an item? Like, struct/enum/macro, etc.
I wrote this solution, but I don't know if I can use it in rustc, it's currently building
I can't work on the problem unfortunately, whoever will assign it to him you can solve it this way The block
release-assignment
claim
Trying to add a method in token: And add a check: Any other better idea?
could be the keyword, as well. looks alright, ideally the repeated block could be prevented using a macro? I'm afraid that might slightly overengineer it, though.
Change:
/// Some special error handling for the "top-level" patterns in a match arm, /// `for` loop, `let`, &c. (in contrast to subpatterns within such). <del> fn maybe_recover_unexpected_comma(&mut self, lo: Span, rc: RecoverComma) -> PResult<'a, ()> { </del> <ins> fn maybe_recover_unexpected_comma( &mut self, lo: Span, rc: RecoverComma, gate_or: GateOr, ) -> PResult<'a, ()> { </ins> if rc == RecoverComma::No || self.token != token::Comma { return Ok(()); }

Discussion:
When forgetting to include parenthesis around a tuple pattern in a for loop, the compiler gives a suggestion to use an or pattern. I would expect this, a. because it's not what most would expect if you use a comma to separate two values in a pattern, and b. because or patterns in for loops are still an unstable feature. I tried this code: As expected, the compiler gives an , error, because I forgot the parenthesis around . However, the compiler also suggests that I add a "vertical bar to match on multiple alternatives". While it does provide the correct answer (adding parenthesis), it also provides the vertical bar option, which is an unstable feature in this . While the RFC does not explicitly single out for loops as a situation where this is necessary, I believe it does apply here, because in (credit /u/ehuss for the example, which is a situation where the or pattern syntax is being used correctly, I get a error, as expected, and including resolves the error. I tested this on stable, beta, and nightly in the rust playground. The output is identical for all 3 of them. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I would like to work on this, if possible Would it just be only giving if like ?
that seems like the right approach :)
claim
Looking at this more closely I'm not sure the fix is that simple, since and seems to (Which matches the comment for )
Looking at usages of GateOr::{Yes, No}, it looks like the only top level things (Which are the only ones that give the suggestion AIUI) that are GateOr::Yes are local variable declaration patterns and for patterns EDIT: I'm gonna try just propagating the GateOr into mayberecoverunexpected_comma
Change:
<ins> // check-pass #![feature(type_alias_impl_trait)] struct Outer<T: ?Sized> { i: InnerSend<T>, } type InnerSend<T: ?Sized> = impl Send; fn constrain<T: ?Sized>() -> InnerSend<T> { () } trait SendMustNotImplDrop {} #[allow(drop_bounds)] impl<T: ?Sized + Send + Drop> SendMustNotImplDrop for T {} impl<T: ?Sized> SendMustNotImplDrop for Outer<T> {} fn main() {} </ins>

Discussion:
The full log is available from this link: From the aforementioned link:
Do you have a more concise way of reproducing this? I can't seem to get it to ICE when I run with , no matter if I use , etc.
nvm, should be using ..
This is actually reproducible even with . It seems to only ICE with feature. Command for reproduction: <details<summary<strongBacktrace</strong</summary<p</p</detailsWe don't use feature much, so it should be easy, to make a MRE, I'll try.
I found an MRE. I'll put up a fix in a second.
I found a MRE too :(
+1, I basically reproduced that in the UI test but manually expanding the part of the macro that causes the ICE.
Change:
LangItem::PartialEq, LangItem::PartialOrd, ]; <ins> pub static BINARY_OPERATORS: &'static [LangItem] = &[ LangItem::Add, LangItem::Sub, LangItem::Mul, LangItem::Div, LangItem::Rem, LangItem::BitXor, LangItem::BitAnd, LangItem::BitOr, LangItem::Shl, LangItem::Shr, LangItem::AddAssign, LangItem::SubAssign, LangItem::MulAssign, LangItem::DivAssign, LangItem::RemAssign, LangItem::BitXorAssign, LangItem::BitAndAssign, LangItem::BitOrAssign, LangItem::ShlAssign, LangItem::ShrAssign, LangItem::Index, LangItem::IndexMut, LangItem::PartialEq, LangItem::PartialOrd, ]; </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'range start index 2 out of range for slice of length 1'', 'thread 'rustc' panicked at 'range start index 2 out of range for slice of length 1'' File: --snippet: 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: [typeck] type-checking [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Regression in cc sjwang05
claim
just to jump start, I just checked the contents of in the case presented: I'm checking what breaks in the test suite if we change the slicing to (which intuitively makes more sense but am still trying to piece things together). Edit: Ah, yeah, that won't work.
Thanks for the help, turns out I could've just used instead of slicing all along . I'll submit the PR once the test suite finishes running locally. As a side note, do you know why some binops seem to have 3 args? Intuitively it'd make sense to only have 2 args for the lhs and rhs tys--my guess is that the "extra" arg is something effects-related, but I'm not familiar at all with that part of the code.
Change:
<ins> // Copyright 2016 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. pub fn foo<'a>(s: &'a mut ()) where &'a mut (): Clone { s.clone(); } fn main() {} </ins>

Discussion:
Compiler panicks instead of showing an appropriate error message in case boundaries are not satisfied. I tried this code: In the result compiler panicked with the following message:
Minimal repr:
Still panics on stable 1.15.1
Change:
fn main() {} <del> const FOO: [u8; 3] = { //~ ERROR this code is interpreted as a block expression </del> <ins> const FOO: [u8; 3] = { //~^ ERROR this is a block expression, not an array </ins> 1, 2, 3 }; const BAR: [&str; 3] = {"one", "two", "three"}; <del> //~^ ERROR this code is interpreted as a block expression </del> <ins> //~^ ERROR this is a block expression, not an array </ins> fn foo() { {1, 2, 3}; <del> //~^ ERROR this code is interpreted as a block expression </del> <ins> //~^ ERROR this is a block expression, not an array </ins> } fn bar() {

Discussion:
, we should provide a structured suggestion as we already do when . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
seems easy enough, claim
Change:
) -> Result<(), SendTimeoutError<T>> { let token = &mut Token::default(); loop { <del> // Try sending a message several times. let backoff = Backoff::new(); loop { if self.start_send(token) { let res = unsafe { self.write(token, msg) }; return res.map_err(SendTimeoutError::Disconnected); } if backoff.is_completed() { break; } else { backoff.spin_light(); } </del> <ins> // Try sending a message. if self.start_send(token) { let res = unsafe { self.write(token, msg) }; return res.map_err(SendTimeoutError::Disconnected); </ins> } if let Some(d) = deadline {

Discussion:
Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Done in I believe
assign
Change:
traits: LazyArray<DefIndex>, impls: LazyArray<TraitImpls>, incoherent_impls: LazyArray<IncoherentImpls>, <del> interpret_alloc_index: LazyArray<u32>, </del> <ins> interpret_alloc_index: LazyArray<u64>, </ins> proc_macro_data: Option<ProcMacroData>, tables: LazyTables,

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. --: I see similar behavior in stable : The example always succeeds to compile the first time, but uses a large amount of time and memory. : Upon incremental re-compilation, I almost always see one of the following errors. I saw other open issues with a similar error message as the 1.46.0 output below, but in this one the error is affected by the value the array was filled with. : Running sometimes yields a different yet similar error: On 1.46.0: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<pOn 1.46.0: </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
do you know if this is still a problem for you? claim
On 1.66.0, I still get an error upon incremental recompilation with the same code: <details<summary<strongBacktrace</strong</summary</details
Oh wow I didn't know anyone actually hit this so long ago! I turned this into a much nicer panic a few months ago:
Change:
= help: within `impl std::clone::Clone`, the trait `std::marker::Send` is not implemented for `std::rc::Rc<std::string::String>` = note: required because it appears within the type `impl std::clone::Clone` <del> error: aborting due to 4 previous errors </del> <ins> error: aborting due to 2 previous errors </ins> Some errors have detailed explanations: E0277, E0391. For more information about an error, try `rustc --explain E0277`.

Discussion:
Does not appear on Stable or Beta in the playground. () Errors: modify labels: +C-bug, A-diagnostics, D-verbose, E-needs-bisection, T-compiler Edit: nevermind the attempt of adding “regression-from-stable-to-nightly”, I didn’t fully read the description of that label, it doesn’t apply.
Error: Label regression-from-stable-to-nightly can only be set by Rust team members Please let know if you're having trouble with this bot.
This can be reproduced outside the playground by adding to your . I suspect that this is caused by we now continue trait selection instead of bailing out when we see an error type. I think we'll want to re-add some kind of bail-out logic, but I'm not sure where the best place would be.
I can confirm regression at modify labels to -E-needs-bisection.
(This bug leaked into beta channel while waiting for PR to land, I think.)
Removing as this have been prioritized already.
This one is already on master and beta backported so closing it as fixed in both channels.
Change:
/// Divide `Duration` by `f64`. /// /// # Panics <del> /// This method will panic if result is not finite, negative or overflows `Duration`. </del> <ins> /// This method will panic if result is negative, overflows `Duration` or not finite. </ins> /// /// # Examples /// ```

Discussion:
Hello. I am diagnosing why I've got a wrong duration computed from Duration::fromsecsf32()... I tried this code: I expected to see an exact 30-second duration. Instead, I've got this: which is: 30 seconds and 1024 nanos. I dig deeper into rust code and I've prepared a sample code which is computing it based on the source code: As the result I've got: Instead of exact 30 seconds and 0 nanos.
?
Works on current stable and nightly: I mean, that this issue exist for that versions.
yep, I also confirmed on:
What is interesting the function: fromsecsf64 doesn't seem to have this problem... so a quick workaround would be use it and cast from f32 to f64
Extending(?) f32 to u128 gives this addition in 1024:
CC: CC: Adding authors ... guys please take a quick look if you have a time...
f32 will naturally have trouble representing all possible nanosecond values and so doing calculations in f64 may help here somewhat. However the most appropriate approach would be to decompose the float into the whole part and the fractional part and then operate on the two separately to produce the values necessary to create the . and may work sufficiently well for the purpose. EDIT: I think we would still need to be careful about how the nanosecond fraction is handled. We cannot simply multiply the number by and then convert to an integer, because is not capable of representing integers of such degree losslessly.
We cannot simply multiply the number by and then convert to an integer, because f32 is not capable of representing integers of such degree losslessly. Small correction: is represented exactly by , the problem is with . The closest float is , which results in the 1024 ns error. For example, would have produced an exact value. I would say such loss of precision is expected for and if you want exact values, you should use the integer based methods. So I don't think this issue should be marked as a bug. It could be worthwhile to improve the code by processing the fractional part separately, but note that it will not solve this issue fundamentally. We still have the issue of mapping at most 23 fractional bits into ~30 bits, e.g. calling would still result in an inexact result.

specifically may be representable exactly, but f32 cannot represent all integers exactly. Though maybe its not a huge deal if after we end up roundtripping back to the actual integer in all cases.
Argh, I forgot that the method is not available on , so the linked PR will not work out of box. UPD: I have implemented manual fraction/exponent splitting and their conversion to integers.
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. // Test that `&T` and `&mut T` implement `Deref<T>` fn deref<U:Copy,T:Deref<U>>(t: T) -> U { *t } fn main() { let x: int = 3; let y = deref(&x); assert_eq!(y, 3); let mut x: int = 4; let y = deref(&mut x); assert_eq!(y, 4); } </ins>

Discussion:
As titled. Add the following trait implementations: This allows generic code that accepts smart pointer can take references too, e.g.
cc
yes I want this :+1:
This would also allow code to be polymorphic over &T and &mut T by accepting . A huge win imho.
The branch creates some .
Change:
) -> Option<(ty::ParamEnv<'c>, ty::ParamEnv<'c>)> { let tcx = infcx.tcx; <del> let mut select = SelectionContext::new(&infcx); </del> <ins> let mut select = SelectionContext::with_negative(&infcx, true); </ins> let mut already_visited = FxHashSet::default(); let mut predicates = VecDeque::new();

Discussion:
Hi, I noticed a weird internal error using . The smallest example I could make to reproduce the bug is an basic library project () whose contains: , , and all work fine; and as mentioned in the code, the place where is declared seems to matter. Here is the output and trace of : [log was from an out of date nightly rust, see my comment below for the log for the latest nightly as of this edit] Have a nice day.
My bad, I appear to have accidentally used a version of rust that wasn't up to date. The bug still occurs in the latest nightly, here's the backtrace: Sorry again about that.
It looks like is only checking for explicit negative impls at the very beginning, and not throughout the process. I should have a fix for this later today.
Looks like this error has been there the whole time that synthetic impls have been there - that sample fails all the way back to 1.26.0.