jiebi/CodeConvo huggingface dataset:
Change:
let mut errors = errors.iter().flat_map(|x| x.iter()).peekable(); if errors.peek().is_some() { <del> let trait_name = ty::item_path_str(tcx, object_trait.principal.def_id); </del> <ins> let trait_name = ty::item_path_str(tcx, object_trait.def_id); </ins> span_err!(tcx.sess, span, E0038, "cannot convert to a trait object because trait `{}` is not object-safe", trait_name);

Discussion:
The following code either aborts or segfaults for me, depending on if I'm in gdb or not, on Linux: With optimizations, becomes Which means we're doing something very bad when translating this code.
Still reducing...
FWIW, I can confirm that behaviour on Windows.
cc me
Reduced: And that makes it clear the issue is not broken codegen, but rather that is mistakenly treated as object-safe (while it inherits from the non-object-safe ).
nice. cc
P-backcompat-lang, 1.0.
Hint: iterate with
takes/creates s but needs a . I'm not sure how to make these agree.
checkobjectsafety should use to enumerate the trait_ref, I think. Annoyingly this does require a right now (harder to fix than you might think).
On I get , which is an unwrap in in the supertraits iterator.
Change:
fn test_from_str_socket_addr() { assert_eq!(Ok(sa4(Ipv4Addr::new(77, 88, 21, 11), 80)), "77.88.21.11:80".parse()); <ins> assert_eq!(Ok(SocketAddrV4::new(Ipv4Addr::new(77, 88, 21, 11), 80)), "77.88.21.11:80".parse()); </ins> assert_eq!(Ok(sa6(Ipv6Addr::new(0x2a02, 0x6b8, 0, 1, 0, 0, 0, 1), 53)), "[2a02:6b8:0:1::1]:53".parse()); <ins> assert_eq!(Ok(SocketAddrV6::new(Ipv6Addr::new(0x2a02, 0x6b8, 0, 1, 0, 0, 0, 1), 53, 0, 0)), "[2a02:6b8:0:1::1]:53".parse()); </ins> assert_eq!(Ok(sa6(Ipv6Addr::new(0, 0, 0, 0, 0, 0, 0x7F00, 1), 22)), "[::127.0.0.1]:22".parse()); <ins> assert_eq!(Ok(SocketAddrV6::new(Ipv6Addr::new(0, 0, 0, 0, 0, 0, 0x7F00, 1), 22, 0, 0)), "[::127.0.0.1]:22".parse()); </ins> // without port let none: Option<SocketAddr> = "127.0.0.1".parse().ok();

Discussion:
I need to parse an ipv4 address. I feel like these impls are missing seeing as we have impls of for , and .
Change:
} } <ins> /// Given an expression type mismatch, peel any `&` expressions until we get to /// a block expression, and then suggest replacing the braces with square braces /// if it was possibly mistaken array syntax. pub(crate) fn suggest_block_to_brackets_peeling_refs( &self, diag: &mut Diagnostic, mut expr: &hir::Expr<'_>, mut expr_ty: Ty<'tcx>, mut expected_ty: Ty<'tcx>, ) { loop { match (&expr.kind, expr_ty.kind(), expected_ty.kind()) { ( hir::ExprKind::AddrOf(_, _, inner_expr), ty::Ref(_, inner_expr_ty, _), ty::Ref(_, inner_expected_ty, _), ) => { expr = *inner_expr; expr_ty = *inner_expr_ty; expected_ty = *inner_expected_ty; } (hir::ExprKind::Block(blk, _), _, _) => { self.suggest_block_to_brackets(diag, *blk, expr_ty, expected_ty); break; } _ => break, } } } /// Suggest wrapping the block in square brackets instead of curly braces /// in case the block was mistaken array syntax, e.g. `{ 1 }` -> `[ 1 ]`. pub(crate) fn suggest_block_to_brackets( &self, diag: &mut Diagnostic, blk: &hir::Block<'_>, blk_ty: Ty<'tcx>, expected_ty: Ty<'tcx>, ) { if let ty::Slice(elem_ty) | ty::Array(elem_ty, _) = expected_ty.kind() { if self.can_coerce(blk_ty, *elem_ty) && blk.stmts.is_empty() && blk.rules == hir::BlockCheckMode::DefaultBlock { let source_map = self.tcx.sess.source_map(); if let Ok(snippet) = source_map.span_to_snippet(blk.span) { if snippet.starts_with('{') && snippet.ends_with('}') { diag.multipart_suggestion_verbose( "to create an array, use square brackets instead of curly braces", vec![ ( blk.span .shrink_to_lo() .with_hi(rustc_span::BytePos(blk.span.lo().0 + 1)), "[".to_string(), ), ( blk.span .shrink_to_hi() .with_lo(rustc_span::BytePos(blk.span.hi().0 - 1)), "]".to_string(), ), ], Applicability::MachineApplicable, ); } } } } } </ins> fn is_loop(&self, id: hir::HirId) -> bool { let node = self.tcx.hir().get(id); matches!(node, Node::Expr(Expr { kind: ExprKind::Loop(..), .. }))

Discussion:
, we should provide a structured suggestion as we already do when . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
seems easy enough, claim
Change:
<ins> // Regression test for #72616, it used to emit incorrect diagnostics, like: // error[E0283]: type annotations needed for `String` //  --> src/main.rs:8:30 //   | // 5 |         let _: String = "".to_owned().try_into().unwrap(); //   |             - consider giving this pattern a type // ... // 8 |         if String::from("a") == "a".try_into().unwrap() {} //   |                              ^^ cannot infer type for struct `String` //   | //   = note: cannot satisfy `String: PartialEq<_>` use std::convert::TryInto; pub fn main() { { let _: String = "".to_owned().try_into().unwrap(); } { if String::from("a") == "a".try_into().unwrap() {} //~^ ERROR: type annotations needed } { let _: String = match "_".try_into() { Ok(a) => a, Err(_) => "".into(), }; } } </ins>

Discussion:
This is either a regression of or it was closed prematurely. Fairly minimal reproducer: - I'm still not entirely sure what is actually wrong here - is it the lifetime as in ? Anyhow - the message doesn't refer to any T that needs to be specified, and the named explicit type is not sufficient to fix the issue even when given. Happens with nightly too.
Right, so the triggering problem here is the call - with that fixed it all falls into place, but the error message is still poor.
I got hit by this bug too and in my case the fix isn't obvious (it's a mix of an iterator and ). What did you mean by "fixing the get() call"?
It has a parameter type that is a bit bonkers given the type of the Hash, which causes the type inference of the to go off into the weeds I think; doesn't change that there is a bug - this is about the diagnostics after all. is a fixed version of the broken code.
The error message should have been fixed by , marking as .
Change:
}); }); for (i = from; i <= to; ++i) { <del> addClass(document.getElementById(i), "line-highlighted"); </del> <ins> elem = document.getElementById(i); if (!elem) { break; } addClass(elem, "line-highlighted"); </ins> } } else if (ev !== null && search && !hasClass(search, "hidden") && ev.newURL) { addClass(search, "hidden");

Discussion:
When I click on the link of a function in the rendered documentation, if the function's line number is greater than , the browser navigates to line instead of the proper location. I found the relevant code here: What's the rationale behind this limitation? Can it be lifted?
Interestingly, it looks like if this limit were removed, the for loop might be a problem. Then, maybe, someone could link to a url such as which would make the page freeze up, since the loop won't exit early if the line doesn't exist. I don't know if this would be considered harmful, however. The edit would simply be to change the line to , obviously
The freeze in that loop can be avoided with something like this:
Wo, super strange old code as it seems. Good catch!
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. static X: uint = 0 as *const uint as uint; fn main() { assert_eq!(X, 0); } </ins>

Discussion:
The following program causes rustc to crash: Obviously it's badly typed (converting void to a pointer type), but the compiler shouldn't crash here right? :) output of rustc -v: rustc 0.12.0-pre-nightly ( 2014-09-11 00:05:41 +0000) backtrace from trying to compile; Let me know if you need more information.
Yes, any ICE is bad. Thanks!
Simpler: Works with every C-like enum.
I'll try to fix this one together with
Fixed in
Change:
pub struct Unfold<St, F> { f: F, /// Internal state that will be passed to the closure on the next iteration <ins> #[unstable(feature = "core")] </ins> pub state: St, }

Discussion:
compiles without any error. Notably this isn't a regression from I noticed it because has a public field that has had no stability attribute from far before . However, that PR did pick up some structs with missing stability attributes, I'm unsure of the exact circumstances when fields will get the errors or when they will not.
As points out in this isn't a bug; I didn't realise that stability propagation literally just ignores , meaning is due to the on . Closing.
Change:
fn boo(_1: Boo) -> usize { debug boo => _1;                     // in scope 0 at $DIR/enum_cast.rs:+0:8: +0:11 let mut _0: usize;                   // return place in scope 0 at $DIR/enum_cast.rs:+0:21: +0:26 <del> let mut _2: u8;                      // in scope 0 at $DIR/enum_cast.rs:+1:5: +1:8 </del> <ins> let _2: Boo;                         // in scope 0 at $DIR/enum_cast.rs:+1:5: +1:8 let mut _3: u8;                      // in scope 0 at $DIR/enum_cast.rs:+1:5: +1:8 </ins> bb0: { <del> _2 = discriminant(_1);           // scope 0 at $DIR/enum_cast.rs:+1:5: +1:17 _0 = move _2 as usize (IntToInt); // scope 0 at $DIR/enum_cast.rs:+1:5: +1:17 </del> <ins> StorageLive(_2);                 // scope 0 at $DIR/enum_cast.rs:+1:5: +1:8 _2 = move _1;                    // scope 0 at $DIR/enum_cast.rs:+1:5: +1:8 _3 = discriminant(_2);           // scope 0 at $DIR/enum_cast.rs:+1:5: +1:17 _0 = move _3 as usize (IntToInt); // scope 0 at $DIR/enum_cast.rs:+1:5: +1:17 StorageDead(_2);                 // scope 0 at $DIR/enum_cast.rs:+1:16: +1:17 </ins> return;                          // scope 0 at $DIR/enum_cast.rs:+2:2: +2:2 } }

Discussion:
noticed this 1.63→1.64 change in I tried this code: I expected to see this happen: because is non-, an error about moving out from behind a reference, like happened in 1.63 , this happened: it compiles fine in 1.64 in nightly is probably cased by Change enum-int casts to not go through MIR casts which is mentioned in It's unclear to me whether this is intentional under the banner of " behaviour", since there's no trait involved.
Prioritized as P-critical in meeting just now. This needs to be fixed by 1.65 at a minimum.
labels +T-compiler This needs work from T-compiler! :)
labels -I-lang-nominated Meeting consensus is that the current behavior is wrong and needs to be fixed.
Change:
use build_helper::output; <ins> #[cfg(not(target_os = "solaris"))] const SH_CMD: &'static str = "sh"; // On Solaris, sh is the historical bourne shell, not a POSIX shell, or bash. #[cfg(target_os = "solaris")] const SH_CMD: &'static str = "bash"; </ins> use {Build, Compiler, Mode}; use util::{cp_r, libdir, is_dylib, cp_filtered, copy};

Discussion:
The configure script begins with: This works on machines where bash implements its own version of sh. But fails on Solaris where sh and bash are separated programs. To fix, I changed that first line into: And after that it ran.
cf. .
If the problem here is that we are using bashisms in the configure script, I would rather fix that.
works for me today. Was this issue fixed? I remember some other issues...
works, but the installer has the same issue. For this reason, doesn't work on Solaris.
According to , as one example, gen- is using bashsims or other shell extensions: But in all honesty, I don't think it's worth it. I would encourage you to either rewrite the script in Python (such that it is compatible with Python 2.x and 3.x) or simply change the scripts to use instead. On Solaris, is the traditional bourne shell, not bash, and is not even POSIX compliant. This is for backwards-compatibility reasons, among others. The posix shell is .
Change:
elided = true; } // Print the offending lines <del> for line in display_lines.iter() { try!(write!(&mut err.dst, "{}:{} {}n", fm.name, *line + 1, fm.get_line(*line as int))); </del> <ins> for &line_number in display_lines.iter() { if let Some(line) = fm.get_line(line_number) { try!(write!(&mut err.dst, "{}:{} {}n", fm.name, line_number + 1, line)); } </ins> } if elided { let last_line = display_lines[display_lines.len() - 1u];

Discussion:
When trying to build with I'm getting
Is there a temporary workaround? Thanks!
Most likely change the occurrences of (or ) to . Like .
I just tripped over this ICE in serde. I love c-reduce. It came up with the following code that reproduces the bug by reducing 203K down to this in 15 minutes: Here's the error:
Change:
} } <ins> pub(super) fn try_macro_suggestion(&mut self) -> PResult<'a, P<Expr>> { let is_try = self.token.is_keyword(kw::Try); let is_questionmark = self.look_ahead(1, |t| t == &token::Not); //check for ! let is_open = self.look_ahead(2, |t| t == &token::OpenDelim(token::Paren)); //check for ( if is_try && is_questionmark && is_open { let lo = self.token.span; self.bump(); //remove try self.bump(); //remove ! let try_span = lo.to(self.token.span); //we take the try!( span self.bump(); //remove ( let is_empty = self.token == token::CloseDelim(token::Paren); //check if the block is empty self.consume_block(token::Paren, ConsumeClosingDelim::No); //eat the block let hi = self.token.span; self.bump(); //remove ) let mut err = self.struct_span_err(lo.to(hi), "use of deprecated `try` macro"); err.note("in the 2018 edition `try` is a reserved keyword, and the `try!()` macro is deprecated"); let prefix = if is_empty { "" } else { "alternatively, " }; if !is_empty { err.multipart_suggestion( "you can use the `?` operator instead", vec![(try_span, "".to_owned()), (hi, "?".to_owned())], Applicability::MachineApplicable, ); } err.span_suggestion(lo.shrink_to_lo(), &format!("{}you can still access the deprecated `try!()` macro using the "raw identifier" syntax", prefix), "r#".to_string(), Applicability::MachineApplicable); err.emit(); Ok(self.mk_expr_err(lo.to(hi))) } else { Err(self.expected_expression_found()) // The user isn't trying to invoke the try! macro } } </ins> /// Recovers a situation like `for ( $pat in $expr )` /// and suggest writing `for $pat in $expr` instead. ///

Discussion:
Old documentation and blogposts will never be updated to not talk about the macro. is It should provide structured suggestions to either use or : This request is similar in spirit to and feels like a subset of . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Would it be fine if I modified and check if the keyword is used, or is there another way to tackle this issue
Change:
| ProjectionElem::Subtype(_) | ProjectionElem::Downcast(_, _) | ProjectionElem::Field(_, _) => { <del> write!(fmt, "(").unwrap(); </del> <ins> write!(fmt, "(")?; </ins> } ProjectionElem::Deref => { <del> write!(fmt, "(*").unwrap(); </del> <ins> write!(fmt, "(*")?; </ins> } ProjectionElem::Index(_) | ProjectionElem::ConstantIndex { .. }

Discussion:
Reading the compiler code (specifically the one responsible for mir output) I found these s where probably expected . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Have you actually encountered an ICE due to this?
No, I just happened to find that. It's not a ICE, just a typo in the code
claim
Change:
}), span: sp(17,18)}, ast::DUMMY_NODE_ID), <del> span: sp(17,18)}), </del> <ins> span: sp(17,19)}), </ins> expr: None, id: ast::DUMMY_NODE_ID, rules: ast::DefaultBlock, // no idea

Discussion:
Code: Compilation attempt: It should be pointing at the semi-colon on the next line, not the comma on this line.
The note message was introduced in . It doesn't seem to handle this situation properly.
Change:
<ins> error: overriding linking modifiers from command line is not supported error: aborting due to previous error </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. --There is no code. The internal compiler error happens when building rustc itself (on MSYS2/Mingw) <!-- 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. --We are trying to build Rust 1.61.0. The error happens when building while processing the libs passed on the command line. The issue concerns native library modifiers and was most probably introduced by The line that triggers the panic is here: The code change in question broke the handling of (i.e. no bundle) which is used when building on mingw. See here for an example: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Note that we have on the rustc command line. So we have the same lib twice and one has modifiers which triggers the error. It should actually trigger an error but panics before...
Yes, the ICE is caused by used to determine the span for the error. There's a PR in progress that fixes that - Even without ICE you'll need a workaround for the error that it's masking - linking the library with modifiers either only from command line, or only from attributes. will relax these restrictions as well.
The ICE is a regression from
Fixed in
Change:
"llvm-nm", "llvm-dwarfdump", "llvm-dis", <ins> "llvm-tblgen", </ins> ] { tarball.add_file(src_bindir.join(exe(bin, target)), "bin", 0o755); }

Discussion:
In particular, this means you have to rebuild llvm for the host when cross-compiling. I tried this code: . I expected to see this happen: The compiler builds successfully. Instead, this happened: I think there's a secondary bug which is that x.py hard-codes instead of . But that seems easier to fix. <!-- 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<summaryBacktrace</summary<p</p</details
Mentoring instructions: where in it generates the component (I think I might be in ) llvm-tblgen to the binaries that are copied a PR and ask someone to run , which will generate CI artifacts. the merge commit from the build locally and confirm that works successfully (or if you're not on Linux, some other platform that's binary compatible).
label: +E-mentor
Make sure to only copy it if it exists. It doesn't get build if the llvm backend isn't enabled.
It looks like unconditionally copies llvm binaries right now, so I think should be no different.
Change:
FormatSpec, Formatter, From, <ins> FromIterator, </ins> Future, FxHashMap, FxHashSet,

Discussion:
(As I mentioned :) I tried out the migration lints on some of my own code, and ran into one false positive: A struct being used with This doesn't actually become ambiguous when FromIterator is imported, because Opt doesn't implement that. Niko :
(If we don't end up doing this, we should at least change the wording to say instead of .)
Which exact function on which type do you mean? Do you have some pointers here?
Maybe Niko meant evaluate-obligation ?
Okay I have an implementation that uh.. compiles. And seems to work, maybe? (:
Change:
<ins> #![cfg(windows)] //! An external tests use std::{ffi::OsString, os::windows::ffi::OsStringExt, path::PathBuf}; #[test] #[should_panic] fn os_string_must_know_it_isnt_utf8_issue_126291() { let mut utf8 = PathBuf::from(OsString::from("utf8".to_owned())); let non_utf8: OsString = OsStringExt::from_wide(&[0x6e, 0x6f, 0x6e, 0xd800, 0x75, 0x74, 0x66, 0x38]); utf8.set_extension(&non_utf8); utf8.into_os_string().into_string().unwrap(); } </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: Instead, this happened: (Obviously, s can't contain .) <img width="1087" alt="1" src=""<!-- 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. --:
Nice catch!
Change:
<del> #![feature(int_bits_const)] </del> #![feature(maybe_uninit_slice)] #![feature(maybe_uninit_uninit_array)]

Discussion:
Tracking issue for as introduced by Gated behind .
modify labels: +T-libs
Error: Label P can only be set by Rust team members Please let know if you're having trouble with this bot.
This has been in a few releases, is used in many places in rustc itself, and there's no open questions so far. Time to stabilize? 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.
We agreed in the libs meeting just now to revert stablization, since the is significant throughout the ecosystem, through . :( We can stabilize it again once that is solved upstream.
Closing this since has been merged.
Change:
<ins> // aux-build:uninhabited.rs #![deny(unreachable_patterns)] #![feature(never_type)] #![feature(non_exhaustive)] extern crate uninhabited; use uninhabited::PartiallyInhabitedVariants; // This test checks a redundant/useless pattern of a non-exhaustive enum/variant is still // warned against. pub fn foo(x: PartiallyInhabitedVariants) { match x { PartiallyInhabitedVariants::Struct { .. } => {}, PartiallyInhabitedVariants::Struct { .. } => {}, //~^ ERROR unreachable pattern _ => {}, } } fn main() { } </ins>

Discussion:
Say I have the following enum in crate : And I match on it in crate : The second branch is not detected to be unreachable. This is on current nightly; .
The reason for this behaviour is straightforward: reports tuple variants with non-exhaustive fields as always useful. This line was introduced in commit . I'm not quite sure what the intended semantics are so I wouldn't know how to fix it.
Please wait for to be merged before fixing this; I'm dreading having to rebase on top of the fix
cc
Change:
#[stable(feature = "rust1", since = "1.0.0")] pub trait Drop { /// A method called when the value goes out of scope. <ins> /// /// When this method has been called, `self` has not yet been deallocated. /// If it were, `self` would be a dangling reference. /// /// After this function is over, the memory of `self` will be deallocated. /// /// # Panics /// /// Given that a `panic!` will call `drop()` as it unwinds, any `panic!` in /// a `drop()` implementation will likely abort. </ins> #[stable(feature = "rust1", since = "1.0.0")] fn drop(&mut self); }

Discussion:
For example, that the struct being dropped has not been deallocated when is called (it's implied by the existence of and Rust's general reluctance to dangle pointers, but still...), and that the struct members are recursively dropped after finishes, and what happens if panics.