jiebi/CodeConvo huggingface dataset:
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. struct Obj<'a> { closure: ||: 'a -> u32 } fn main() { let o = Obj { closure: || 42 }; o.closure(); //~ ERROR type `Obj<'_>` does not implement any method in scope named `closure` //~^ NOTE use `(s.closure)(...)` if you meant to call the function stored in the `closure` field } </ins>

Discussion:
I tried to do this: And I got the error: S It seems to try to look for a member function and ignore the member variable. One person(alexchandel) in the rust irc channel said this was a bug and should work, another(p1start) said the error message should be improved.
To get this working, you need to write . The problem is that Rust will search only for methods named and not for fields. I don't know if there are plans of changing this behavior. If not, then I guess it would be nice to get a clearer error message which explains this.
I've tagged the bug so that it covers improving the error message by adding something like (s.func)(...)func.
I guess we would need to check if the type has a field with the same name as the method.
I got it working with the nice people in the channel but thanks anyway. Alright, sounds good.
Change:
<ins> // run-rustfix // See https://github.com/rust-lang/rust/issues/87955 #![deny(rust_2021_incompatible_closure_captures)] //~^ NOTE: the lint level is defined here fn main() { let a = ("hey".to_string(), "123".to_string()); let _ = || dbg!(a.0); //~^ ERROR: drop order //~| NOTE: only captures `a.0` //~| NOTE: for more information, see //~| HELP: add a dummy let to cause `a` to be fully captured } //~^ NOTE: dropped here </ins>

Discussion:
produces: It expanded the macro. This only happens when the macro invocation is the entire body of the closure.
cc
Working on a fix.
Change:
<del> // build-pass // // compile-flags: -g --emit=llvm-ir -Zunstable-options -Csplit-debuginfo=unpacked // // Make sure that we don't explode with an error if we don't actually end up emitting any `dwo`s, // as would be the case if we don't actually codegen anything. #![crate_type="rlib"] </del>

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. --glacier <!-- 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. --: Note: you need a build with rustc debug assertions enabled! <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
}, // array-ptr-cast Ptr(mt) => { <ins> if !fcx.type_is_sized_modulo_regions(fcx.param_env, mt.ty) { return Err(CastError::IllegalCast); } </ins> self.check_ref_cast(fcx, TypeAndMut { mutbl, ty: inner_ty }, mt) } _ => Err(CastError::NonScalar),

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. --: On playgrounds it seemed to affect and for , and . <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Looks like it also happens without the re-borrow, but with a different error. <details<summary<strongBacktrace</strong</summary<p</p</details
Regression in nightly-2021-11-14 found 7 bors merge commits in the specified range commit[0] 2021-11-12: Auto merge of - matthiaskrgr:rollup-ou6yrlw, r=matthiaskrgr commit[1] 2021-11-13: Auto merge of - workingjubilee:use-simd, r=MarkSimulacrum commit[2] 2021-11-13: Auto merge of - jfrimmel:rtcopychecks, r=Mark-Simulacrum commit[3] 2021-11-13: Auto merge of - mystor:expandliteral, r=petrochenkov commit[4] 2021-11-13: Auto merge of - the8472:privatize-the-means-of-rawvec-production, r=joshtriplett commit[5] 2021-11-13: Auto merge of - jhpratt:stabilize-constrawptrderef, r=oli-obk commit[6] 2021-11-13: Auto merge of - mfrw:mfrw/librustdoc, r=GuillaumeGomez ERROR: no CI builds available between and within last 167 days
Regression in nightly-2019-06-17 found 7 bors merge commits in the specified range commit[0] 2019-06-15: Auto merge of - RalfJung:cfg-if,

r=alexcrichton commit[1] 2019-06-16: Auto merge of - Centril:rollup-3p3m2fu, r=Centril commit[2] 2019-06-16: Auto merge of - matthewjasper:optimize-false-edges, r=pnkfelix commit[3] 2019-06-16: Auto merge of - chansuke:separate-unit-tests, r=petrochenkov commit[4] 2019-06-16: Auto merge of - nikomatsakis:trait-caching-perf-3, r=pnkfelix commit[5] 2019-06-16: Auto merge of - glaubitz:sparc64-ffi-abi, r=petrochenkov commit[6] 2019-06-16: Auto merge of - Centril:stabilize-underscoreconstnames, r=petrochenkov ERROR: no CI builds available between and within last 167 days
WG-prioritization assigning priority (). label -I-prioritize +P-medium
This also returns ICE, but ICE message varies between rustc version.
Change:
{ type T = Either<Left::T, Right::T>; type TRef<'a> <del> //~^ the associated type //~^^ the associated type </del> <ins> //~^ `impl` associated type signature //~^^ `impl` associated type signature </ins> where <Left as HasChildrenOf>::T: 'a, <Right as HasChildrenOf>::T: 'a

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: A slightly better error message Instead, this happened: A slightly confusing error message <!-- 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
Change:
fn main() { // check for `impl Trait<{ const }>` which has a parent of a `DefKind::TyParam` generics_of_parent_impl_trait::foo([()]); <del> //~^ error: type annotations needed: </del> <ins> //~^ error: type annotations needed </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. --Based on the example in , which after the changes in would output an error. The following code, however, does not output such an error, although I believe it should. Given the following code: <!-- Please provide a link to --The current output is: This only happens if the is included. This also compiles if you don't include the call of in main. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
dont think this is related to adtconstparams as this has the same error:
the reason this happens is because from we don't infer the value for . The error message should be improved by using in this branch for that the predicates should be searched for a relevant inference variable.
going to mentor this issue in case someone wants to fix this
claim
Change:
if let ExprKind::MethodCall(unwrap_fun, [write_call], _) = expr.kind; if unwrap_fun.ident.name == sym::unwrap; // match call to write_fmt <del> if let ExprKind::MethodCall(write_fun, [write_recv, write_arg], _) = write_call.kind; </del> <ins> if let ExprKind::MethodCall(write_fun, [write_recv, write_arg], _) = look_in_block(cx, &write_call.kind); </ins> if write_fun.ident.name == sym!(write_fmt); // match calls to std::io::stdout() / std::io::stderr () if let Some(dest_name) = if match_function_call(cx, write_recv, &paths::STDOUT).is_some() {

Discussion:
https://crater- https://crater- https://crater- https://crater- https://crater- https://crater- is likely cause (cc
I'll fix this.
Fixed on beta with and on master. will be a more complete change and will likely land in 1.63 (or later).
Change:
impl Drop for Args { fn drop(&mut self) { <ins> // self.cur can be null if CommandLineToArgvW previously failed, // but LocalFree ignores NULL pointers </ins> unsafe { c::LocalFree(self.cur as *mut c_void); } } }

Discussion:
I'm looking at , and trying to find out the thread-safety of . Along the way, I noticed that , despite I'm allergic to Windows, so I've no idea what might cause this dangerous return value.
While it may be nice to have a comment to this effect, I don't think that this is a problem. The only time we actually look at the pointer is during iteration, and that only happens if the count/range returns an item. In the case that NULL is returned the count will be 0, so the pointer is never looked at. Additionally, ignores NULL pointer arguments, so I don't think that there's actually a problem here. All that being said, though, a comment would be nice.
Change:
<del> //@ known-bug: #122736 fn main_ref() { let array = [(); { let mut x = &0; let mut n = 0; while n < 5 { x = &0; } 0 }]; let mut ptrs: Vec<*const [u8]> = vec![&array[0..0], &array[0..1], &array, &array[1..]]; } fn main() {} </del>

Discussion:
<!-- [31mICE[0m: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' 'thread 'rustc' panicked at 'called on a value'', 'thread 'rustc' panicked at 'called on a value'' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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: note: compiler flags: -Z incremental-verify-ich=yes -C incremental=[REDACTED] -C debuginfo=2 [checkmodprivacy] checking privacy in top-level module [analysis] running analysis passes on this crate --
this bisects to
Change:
} } <del> pub fn to_title(c: char) -> [char; 3] { match bsearch_case_table(c, to_titlecase_table) { None        => [c, '0', '0'], Some(index) => to_titlecase_table[index].1 } } </del> fn bsearch_case_table(c: char, table: &'static [(char, [char; 3])]) -> Option<usize> { match table.binary_search_by(|&(key, _)| { if c == key { Equal }

Discussion:
Converting a string to titlecase requires a word-breaking algorithm, which std does not provide. We do have the method for converting a single char to titlecase, if one can identify the first char of a word. This method requires a few kb of lookup tables. We might want to consider whether its wise to ship one without the other. This is marked for stabilization in 1.2 so we need to decide soon. cc
so I'm fine just deleting it, I don't think it's marked to be stable.
Change:
return DummyResult::expr(sp); } Ok(..) => { <ins> // Add this input file to the code map to make it available as // dependency information, but don't enter it's contents let filename = format!("{}", file.display()); cx.codemap().new_filemap(filename, "".to_string()); </ins> base::MacEager::expr(cx.expr_lit(sp, ast::LitBinary(Rc::new(bytes)))) } }

Discussion:
This causes cargo to misbehave: Tagging as E-easy, since the appropriate fix.
I'm going to try and fix this.
After reading the files and , I have come up with a plan. This is a little bit tricky, since with , we know that we are including utf-8 content, so it's safe to store the source as a String in a . We don't know that for , but I don't think we actually need to track the contents anyways, so I'm passing to . Currently building, I'll see if that fixes it.
This should have been Can someone with power close?
Indeed!
Change:
#[cfg(stage1)] #[cfg(stage2)] <ins> #[cfg(stage3)] </ins> impl Reader for @Reader { fn read(&self, bytes: &mut [u8], len: uint) -> uint { self.read(bytes, len)

Discussion:
Kind of annoying to not have this imported by default.
Would it be an option to implement WriterUtils functionality as default methods on Writer? A similar situation exists with ReaderUtil too.
yes, that is a good use case for default methods, but they don't work yet.
Change:
<ins> trait Foo: std::fmt::Debug {} fn print_foos(foos: impl Iterator<Item = dyn Foo>) { foos.for_each(|foo| { //~ ERROR [E0277] println!("{:?}", foo); //~ ERROR [E0277] }); } fn main() {} </ins>

Discussion:
Notice how the last 2 suggestions aren't valid in such a closure: The suggestions given in should help me get closer to fixing the error, or at least not have invalid syntax. No response No response Output of :
(if is used in the snippet, comes up again with leaking implementation details)
Change:
all: $(RUSTC) foo.rs -C lto -O --target wasm32-unknown-unknown wc -c < $(TMPDIR)/foo.wasm <del> [ "`wc -c < $(TMPDIR)/foo.wasm`" -lt "20500" ] </del> <ins> [ "`wc -c < $(TMPDIR)/foo.wasm`" -lt "25000" ] </ins> else all: endif

Discussion:
Stack trace: Examples:
In we build with LLVM assertions enabled, but there is no messages from the log, meaning the segfault is not caused by broken assertions.
When setting opt-level=3 I believe that also changes the C/C++ code's optimization level, so this may be a but in clang's O3 optimization passes as well (and may in theory be fixable by compiling C++ code with O2)
I inspected generated CMake files and LLVM is built with nowadays but Rust is still using . How can I see if reapplying works without possibly breaking CI?
mentions LLVM7.0. Rust recently . So is this still an issue?
Change:
/// # Examples /// /// ``` <del> /// #![feature(str_strip)] </del> /// assert_eq!("bar:foo".strip_suffix(":foo"), Some("bar")); /// assert_eq!("bar:foo".strip_suffix("bar"), None); /// assert_eq!("foofoo".strip_suffix("foo"), Some("foo")); /// ``` #[must_use = "this returns the remaining substring as a new slice,  without modifying the original"] <del> #[unstable(feature = "str_strip", reason = "newly added", issue = "67302")] </del> <ins> #[stable(feature = "str_strip", since = "1.45.0")] </ins> pub fn strip_suffix<'a, P>(&'a self, suffix: P) -> Option<&'a str> where P: Pattern<'a>,

Discussion:
Cc Will fill the content later. Creating this so that can be merged and tracked.
The code generated by is really complicated and inefficient. Godbolt link: Should we add / method directly to or trait?
Oof that does indeed look pretty bad.
I whipped up that fix here: Not sure if it's actually the ideal fix, but figured it would be a good point to launch the discussion from.
Ok, the code should be far more optimized now. What remains to be done? The main issue description has yet to be filled in.
On , I'm seeing that is much faster than , at least for newlines only. Is this only because I'm stripping off a very small amount of text, or is this function more optimized than (assuming that I didn't screw something up)? See "Standard strip suffix" versus "Standard trim end", with "unix" having the input of and "win" being : !
Ah, yeah, looks the optimizations I made to stripprefix/stripsuffix in are optimizations that don't exist for : I wonder if could be reimplemented as a loop over ... By the way, since I'm here, (or anyone else on the Rust team), what remains to be done for this issue?
If you want to change the implementation this is a good time. Else, the thing left is stabilisation with the libs team approving it (if needed) but i'd wait for some time to check if there are any other issues.
The implementation is now faster than the existing similar stable functions and , so I think we're in a good spot implementation wise. Would you be able to add a note about the progress and when we expect to start the stabilization discussion in the issue description? (Or whatever normally goes in there?)
you can submit a stabilisation PR by following the instructions here:
Change:
|| self.suggest_boxing_when_appropriate(err, expr, expected, expr_ty) || self.suggest_block_to_brackets_peeling_refs(err, expr, expr_ty, expected) || self.suggest_copied_or_cloned(err, expr, expr_ty, expected) <ins> || self.suggest_clone_for_ref(err, expr, expr_ty, expected) </ins> || self.suggest_into(err, expr, expr_ty, expected) || self.suggest_floating_point_literal(err, expr, expected); if !suggested {

Discussion:
we should suggest cloning. Also, we should suggest <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
If we suggest add bound, we don't need dervie , This code will compile:
Change:
} } <del> partial_ord_impl! { f32 f64 } </del> <ins> partial_ord_impl! { f16 f32 f64 f128 } </ins> macro_rules! ord_impl { ($($t:ty)*) => ($(

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. --Playground nightly version: 1.79.0-nightly (2024-03-25 ) This isn't expected since it doesn't seem to hit a label +T-compiler +f-f16andf128 +I-ICE +requires-incomplete-features +S-has-mcve claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label -needs-triage
Minimized:
Looks like it just expects primitives to be . I'm not sure where exactly this assumption comes from, but might as well fix it before the rest of libs support can get merged.
Change:
) -> LocalDefId { let impl_local_def_id = tcx.local_parent(impl_fn_def_id); <del> // FIXME fix the span, we probably want the def_id of the return type of the function let span = tcx.def_span(impl_fn_def_id); </del> <ins> let decl = tcx .hir() .find_by_def_id(impl_fn_def_id) .expect("expected item") .fn_decl() .expect("expected decl"); let span = match decl.output { hir::FnRetTy::DefaultReturn(_) => tcx.def_span(impl_fn_def_id), hir::FnRetTy::Return(ty) => ty.span, }; </ins> let impl_assoc_ty = tcx.at(span).create_def(impl_local_def_id, DefPathData::ImplTraitAssocTy); let local_def_id = impl_assoc_ty.def_id();

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
This needs detailed investigation, and I'd prefer we fully understand why this is resulting in a region error over just adding an check to (or feeding the query).... This probably has to do with the fact that we have a due to the missing region .
Change:
use rustc_middle::ty::TyCtxt; use rustc_span::def_id::DefId; use rustc_span::source_map::SourceMap; <del> use rustc_span::{CharPos, Pos, SourceFile, Span, Symbol}; </del> <ins> use rustc_span::{CharPos, ExpnKind, Pos, SourceFile, Span, Symbol}; </ins> /// A simple error message wrapper for `coverage::Error`s. #[derive(Debug)]

Discussion:
I expect something that looks like the result, for a similar (non-macro) closure: But instead we get results like the following: This issue is demonstrated in the coverage results from the test: I have a new PR in progress to show more examples, and those examples expose the fact that the coverage for is actually being to the macro's source itself. Note that there were 5 macro calls with missing coverage in the corresponding test case, and the coverage report shows 5 . So all are taken into account. Nevertheless, this is a function-like macro, and it should behave like a function call, and show the coverage at the calling site.
I suspect the problem is related to how the expansion is handled for the macro body. When defined without braces, it is (likely) "de-sugared" (adding braces perhaps?) in a way that confuses the macro expansion handling in .
+A-code-coverage fyi:
I looked into this (reviewing debug logs) and the issue it not exactly a macro problem, I think. The closure tests I used all call , and that macro is defined as follows: Note the expansion starts with . That creates a closure that looks like it starts: Since the opening brace comes from the macro, the closure MIR body source starts within the macro. Generating the coverage relative to the source that contains the first character of the function body is generally reasonable, and even in this case it might be hard to argue that it's wrong. But it's probably not right either. The issue is, where should coverage be generated? If the macro is more complex, instrumenting the macro is good. If the caller (which could be another macro, by the way) is more complex, instrumenting the caller source is often better. For example, intuitively we want the coverage results of the two macros below to look similar. Putting the coverage results in the source for the macro loses a lot of coverage span detail! I'm not exactly sure what to do. I'm thinking of treating closures (at least closures that start with a macro) as a special case (at least, when coverage is enabled), and find some way of handling the body span as if it included its own block braces.
Change:
<del> Subproject commit a0ba079b6af0f8c07c33dd8af72a51c997e58967 </del> <ins> Subproject commit 048af409232fc2d7f8fbe5469080dc8bb702c498 </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.