jiebi/CodeConvo huggingface dataset:
Change:
E0693, // incorrect `repr(align)` attribute format E0694, // an unknown tool name found in scoped attributes E0703, // invalid ABI <del> E0704, // incorrect visibility restriction </del> E0717, // rustc_promotable without stability attribute }

Discussion:
Environment: rustc 1.31.0-nightly ( 2018-10-25) and rustc 1.30.0 ( 2018-10-24) Rustc produces E0704 error code on the following (syntactically wrong) code: But but neither nor is aware of this error
I can pick this up unless you'd want to do it yourself! This will be the first the I am writing docs for errors (unless Undin wants to do it of course). I guess the general structure looks a bit like this?: Short description of the error Example of bad syntax Example of good syntax Or should there be something else I can add?
Unfortunately, at this moment I don't have enough time to fix it myself so I will be glad if you fix it
I will try my best this week! Hopefully I'll be able to create a PR on Wednesday. I'll tag you once it's done :)
Change:
/// assert_eq!(v_cloned, vec![1, 2, 3]); /// assert_eq!(v_map, vec![1, 2, 3]); /// ``` <del> #[unstable(feature = "iter_copied", issue = "57127")] </del> <ins> #[stable(feature = "iter_copied", since = "1.36.0")] </ins> fn copied<'a, T: 'a>(self) -> Copied<Self> where Self: Sized + Iterator<Item=&'a T>, T: Copy {

Discussion:
This is a tracking issue for Iterator::copied. Added in . Feature gate: . Related feature: in .
do you feel your comment in is still an objection to the state of this feature, given the response in
So ultimately, was closed meaning that we are comfortable with the specialization. If that specialization is always in place then is a redundant type (and the impls that come with it are also redundant). However, keeping the cost and the type also has less of a risk attached to it so there's a trade-off here. I don't know what the right choice is, but those are the facts as I see them.
Fixed :).
For reference, pattern is quite common according to (%5Cs%5C%7C%5Cs(%3F%3A%26%5Cs%5Cw%2B%5Cs%5C%7C%5Cs%5C%7B%3F%5Cs%5Cw%2B%7C%5Cw%2B%5Cs%5C%7C%5Cs%5C%7B%3F%5Cs%5C%5Cs%5Cw%2B)%5Cs%5C%7D%3F%5Cs*%5C)&insensitive=off&space=off&precise=off&sources=on This includes both Iterators and Options, because a regex match cannot separate those.
Is there anything blocking stabilization here? We'd like to suggest this in Clippy, see (The crux is that is clearer than , but gives off the wrong impression)
That's not my call... =D Picking random libs member... is there anything blocking stabilization here?
Doesn't seem like it. 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:
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.
Change:
|     you probably want to use this value after calling the method... = note: ...instead of the `()` output of method `push_str` <del> error: aborting due to previous error </del> <ins> error: aborting due to 3 previous errors </ins> <del> For more information about this error, try `rustc --explain E0308`. </del> <ins> Some errors have detailed explanations: E0308, E0599. For more information about an error, try `rustc --explain E0308`. </ins>

Discussion:
In long method chains we might inadvertently call a method that is not meant to be chained. When this happens, the most likely error to occur is a type error involving . We should instead look if the rhs expression is a method chain and look at all the chained call's type to find where is introduced. Given Ideally the output would be closer to <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Hi, I'd like to try working on this :) claim
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. // error-pattern:thread 'main' panicked at 'attempt to multiply with overflow' // compile-flags: -C debug-assertions fn main() { let _x = 2i32.pow(1024); } </ins>

Discussion:
Today I learned that eight to the power of eight is zero. Who'da thunk? Incorrect: :arrowright: :x: :arrowright: :x: :arrowright: :x: Correct: :arrowright: overflow :whitecheckmark: :arrowright: overflow :whitecheckmark: :arrowright: overflow :whitecheckmark: Oddly enough, this one breaks the pattern: :arrowright: overflow :whitecheck_mark: Haven't bothered with further cases; at this point it's probably best to just look at the implementation and see what's going on.
was supposed to fix this; looks like it missed the unsigned version?
says that is on nightly.
I meant that fixed this for pow() on signed integers, but not on unsigned integers; it looks like the implementation is copy-pasted for some reason.
Could I take a stab at this?
Sure; feel free to ask if you have questions.
Is overflow checking off in the libcore tests? It'd be nice to be able to write some standard tests for overflow, but they seem to not panic even on cases that should right now.
Overflow checking in unit tests () reflects whether the whole compiler was built in debug or release mode. If you need to specify the overflow mode, you can use a separate test which explicitly specifies , like .
This has since been fixed, in , which it looks like also a test, so closing.
Change:
;; i686-pc-windows-msvc) MIRI_TEST_TARGET=x86_64-unknown-linux-gnu run_tests <ins> MIRI_TEST_TARGET=x86_64-pc-windows-gnu run_tests </ins> ;; *) echo "FATAL: unknown OS"

Discussion:
Specifically, this manifested with indexing into a dvec. Not all of the code that was manipulating s was handling the case. Already fixed it, about to check in a fix. Thanks to for the test case.

It's currently ignored on Windows.
The code in question looks like: When I commented-out the ignore and a then this test passed on my Windows machine (Mingw32 + 64 bit Windows 7). So perhaps this particular issue is no more?
Fixed in

A comment suggests the type should be something richer, perhaps, than just .
Blocked on or something similar
Definitely not backwards incompatible for 1.0 if this depends on Rust 2.0 features. Renominating.
Nominating for "far-future" (does that require nomination?)
FIXME is gone, bug is too vague, closing

as per a FIXME.
Ok, so, the strings "globalenv" and "getglobalenvchan" don't appear in the source anymore, so I'm going to close this bug...
Change:
// with inherited mutability and with `&mut` // pointers. LpExtend(ref lp_base, mc::McInherited, _) | <ins> LpExtend(ref lp_base, _, LpDeref(mc::OwnedPtr)) | LpExtend(ref lp_base, _, LpDeref(mc::GcPtr)) | </ins> LpExtend(ref lp_base, _, LpDeref(mc::BorrowedPtr(ty::MutBorrow, _))) => { lp_base.clone() }

Discussion:
Nominating for P-backcompat-lang as a borrow check bug
cc
cc me
0 P-backcompat-lang.
Also, it doesn't fail when using instead of :
I think is actually irrelevant to the real bug here. The assignment shouldn't be allowed while exists since the immutable borrow freezes everything. It seems to still work with , so maybe the owned pointer version just got lost in the to transition.
Side note: the current Redex model correctly rejects this code (yay!).
I have a simple fix for this: I'm testing on top of a lot of other borrowck changes, but this code in particular wasn't modified. I'll add a test, try again on master, and submit a PR.
theoretically the to transition was just renaming the syntax, I believe is still represented in the compiler in exactly the same way that was. (Maybe could try this code on the last pre--removal compiler (or anything before that) to see if it was rejected then.)
I just figured we would have run into not actually freezing pointers a long time ago, but it's possible I suppose.
Change:
<ins> // Fix for <https://github.com/rust-lang/rust/issues/125432>. fn separate_arms() { let mut x = None; match x { None => { x = Some(0); } Some(right) => { consume(right); //~^ ERROR cannot find function `consume` in this scope } } } fn main() {} </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Maybe but probably easier to debug from scratch.
Change:
<ins> error: item does not constrain `Opaque::{opaque#0}`, but has it in its signature --> $DIR/different_args_considered_equal.rs:9:4 | LL | fn get_iter<'a>() -> impl IntoIterator<Item = Opaque<'a>> { |    ^^^^^^^^ | = note: consider moving the opaque type's declaration and defining uses into a separate module note: this opaque type is in the signature --> $DIR/different_args_considered_equal.rs:3:23 | LL | pub type Opaque<'a> = impl Sized; |                       ^^^^^^^^^^ error: aborting due to 1 previous error </ins>

Discussion:
The following should not compile. Adapted from . This is a quick issue, I did not have the chance to look into it deeper but I guess it affects ATPIT as well. cc
This used to be an error in , but then incorrectly accepted in .
Change:
let l = <$ty>::from_bits(l); let r = <$ty>::from_bits(r); let val = match bin_op { <del> Eq => PrimVal::from_bool(l.partial_cmp(&r).unwrap_or(Ordering::Greater) == Ordering::Equal), Ne => PrimVal::from_bool(l.partial_cmp(&r).unwrap_or(Ordering::Greater) != Ordering::Equal), Lt => PrimVal::from_bool(l.partial_cmp(&r).unwrap_or(Ordering::Greater) == Ordering::Less), Le => PrimVal::from_bool(l.partial_cmp(&r).unwrap_or(Ordering::Greater) != Ordering::Greater), Gt => PrimVal::from_bool(l.partial_cmp(&r).unwrap_or(Ordering::Greater) == Ordering::Greater), Ge => PrimVal::from_bool(l.partial_cmp(&r).unwrap_or(Ordering::Greater) != Ordering::Less), </del> <ins> Eq => PrimVal::from_bool(l == r), Ne => PrimVal::from_bool(l != r), Lt => PrimVal::from_bool(l < r), Le => PrimVal::from_bool(l <= r), Gt => PrimVal::from_bool(l > r), Ge => PrimVal::from_bool(l >= r), </ins> Add => PrimVal::Bytes((l + r).value.to_bits()), Sub => PrimVal::Bytes((l - r).value.to_bits()), Mul => PrimVal::Bytes((l * r).value.to_bits()),

Discussion:
The following tests do not pass for me, but I think they should, as comparisons with NaN should always simply evaluate to : I get this result on both debug and release builds. I'm on an x86_64 running Linux, rustc 1.27.0-nightly ( 2018-05-15).
Playground link for this test. Affects both debug and release, Nightly and Stable.
: ~I think this is an issue with rather than the floating-point comparisons, but I haven't dug into it yet.~
This seems to be a regression introduced by 1.26.
Reduced, . Edit: Or maybe a bug in Miri (cc
Bisection between ... gives as the regression PR, as expected.
I guess this logic, which I blindly copied, was never correct to begin with: I think this is how old const eval did it, and we didn't want to regress that. cc
Has the comment about existing bad behaviour.
The old logic used unwrap, meaning would just ICE (?). I think we can safely replace them directly as etc. Edit: The unwrap is in
The incorrect behavior mentioned in was this: If we fix the float comparison behavior, this code will no longer compile. But I think this is clearly a bug fix and breaking code like this is .
Fixed in
Change:
if let Some(term_did) = tcx.lang_items().termination() { let return_ty = main_fnsig.output(); let return_ty_span = main_fn_return_type_span(tcx, main_def_id).unwrap_or(main_span); <del> let return_ty = return_ty.skip_binder(); </del> <ins> let Some(return_ty) = return_ty.no_bound_vars() else { tcx.sess.emit_err(errors::MainFunctionReturnTypeGeneric { span: return_ty_span }); return; }; </ins> let infcx = tcx.infer_ctxt().build(); let cause = traits::ObligationCause::new( return_ty_span,

Discussion:
<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'Normalizing Alias(Weak, AliasTy { args: [ReBound(DebruijnIndex(0), BoundRegion { var: 0, kind: BrNamed(DefId(0:13 ~ 24C571BC08516AAF219327E12F0FEDBF5591EB2DFE1FD843CF7E2D7C1441FB55[8fdb]::main::'a), 'a) }), ReError], defid: DefId(0:9 ~ 24C571BC08516AAF219327E12F0FEDBF5591EB2DFE1FD843CF7E2D7C1441FB55[8fdb]::Foo) }) without wrapping in a '', 'thread 'rustc' panicked at 'Normalizing Alias(Weak, AliasTy { args: [ReBound(DebruijnIndex(0), BoundRegion { var: 0, kind: BrNamed(DefId(0:13 ~ 24C571BC08516AAF219327E12F0FEDBF5591EB2DFE1FD843CF7E2D7C1441FB55[8fdb]::main::'a), 'a) }), ReError], defid: DefId(0:9 ~ 24C571BC08516AAF219327E12F0FEDBF5591EB2DFE1FD843CF7E2D7C1441FB55[8fdb]::Foo) }) without wrapping in a '' 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: [checkmoditem_types] checking item types in top-level module [analysis] running analysis passes on this crate --
Regression in ping
Change:
const WHILE_PARSING_OR_MSG: &str = "while parsing this or-pattern starting here"; /// Whether or not an or-pattern should be gated when occurring in the current context. <del> #[derive(PartialEq)] </del> <ins> #[derive(PartialEq, Clone, Copy)] </ins> pub(super) enum GateOr { Yes, No,

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:
| LL |     Foo.bar().bar().bar().bar().baz(); |                                 ^^^ cannot infer the value of const parameter `N` declared on the associated function `baz` <ins> | help: consider specifying the const argument | LL |     Foo.bar().bar().bar().bar().baz::<N>(); |                                 ^^^^^^^^ </ins> error: aborting due to previous error

Discussion:
At the moment, we simply emit errors like: It would be good to suggest to the user how to fix this, like with uninferred type arguments.
cc
Stu over has picked this issue up.
Change:
bitrig-x86_64 6476e1562df02389b55553b4c88b1f4fd121cd40 freebsd-i386 7e624c50494402e1feb14c743d659fbd71b448f5 freebsd-x86_64 91724d4e655807a2a2e940ac50992ebeaac16ea9 <ins> dragonfly-x86_64 e74d79488e88ac2de3bd03afd5959d2ae6e2b628 </ins> linux-i386 a09c4a4036151d0cb28e265101669731600e01f2 linux-x86_64 97e2a5eb8904962df8596e95d6e5d9b574d73bf4 macos-i386 ca52d2d3ba6497ed007705ee3401cf7efc136ca1

Discussion:
The DragonflyBSD build is broken the same way the FreeBSD is broken. This is because there isn't a new enough snapshot for the platform. Let me fix that.
Change:
<ins> use std::ops::Deref; pub struct A; pub struct B; // @has recursive_deref/struct.A.html '//code' 'impl Deref for A' impl Deref for A { type Target = B; fn deref(&self) -> &Self::Target { panic!() } } // @has recursive_deref/struct.B.html '//code' 'impl Deref for B' impl Deref for B { type Target = A; fn deref(&self) -> &Self::Target { panic!() } } </ins>

Discussion:
I don't have time to make an MCVE right now. Stable and beta: ! Nightly and 1.51: ! 50: ! Either the methods should be documented, or they shouldn't be linked to. cc I suspect this is regression from the backports of
First of all, here's an MVCE: Nevermind, I see this is getting discussed in
Removed , this is not a 1.53 regression.
sure, then it's a stable-to-stable regression then. It first regressed in 1.52.
Change:
<ins> #![crate_name="foo"] // reduced from sqlx 0.7.3 use std::future::Future; use std::pin::Pin; use std::ops::{Deref, DerefMut}; pub enum Error {} pub trait Acquire<'c> { type Database: Database; type Connection: Deref<Target = <Self::Database as Database>::Connection> + DerefMut + Send; } pub trait Database { type Connection: Connection<Database = Self>; } pub trait Connection { type Database: Database; type Options: ConnectionOptions<Connection = Self>; fn begin( &mut self ) -> Pin<Box<dyn Future<Output = Result<Transaction<'_, Self::Database>, Error>> + Send + '_>> where Self: Sized; } pub trait ConnectionOptions { type Connection: Connection; } pub struct Transaction<'c, DB: Database> { _db: &'c DB, } impl<'t, 'c, DB: Database> Acquire<'t> for &'t mut Transaction<'c, DB> where <DB as Database>::Connection: Send { type Database = DB; type Connection = &'t mut <DB as Database>::Connection; } </ins>

Discussion:
sqlx was updated yesterday. and its search is now broken. compare: with:
Firefox prints those errors: with label -needs-triage +T-rustdoc +A-rustdoc-search +regression-untriaged cc
Change:
#[macro_export] macro_rules! cfg { ($($cfg:tt)*) => ({ /* compiler built-in */ }) } <del> /// Parse the current given file as an expression. /// /// This is generally a bad idea, because it's going to behave unhygienically. </del> <ins> /// Parse the file provided in the argument as an expression or an /// item according to the context. This file is located relative /// to the current file (similarly to how modules are found). /// /// Using this macro is often a bad idea, because if the file is /// parsed as an expression, it is going to be placed in the /// surrounding code unhygenically. This could result in variables /// or functions being different from what the file expected if /// there are variables or functions that have the same name in /// the current file. </ins> /// /// # Examples ///

Discussion:
The docs are: [ ] current given file? wat [ ] "as an expression" is incorrect -- it could be an item or statement according to context [ ] The second sentence is vague and confusing if you aren't familiar with hygiene. [ ] Behavior WRT relative paths is not specified (for it is). is widely used for generated code these days, so the doc should be more informative and clearly explain in which situations is a bad idea. Maybe even have an example of including generated code from $OUTDIR. Part of .
This was presumably fixed by
Change:
<ins> error: type parameter `impl Deref<Target = Self>` is part of concrete type but not used in parameter list for the `impl Trait` type alias --> $DIR/issue-57700.rs:16:58 | LL |       fn foo(self: impl Deref<Target = Self>) -> Self::Bar { |  __________________________________________________________^ LL | | LL | |         self LL | |     } | |_____^ error: aborting due to previous error </ins>

Discussion:
here is the example: this example will compile well if you remove
Backtrace: `
Hmm I reproduced same ICE with next snippet without :
Smaller repro: Edit: AFAICT the problem is the existential assoc type is being made dependent on the type parameter of the trait method ('s in this repro, 's in the OP). So it would be a compile error if it weren't for the ICE.
compiles without ICE.
sorry it needs to be feature or used 2018 edition. Here is complete one which fails to compile regardless feature:
Right, 2015 doesn't hit the error until you actually try to use the type. Regardless, as I said in my previous comment, this code should be a compile error anyway regardless of edition, since it's trying to declare an associated type that depends on the type parameters of the trait method rather than the trait.
hey have you had a chance to look into this yet? Do you think you will be looking at it in the near term, or should we unassign you?
Removed my assignment. Unfortunately I'm running behind on the not-time-critical issues I assigned to myself.
Discussed in T-compiler meeting. This is a blocker for the existential type feature. But there is no schedule yet set for stabilizing that feature. Thus, downgrading fixing this to P-medium.
This no longer produces an ICE on the latest nightly.
Yes, it was fixed by
Change:
<ins> error[E0425]: cannot find value `u` in this scope --> $DIR/issues-71798.rs:6:24 | LL |     let _ = test_ref & u; |                        ^ not found in this scope error[E0277]: the trait bound `u32: std::future::Future` is not satisfied --> $DIR/issues-71798.rs:1:25 | LL | fn test_ref(x: &u32) -> impl std::future::Future<Output = u32> + '_ { |                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::future::Future` is not implemented for `u32` LL |     *x |     -- this returned value is of type `u32` | = note: the return type of a function must have a statically known size error: aborting due to 2 previous errors Some errors have detailed explanations: E0277, E0425. For more information about an error, try `rustc --explain E0277`. </ins>

Discussion:
I'm seeing an internal compiler error on the following input (found by ):
Possibly related to , though the panic happens at a different place.
Report from cargo-bisect-rustc: searched nightlies: from nightly-2020-03-01 to nightly-2020-05-02 regressed nightly: nightly-2020-03-28 searched commits: from to regressed commit:
It is caused by a different underlying cause to .
The underlying issue is a bad interaction in the following code with the call to (called by ) which expects there not to be any unresolved lifetimes. This happens because the code is actually parsed and evaluated as ( and ).