jiebi/CodeConvo huggingface dataset:
Change:
// ignore-pretty issue #37195 // ignore-cloudabi spawning processes is not supported // ignore-emscripten spawning processes is not supported <del> // normalize-stderr-test ".*n" -> "" </del> <ins> // ignore-msvc issue #62844 </ins> // ignore-sgx no processes <ins> // normalize-stderr-test ".*n" -> "" </ins> // Note that above `-opt-bisect-limit=0` is used to basically disable // optimizations. It creates tons of output on stderr, hence we normalize

Discussion:
With the change in function shouldrunsuccessfully() of commit : RunPass =true, Ui == Some(PassMode::Run), RunPass | Ui =self.effectivepass_mode() == Some(PassMode::Run), The test cases under run-pass directory are tested for building only, the compiled test cases are not running any more. Does it work as design?
Oh. This is bad. Will fix today. cc (on vacation)
Fixed in
Change:
<ins> error[E0599]: no function or associated item named `make_g` found for fn pointer `for<'r> fn(&'r ())` in the current scope --> $DIR/issue-57642-higher-ranked-subtype.rs:34:25 | LL |     let x = <fn (&())>::make_g(); |                         ^^^^^^ function or associated item not found in `for<'r> fn(&'r ())` | = note: the method `make_g` exists but the following trait bounds were not satisfied: `for<'r> fn(&'r ()): X` = help: items from traits can only be used if the trait is implemented and in scope note: `X` defines an item `make_g`, perhaps you need to implement it --> $DIR/issue-57642-higher-ranked-subtype.rs:7:1 | LL | trait X { | ^^^^^^^ error[E0599]: no function or associated item named `make_f` found for fn pointer `for<'r> fn(&'r ())` in the current scope --> $DIR/issue-57642-higher-ranked-subtype.rs:38:25 | LL |     let x = <fn (&())>::make_f(); |                         ^^^^^^ function or associated item not found in `for<'r> fn(&'r ())` | = help: items from traits can only be used if the trait is implemented and in scope note: `Y` defines an item `make_f`, perhaps you need to implement it --> $DIR/issue-57642-higher-ranked-subtype.rs:20:1 | LL | trait Y { | ^^^^^^^ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0599`. </ins>

Discussion:
The following code example () produces the output <details</detailsThe second example also unexpectedly compiles in full NLL mode.
I renamed the title to focus on the part I would most like to investigate, which is why this function works but only with feature-nll: That seems like a blocker to disabling migration mode.
cc
marking P-medium to reflect that this is solely about , not migration mode (). When the latter becomes higher priority, this will likewise be raised up.
Update: this is only an issue now with
blocks
Diagnostics triage: this is not a diagnostics issue
This is now a compiler error with :
Yes, but it should be two compiler errors, one in makef and one on makeg.
Looking at this further - why don't we want to compile? It looks perfectly correct to me.
Running this example with my branch from yields, among some other errors: This error seems correct. If I had to guess the problem with NLL, though, I would guess that this is working because of the rule -- in other words, we are inferring to be implemented for and we are (not incorrectly) deducing that . My branch rejects this because I specifically tried to disallow that. I am not entirely convinced that we should disallow this -- it's just that doesn't have a very natural analog in polonius (though you can make it make sense). In fact, the idea of is kind of useful, or could be, so it may be that we want to accept it. If we want to disallow this example, I think we'll have to extend NLL to have a similarly "graded" notion of . I imagine the way to do this would be to extend the set of elements to include "empty" elements in each universe we create, and then permit these empty elements get to all the "free regions" in the root universe.
On the latest nightly, passing causes and to produce . I think this is now purely a diagnostic issue, rather than a soundness issue.
Change:
<ins> // Copyright 2014, 2017 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. // ignore-emscripten #![feature(command_envs)] use std::process::Command; use std::env; use std::collections::HashMap; #[cfg(all(unix, not(target_os="android")))] pub fn env_cmd() -> Command { Command::new("env") } #[cfg(target_os="android")] pub fn env_cmd() -> Command { let mut cmd = Command::new("/system/bin/sh"); cmd.arg("-c").arg("set"); cmd } #[cfg(windows)] pub fn env_cmd() -> Command { let mut cmd = Command::new("cmd"); cmd.arg("/c").arg("set"); cmd } fn main() { // save original environment let old_env = env::var_os("RUN_TEST_NEW_ENV"); env::set_var("RUN_TEST_NEW_ENV", "123"); // create filtered environment vector let filtered_env : HashMap<String, String> = env::vars().filter(|&(ref k, _)| k == "PATH").collect(); let mut cmd = env_cmd(); cmd.env_clear(); cmd.envs(&filtered_env); // restore original environment match old_env { None => env::remove_var("RUN_TEST_NEW_ENV"), Some(val) => env::set_var("RUN_TEST_NEW_ENV", &val) } let result = cmd.output().unwrap(); let output = String::from_utf8_lossy(&result.stdout); assert!(!output.contains("RUN_TEST_NEW_ENV"), "found RUN_TEST_NEW_ENV inside of:nn{}", output); } </ins>

Discussion:
You can add a vector of command-line arguments to a Command object with , but there's no equivalent for environment variables. I'd like to be able to do things like let filteredenv : Vec<(String, String)= std::env::vars().filter( / criterion /).collect(); let status = Command::new("printenv") .stdin(Stdio::null()) .stdout(Stdio::inherit()) .envclear() .envs(filteredenv) .status(); Right now I have to do instead let mut cmd = Command::new("printenv"); (Stdio::null()); (Stdio::inherit()); cmd.envclear(); for (ref k, ref v) in filtered_env { (k, v); } let status = (); which breaks the builder pattern and extends the scope of the Command object.
This sounds reasonable to me considering . If you want to submit a PR for the feature go ahead.
fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, 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:
I'm confused; hasn't this already been merged?
Yes, but it's currently . The FCP above starting means that the libs team believes the API is ready for stabilization.
Oh, ok. Thanks for the explanation.
The final comment period is now complete.
Change:
<ins> #![deny(single_use_lifetimes)] fn with<R>(f: &fn<'a>(x: &'a i32) -> R) -> R { //~^ ERROR function pointer types may not have generic parameters //~| ERROR lifetime parameter `'a` only used once f(&3) } fn main() {} </ins>

Discussion:
<!-- 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. --: Needs a rustc built with debug assertions, <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Change:
/// For more, see [this pull request](https://github.com/rust-lang/rust/pull/100591). pub const VERSION_": &str = "CURRENT_RUSTC_VERSION"; <ins> pub fn rust_version_symbol() -> Symbol { let version = option_env!("CFG_VERSION").unwrap_or("<current>"); let version = version.split(' ').next().unwrap(); Symbol::intern(&version) } </ins> pub fn is_builtin_attr(attr: &Attribute) -> bool { attr.is_doc_comment() || attr.ident().filter(|ident| is_builtin_attr_name(ident.name)).is_some() }

Discussion:
with rustc master looks like the stabilisation version is borked? :sweat_smile: cc
Hm, it actually says it like this in the code :D
This is correct, but not ideal: https://rustc-dev- cc maybe we want to special case this in the diagnostics
Yeah seems I've missed correcting that lint. For GATs, the stabilization version will be adjusted very soon, in the coming days, as we are close to the release cycle. But this needs to be fixed for future stabilizations as well. Working on a PR. label bug
Error: Label bug can only be set by Rust team members Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
Yeah it warns correctly for lib features so only lang features are affected:
PR filed:
Change:
<ins> use std::error::Error; struct A { } impl A { pub fn new() -> A { A { } } pub fn f<'a>( &'a self, team_name: &'a str, c: &'a mut dyn FnMut(String, String, u64, u64) ) -> Result<(), Box<dyn Error>> { Ok(()) } } fn main() { let A = A::new(); let participant_name = "A"; let c = |a, b, c, d| {}; A.f(participant_name, &mut c); //~ ERROR cannot borrow } </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
This regressed in 1.51 according to the playground
searched nightlies: from nightly-2020-12-15 to nightly-2021-02-01 regressed nightly: nightly-2021-01-30 searched commits: from to regressed commit: Regressed in
Most likely due to , cc
Assigning and removing as in the prioritization working group.
Change:
# If this file is modified, then llvm will be forcibly cleaned and then rebuilt. # The actual contents of this file do not matter, but to trigger a change on the # build bots then the contents should be changed so git updates the mtime. <del> 2015-02-02 </del> <ins> 2015-02-09 </ins>

Discussion:
This happens only after the recent LLVM upgrade. The culprit seems to be half of : Changing the call to copy only 8 bytes instead of 16 (to not touch the portion) removes the infinite loop. cc
One workaround would be to replace with but I'm not sure if that will cause a hit on performance.
I haven't fully analyzed this, but that changing the memcpy size helps is coincidental. That just breaks a memcpy optimization that is required for the problem to show up, because the memcpy sizes now differ. AFAICT for now, this is some problem with aliasing.
So looking through the relevant changes in LLVM, I noticed that the docs for have been refined. And now they clarify that using on the return value is only meant for like functions, i.e. functions that return "new" pointers, not previously accessible to the caller at all. We use it for functions returning unique pointers and functions that return through sret pointers. Seems bad. See Testing a patch now.
FWIW, removing from the no-opt IR for the given testcase does indeed fix the problem.
Nice find!
Fun fact, our suspicion that our usage of lifetime intrinsics was at fault for a bunch of failures might have been totally off. Different usage of lifetimes might just have killed different memcpy optimizations, hiding the real culprit lol I still need to fix them to allow for better optimization though :-/
So here's the minimal LLVM IR I have so far: Removing the attribute on on makes the problem go away, but having there doesn't seem wrong to me.
Pretty sure this is a bug in the memcpyopt pass that doesn't update the scoped alias data.
Change:
<ins> Version 1.72.1 (2023-09-19) =========================== - [Adjust codegen change to improve LLVM codegen](https://github.com/rust-lang/rust/pull/115236) - [rustdoc: Fix self ty params in objects with lifetimes](https://github.com/rust-lang/rust/pull/115276) - [Fix regression in compile times](https://github.com/rust-lang/rust/pull/114948) - Resolve some ICE regressions in the compiler: - [#115215](https://github.com/rust-lang/rust/pull/115215) - [#115559](https://github.com/rust-lang/rust/pull/115559) </ins> Version 1.72.0 (2023-08-24) ==========================

Discussion:
The 1.72.1 release was announced: Actually, this tag exists: However, this version does not seem to exist in GitHub Releases: It seems that this operation is usually done by a , so is there some problem with the automated release procedure?
I suspect we need to copy the release notes to master.
I tried to respond with , is this what you meant?
Why is the release not marked as ? What is the authoritative source of the version?
Good catch! At the moment, 1.71.1 is flagged as presumably since the release notes for 1.71.1 () were merged several hours after the ones for 1.72.1 (). I'm not a T-release member and I'm not super familiar with GitHub releases. is there a simple way to mark 1.72.1 as ?
Should be fixed.
Change:
<del> Subproject commit 8531cc11e196b7ae9072ae7b384a930ff7b00dfb </del> <ins> Subproject commit c27f4167a7706baba1ddbb0a9ab320ec18d097db </ins>

Discussion:
Hello All, Used to build the nightly smoothly, but today it failed with the messages: running it manually: Don't you think adding to solve the problem? Thanks!
cc probably fallout from ?
Thanks a lot. I've read comments carefully and have got that the changes to in nursery that is an additional have already shipped. Unfortunately my rust sandbox stuck to the previous version of after script. Anyway editing manually the above file: solved the issue.
Closing as the problem has been resolved. Thanks!
Change:
<ins> // run-rustfix pub struct Bytes; impl Bytes { pub fn as_slice(&self) -> &[u8] { todo!() } } impl PartialEq<[u8]> for Bytes { fn eq(&self, other: &[u8]) -> bool { self.as_slice() == other } } impl PartialEq<Bytes> for &[u8] { fn eq(&self, other: &Bytes) -> bool { *other == **self } } fn main() { let _ = &[0u8] == [0xAA]; //~ ERROR can't compare `&[u8; 1]` with `[{integer}; 1]` } </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 (while debugging): Where is the corresponding type from the crate (and everything else is my types). It has an associated function , which returns a 16-byte slice containing the UUID. Because the right-hand-side of the comparison is not a byte slice but an array, the two expressions can't be compared and I get error E0277, shown below. Of interest is the help message at the end, which has the correct solution, but proposes a fix with invalid syntax. It should suggest placing before . <!-- 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 could not test on nightly, as I got a different compile error, apparently related to procedural macros: <details<summaryError</summary<p</p</details
For the error, see . Could you try to bump your version? Also, could you maybe provide either the full code or a smaller reproduction of the suggestion (if possible), I can't seem to reproduce the suggestion for your pattern on stable.
Thanks for the notice. I just bumped to and retried on nightly: Unfortunately the exact same misleading help message still appears. I managed to reproduce it here: The import or argument is actually necessary to cause the bug. If you remove both, the help message doesn't appear. Perhaps this is related to the crate, which I noticed uses a type alias called (), unrelated to .
Smaller repro but still requires dependency: Am investigating how to get rid of the dependency.
Repro without dependencies:
Change:
unstable(longer(a, b), move |opts| opts.optmulti(a, b, c, d)) } } <ins> static EDITION_STRING: LazyLock<String> = LazyLock::new(|| { format!( "Specify which edition of the compiler to use when compiling code.  The default is {DEFAULT_EDITION} and the latest stable edition is {LATEST_STABLE_EDITION}." ) }); </ins> /// Returns the "short" subset of the rustc command line options, /// including metadata for each option, such as whether the option is /// part of the stable long-term interface for rustc.

Discussion:
rustc --edition: rustc --edition=help: --editionhelprustc --help The default is not mentioned anywhere. I assume it is 2015? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The default is indeed 2015. It should probably not only mention the default (2015) but also the latest stable edition (2021).
Mentoring instructions: modify to include and somewhere.
claim
What is the best way to insert the values for and into the string? only takes 's and I don't see an easy way to create one while inlining those variables. Neither nor works - former only accepts literals rather than the static variable, and the latter would create a &str, but then drop a temporary variable. I don't believe it would be a good idea to simply write the value of these variables into the string, so I'm wondering what other options I have. However, if that's the way forward, I can do so.
Where does that requirement come from? Seems fine to loosen it.
ah I see, the string ends up stored in RustcOptGroup. Honestly, given that this is only used once and the string is tiny, using seems fine.
Change:
<del> Subproject commit af8f9eb61a2ad4ee1f2d3f46d157b93a47c6a4bf </del> <ins> Subproject commit 5399a24c66cb6164cf32280e7d300488c90d5765 </ins>

Discussion:
Hello, regressed on the following tests on MIPS: I have bisected this to in the Rust repo and to in the LLVM repo. (On Debian 12) install a MIPS toolchain: a file with the following contents (which is a simplified snippet of the failing doctests mentioned above): it like this: like this: The program completes successfully. The program fails like this: With pointing to the test also fails, but when pointing to the parent commit () the test passes. So we can conclude that this regression was introduced by , which originates from Edit: See for more discussion around this. label +O-MIPS +A-atomic +T-compiler +C-bug
label +A-LLVM
I can confirm that the regression has been fixed :+1: The first nightly with the fix is nightly-2024-04-19.
Change:
NoopMethodCallDiag { method: call.ident.name, receiver_ty, label: span }, ); } else { <del> cx.emit_spanned_lint( SUSPICIOUS_DOUBLE_REF_OP, span, SuspiciousDoubleRefDiag { call: call.ident.name, ty: expr_ty, op }, ) </del> <ins> match name { // If `type_of(x) == T` and `x.borrow()` is used to get `&T`, // then that should be allowed sym::noop_method_borrow => return, sym::noop_method_clone => cx.emit_spanned_lint( SUSPICIOUS_DOUBLE_REF_OP, span, SuspiciousDoubleRefCloneDiag { ty: expr_ty }, ), sym::noop_method_deref => cx.emit_spanned_lint( SUSPICIOUS_DOUBLE_REF_OP, span, SuspiciousDoubleRefDerefDiag { ty: expr_ty }, ), _ => return, } </ins> } } }

Discussion:
If I have a type , and a trait that is implemented for both and , is a valid way to get a reference from an object of type . But since beta 1.71, this emits a warning. I have no idea what the warning is trying to convey, what "double reference" is referring to, or what "the inner type" is. No response
cc
Ah. then I think this lint shouldn't apply to since can mean specifically to borrow . But I think this should still apply to and
(sorry)
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
<del> Subproject commit 388750b081c0893c275044d37203f97709e058ba </del> <ins> Subproject commit e3f3af69dce71cd37a785bccb7e58449197d940c </ins>

Discussion:
Results in a crash (after a perfectly reasonable error message): This was tested with rustc 0.1. Building from HEAD on nyus now to try to get a more helpful backtrace and to verify that it hasn't since been fixed.
Here's a more helpful backtrace. Repros at .
Looks exactly like to me.

On the pull request for (), had a good suggestion for what I think would make a good additional function: "a version of frombytes which doesn't fail on invalid input but rather offers some sort of error recovery options. Like maybe it can return the partly converted string with an index to the invalid position. Or perhaps, a callback function to handle the error, etc." At a glance the easy way to do this would be with a callback to, e.g., drop, replace, or coerce offending sequences into UTF-8 or else return a ... But is this a recipe for complex callbacks? Perhaps providing sensible callback functions like , , , and so on would make this simple enough to use. Maybe those should just be simple functions for whole byte vector conversion, anyways. What do you think?
I don't have a strong opinion about it, but I guess I would prefer to wait until somebody actually needs something like this.
Not RFC-level proposal. Just a library wishlist item. Might accept a patch; but it seems a bit overwrought. Anyone need such a thing yet?
I think this is subsumed in ; we might well adopt a dynamic-handler mechanism while working through that bug. This would be a special case.
Change:
fn should_warn_about_field(&mut self, field: &hir::StructField) -> bool { let field_type = self.tcx.type_of(self.tcx.hir.local_def_id(field.id)); <del> let is_marker_field = match field_type.ty_to_def_id() { Some(def_id) => self.tcx.lang_items().items().iter().any(|item| *item == Some(def_id)), _ => false }; </del> !field.is_positional() && !self.symbol_is_live(field.id, None) <del> && !is_marker_field </del> <ins> && !field_type.is_phantom_data() </ins> && !has_allow_dead_code_or_lang_attr(self.tcx, field.id, &field.attrs) }

Discussion:
I don't know if this is really problem, but e.g. the reimplements this function (and yields a bunch of other s, too. This needs some looking at Mostly leaving this here so I don't forget
is probably a hack for cache keying, and should ideally be removed?
Change:
<ins> #![feature(auto_traits)] auto trait Foo { fn g(&self); //~ ERROR auto traits cannot have associated items } trait Bar { fn f(&self) { self.g(); //~ ERROR the method `g` exists for reference `&Self`, but its trait bounds were not satisfied } } fn main() {} </ins>

Discussion:
Found with a error]: auto traits cannot have associated items thread 'rustc' panicked at 'internal error: entered unreachable code', <details<summaryFull output including backtrace</summary</detailsRegression in nightly-2022-11-05, somewhere in rollup , likely (CC 2022-12-14 label +F-autotraits <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Fixed the ICE, the error message now is: I think the second error message should not come out, considering the is an auto trait.
Change:
fn print_associated_type( &mut self, ident: ast::Ident, <ins> generics: &hir::Generics<'_>, </ins> bounds: Option<hir::GenericBounds<'_>>, ty: Option<&hir::Ty<'_>>, ) { self.word_space("type"); self.print_ident(ident); <ins> self.print_generic_params(&generics.params); </ins> if let Some(bounds) = bounds { self.print_bounds(":", bounds); } <ins> self.print_where_clause(&generics.where_clause); </ins> if let Some(ty) = ty { self.s.space(); self.word_space("=");

Discussion:
The following code: is pretty printed as This presumably also affects procedural macros.
Are there tests intended for pretty printing? I got the impression that folder only tests specific features and bugs, not the form