jiebi/CodeConvo huggingface dataset:
Change:
} unsafe { <del> let _guard = ENV_LOCK.read(); </del> <ins> let _guard = env_read_lock(); </ins> let mut result = Vec::new(); if !environ.is_null() { while !(*environ).is_null() {

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. --Investigating library sources for , I have found that the copying of the env variable value is performed not under the lock: So there is a potential data race with setenv. I tried this code with miri And got Have tried to move under the lock, but still got error with miri. I was not able to trigger the real crash with it yet. <!-- 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. --: Bug was introduced by this commit: (PR: ) Before that changes, read was under the lock. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
I think this happened because implicit scoping of the lock guard, which makes it easy to shorten its lifetime the rwlock isn't coupled to the resource via a lifetime, so it's easy for the extracted pointer to be used longer than the lock is valid The first one could be made more visible by linting to add an explicit to make its lifetime more explicit in the code when a critical section ends. Especially when guard is otherwise unused which indicates that the lock doesn't directly own the resource it protects. The second one could be solved by using a lifetime-tagged raw pointer and coupling that lifetime to the guard.
Side note: even when fixed this assumes all other read/writes acquire Rust's lock and is potentially unsound if they do not. This has often been discussed with a view to making unsafe. Arguably if that happens then the lock would be redundant, although it could also be argued it's still useful to help avoid some footguns even if you can't make it totally safe.
That's
That PR did not add a test, did it? Would be good to add one in (those are run in Miri regularly). We probably don't want iterations though, that will take forever. 100 should easily be enough.
Something like ?
Yeah something like that.

For Miri it's not really necessary to do this "sum of the lengths" computation, not sure why that would be particularly susceptible to a data race. The one existing concurrency test uses , so probably it would make sense to use the same attribute here.
Change:
<del> Subproject commit e3be3f64ecac101d14ceda759ba078ad0aaf3747 </del> <ins> Subproject commit 670e5f673acb736acbfce65e0ffe2c8cd115b93f </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. --The  crate compiles on nightlies before (the LLVM 15 upgrade), but now it fails with this: The error happens both when natively compiling on Arch Linux, and when cross compiling from macOS as shown here. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: searched nightlies: from nightly-2022-08-12 to nightly-2022-08-14 [originally searched from 2022-07-01; reduced range shown here because I restarted bisect due to a crash half way through] regressed nightly: nightly-2022-08-13 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
WG-prioritization assigning priority (). label -I-prioritize +P-high T-compiler
Upstream issue: Not sure why this starts with LLVM 15, as the issue itself is not new.
Change:
.anchor { display: none; position: absolute; <del> left: -7px; </del> <ins> left: 0; background: none !important; </ins> } .anchor.field { left: -5px; } .small-section-header > .anchor { <del> left: -28px; padding-right: 10px; /* avoid gap that causes hover to disappear */ </del> <ins> left: -15px; padding-right: 8px; </ins> } <del> .anchor:before { content: '200200a72002'; </del> <ins> h2.small-section-header > .anchor { padding-right: 6px; } .anchor::before { content: '§'; </ins> } .docblock a:not(.srclink):not(.test-arrow):hover,

Discussion:
This is a regression from 1.53.0 to 1.54.0 (released today). It's likely that the display of other parts of the docs has regressed in a similar way as well (e.g., fields), but I haven't checked those. More broadly, the way the variant looks when hovered has changed as well. I am unsure if that part of the change was intentional; to me it seems like a regression. ! !
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Fixing it.
It's actually already fixed in and . Should we close it then?
It doesn't look fixed to me in the links you posted. When I hover over the variant, the section icon still covers the word , and the styling of the highlight is still different from 1.53.0. EDIT: Ah, I realize what caused the confusion: you actually have to click on , and then hover to see the problem. Or, you have to add the anchor to the URL before visiting the page.
That's interesting: ! I love when dark magic is involved haha. Well, I'm gonna try to see how to reproduce it.
The bug is present in all themes, but it looks a bit different in Ayu: ! As you can see, it looks like the section icon's background is overlapping with the text .
Ayu seems to have also had a highlighting regression from stable to beta, perhaps separate from the one described in this issue? ! !
For for the background, it's definitely on purpose.
Change:
pub fn yield_now() {} pub fn set_name(_name: &CStr) {} <ins> pub fn get_name() -> Option<CString> { None } </ins> pub fn sleep(dur: Duration) { use crate::arch::wasm32;

Discussion:
Compilation of any code using the atomics feature flag for the wasm target fails when building the std library due to the following error: I tried this code: With these flags enabled I expected to see this happen: Compilation succesful Instead, this happened: : <details<summaryBacktrace</summary<pBacktrace doesn't seem to add useful information. </p</details
While playing around locally, adding this, in fixes the compiler error, not sure if there are undesired side effects.
That looks great! Would you be willing to submit a PR?
Definitely!
Change:
let origin = Point { x: 0, y: 0 }; match origin { <del> Point { x: x, .. } => println!("x is {}", x), </del> <ins> Point { x, .. } => println!("x is {}", x), </ins> } ```

Discussion:
The page doesn't explain that it's possible to match compound data in this way: Currently only this form is covered: The latter form results in compiler warnings (). I'm not sure whether it should be avoided for that reason.
fixed this
Change:
} #[test] <ins> fn test_ptr_addition() { use vec::raw::*; unsafe { let xs = ~[5, ..16]; let mut ptr = to_ptr(xs); let end = ptr + 16; while ptr < end { assert_eq!(*ptr, 5); ptr = ptr + 1u; } let mut xs_mut = xs.clone(); let mut m_ptr = to_mut_ptr(xs_mut); let m_end = m_ptr + 16i16; while m_ptr < m_end { *m_ptr += 5; m_ptr = m_ptr + 1u8; } assert_eq!(xs_mut, ~[10, ..16]); } } #[test] fn test_ptr_subtraction() { use vec::raw::*; unsafe { let xs = ~[0,1,2,3,4,5,6,7,8,9]; let mut idx = 9i8; let ptr = to_ptr(xs); while idx >= 0i8 { assert_eq!(*(ptr + idx), idx as int); idx = idx - 1i8; } let mut xs_mut = xs.clone(); let mut m_start = to_mut_ptr(xs_mut); let mut m_ptr = m_start + 9u32; while m_ptr >= m_start { *m_ptr += *m_ptr; m_ptr = m_ptr - 1i8; } assert_eq!(xs_mut, ~[0,2,4,6,8,10,12,14,16,18]); } } #[test] </ins> fn test_ptr_array_each_with_len() { unsafe { let one = ~"oneOne";

Discussion:
This seems like an obvious use case for operator overloading. Probably export them from core by default.
What operators did you have in mind? Things like for ?
yes, and
Not going to work right now, because operators can't be unsafe. Not sure how to change that either. Going to close for now.
At least for , the operator could be "safe" with an unsafe block inside of it. You aren't going to have problems if you do pointer arithmetic until you dereference it, which would be unsafe anyway. In other words, if is safe (which is is), then it seems like pointer arithmetic is also safe.
Yeah, that's true. We consider arithmetic safe, but indexing and dereferencing unsafe. Just having would be convenient.
I'm going to try on work on this. I'll add overloaded and . I'll use as dbaupp suggested on IRC so that it will work with any primitive integer type.
Looks like and for unsafe pointers, can this be closed?
Change:
db.help("to document an item produced by a macro,  the macro must produce the documentation as part of its expansion"); } <ins> BuiltinLintDiagnostics::PatternsInFnsWithoutBody(span, ident) => { db.span_suggestion(span, "remove `mut` from the parameter", ident.to_string(), Applicability::MachineApplicable); } </ins> } // Rewrap `db`, and pass control to the user. decorate(LintDiagnosticBuilder::new(db));

Discussion:
Taken from We should suggest to use an identifier. When possible take that identifier from the pattern, otherwise should work just as well. CC
I'll try it!
Change:
<ins> // edition: 2021 async fn dont_suggest() -> i32 { if false { return Ok(6); //~^ ERROR mismatched types } 5 } async fn do_suggest() -> i32 { if false { let s = Ok(6); return s; //~^ ERROR mismatched types } 5 } fn main() {} </ins>

Discussion:
snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details
Regression in probably ? cc
This is due to . The function name in the stack trace matches the title of that PR. cc
oops race condition, clicked the button before I saw you self-assigned -- I already found a fix
yeah, go ahead please.
Change:
err.span_label(span, format!("cannot {act}")); } if suggest { <del> err.span_suggestion_verbose( local_decl.source_info.span.shrink_to_lo(), "consider changing this to be mutable", "mut ", Applicability::MachineApplicable, ); </del> <ins> self.construct_mut_suggestion_for_local_binding_patterns(&mut err, local); </ins> let tcx = self.infcx.tcx; if let ty::Closure(id, _) = *the_place_err.ty(self.body, tcx).ty.kind() { self.show_mutating_upvar(tcx, id.expect_local(), the_place_err, &mut err);

Discussion:
No response Applying the suggestion gives No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It should suggest instead. Looks odd but it's correct. label -needs-triage A-suggestion-diagnostics D-invalid-suggestion
Hi, I'm interested in this issue and want to try to fix it. claim
Change:
<ins> // Regression test for #47429: short backtraces were not terminating correctly // compile-flags: -O // run-fail // check-run-results // exec-env:RUST_BACKTRACE=1 // ignore-msvc see #62897 and `backtrace-debuginfo.rs` test // ignore-android FIXME #17520 // ignore-cloudabi spawning processes is not supported // ignore-openbsd no support for libbacktrace without filename // ignore-wasm no panic or subprocess support // ignore-emscripten no panic or subprocess support // ignore-sgx no subprocess support fn main() { panic!() } </ins>

Discussion:
v.s. is less verbose, but I remember it also filtering out some stack frames in some previous compiler versions. (Only frame # 6 is really useful to me here.) Indeed, contains some code that looks for a symbol on the stack to find out what to filter. It looks like some functionality has regressed. Stepping through the program in gdb it looks like the function is called, but despite there’s apparently no stack frame (anymore?) for it. CC and for , , and .
contains a fix for this
Now being worked on in instead afaict?
It is.
This issue hasn't been active in almost two years, and so have the issues linked here. Is there any intention of resuming work on this? It's mostly a small papercut because currently when crashing, programs suggest: run with environment variable to display a backtrace. and after setting that, also claim that: Some details are omitted, run with for a verbose backtrace. even though no details were omitted at all (which is the issue of course)
A simple fix would be to just look for "std::rt::lang_start::{{closure}}" instead until the real solution to the disappearing function is found..
This single fix is likely to have the biggest positive effect on my use of Rust since async/await. Thank you so much!
Awesome! I'm happy to see this finally fixed :D Thanks to everyone who had a part in this fix :)
Change:
<ins> fn main() { let _ = fix(|_: &dyn Fn()| {}); } fn fix<F: Fn(G), G: Fn()>(f: F) -> impl Fn() { move || f(fix(&f)) //~^ ERROR mismatched types } </ins>

Discussion:
Messing around with a Haskell-like implementation of , I encountered two presumably similar ICEs (would think they're the same, but the error messages are obviously different). The other one is . I'm pretty sure this should be an error, based on the reasoning that returns an opaque type, so, while the output of might be , it also might not (and in this case, isn't), and since only accepts s, should be an error. Note that this implementation throws the ICE even without the main method, but I'm leaving it there for contrast to the other ICE. : Same ICE on nightly: <details<summary<strongBacktrace</strong</summary<p</p</details
This regressed in
I was able to "weaponize" this into a transmute, lol: So the issue here is that, at least in the case of RPITs, we are not checking for opaque type mismatches in closures correctly. The closure, in this example, is able to incorrectly constrain even though in the enclosing function, we define . During mir borrowck, we never check these two together, so we never report a type mismatch. I think I have a fix, though.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Change:
AssocTypeItem(bounds.clean(cx), default.clean(cx)) } }; <del> Item::from_def_id_and_parts(local_did, Some(self.ident.name), inner, cx) </del> <ins> let what_rustc_thinks = Item::from_def_id_and_parts(local_did, Some(self.ident.name), inner, cx); // Trait items always inherit the trait's visibility -- we don't want to show `pub`. Item { visibility: Inherited, ..what_rustc_thinks } </ins> }) } }

Discussion:
The trait on 1.49.0 (current stable) doesn't contain modifier in function declaration of that trait. ! However, on and nightly, there is modifier. ! This is wrong because you cannot use modifier for each method/function in Trait definition. Why is this important? People copy the method/function declaration in the documentation to their code and see the compiler error: . : cc I think this might relate to some changes in visibility around macros ? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Yes, this needs the same fix as (in particular should work).
Self-assigning because this is a beta regression.
Note that this also occurs for the impl's docs.
Removed since this was fixed.
, trait methods still rendered as : ! Is there something wrong to Rust release or the bug still exists ?
Hmm, maybe it was only fixed for items in the local crate. do you have time to come up with an MCVE? I expect it's related to cross-crate re-exports.
Your guess sounds right. With core link (), things are normal.
I don't think I'll have time to fix this second part soon, so unassigning myself.
Assigning and removing as in the prioritization working group.
Removing E-mentor + E-easy labels since we don't have guides for cross-crate linking: label -E-easy -E-mentor
I think is the cross-crate case.
Fix backported to 1.50.0 and landed in 1.51.0, closing this.
Please reopen. The issue is not entirely fixed for cross-crate trait reexport case.
The cross-crate issue is now on stable. label: +regression-from-stable-to-stable -regression-from-stable-to-beta
claim
Change:
/// # Examples /// /// ``` <del> /// #![feature(copied)] /// </del> /// let x = 12; /// let opt_x = Some(&x); /// assert_eq!(opt_x, Some(&12)); /// let copied = opt_x.copied(); /// assert_eq!(copied, Some(12)); /// ``` <del> #[unstable(feature = "copied", issue = "57126")] </del> <ins> #[stable(feature = "copied", since = "1.35.0")] </ins> pub fn copied(self) -> Option<T> { self.map(|&t| t) }

Discussion:
This is a tracking issue for . Added in . Feature gate: . Related feature: in .
Did you mean in the first sentence?
Fixed.
The lint in Clippy should be updated to suggest this instead when the type is copiable.
So we a newtype because that's what we usually do. However, in this case, we could simply reuse and implement copied as: Are there notable reasons not to do this that I'm missing? Doing so would substantially decrease the cost of this feature for the standard library.
type wouldn't have the guarantees that does, as it calls the method, which can have side-effects (it shouldn't, but it's not something we can depend on). Although I suppose we currently DO expose specialization in structure when implementation is incompatible with implementation. This seems like a bug, so I will fix that in a separate PR.
See .
The comment about the type belongs in Since I see no objection to : 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] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), 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.
Am I correct that this now awaits for a stabilization PR?
Yes.
Stabilization PR is up:
Change:
///         .expect("ls command failed to start"); /// ``` #[stable(feature = "process", since = "1.0.0")] <del> pub fn args<S: AsRef<OsStr>>(&mut self, args: &[S]) -> &mut Command { </del> <ins> pub fn args<I, S>(&mut self, args: I) -> &mut Command where I: IntoIterator<Item=S>, S: AsRef<OsStr> { </ins> for arg in args { self.arg(arg.as_ref()); }

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:
data_layout: "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64".to_string(), arch: "arm".to_string(), target_os: "linux".to_string(), <del> target_env: "gnueabi".to_string(), </del> <ins> target_env: "gnu".to_string(), </ins> target_vendor: "unknown".to_string(), options: TargetOptions {

Discussion:
Right now is predominately used to conditionally compile code for differing C libraries like msvc, glibc, musl, etc. On ARM, however, there are two glibc annotations, "gnueabi" and "gneuabihf". This then also extends to musl with "musleabi" and "musleabihf". This seems unnecessarily complicated to say "conditionally compile this code when using musl", that is it should only require one annotation, not three. We could possibly change as I doubt anyone's using "gnueabihf" as a matcher, or we could add a new .
cc
The presence of absence of hard float should be denoted inside its own feature instead ( or something). I believe we already have (or plans for) a few such switches already.
Could we use for choosing between static vs dynamic or release vs debug for the msvc CRT?
The toosl team discussed this issue at triage and the decision was to name as either gnu or musl instead of also gnueabi/musleabi. I'll send a PR shortly
There should probably also be a good way to distinguish between statically linked musl and dynamically linked musl targets.
Change:
static s3: xcrate_unit_struct::Unit = xcrate_unit_struct::Argument(xcrate_unit_struct::Struct); static s4: xcrate_unit_struct::Unit = xcrate_unit_struct::Argument(s1); <ins> static s5: xcrate_unit_struct::TupleStruct = xcrate_unit_struct::TupleStruct(20, "foo"); </ins> fn f1(_: xcrate_unit_struct::Struct) {} fn f2(_: xcrate_unit_struct::Unit) {} <ins> fn f3(_: xcrate_unit_struct::TupleStruct) {} </ins> pub fn main() { f1(xcrate_unit_struct::Struct); f2(xcrate_unit_struct::UnitVariant); f2(xcrate_unit_struct::Argument(xcrate_unit_struct::Struct)); <ins> f3(xcrate_unit_struct::TupleStruct(10, "bar")); </ins> f1(s1); f2(s2); f2(s3); f2(s4); <ins> f3(s5); </ins> }

Discussion:
compiles fine (other than the dead code warning for ), but is not:
I hit this as well, I would love a fix :+1:
Change:
crate maybe_sysroot: Option<PathBuf>, /// Lint information passed over the command-line. crate lint_opts: Vec<(String, Level)>, <del> /// Whether to ask rustc to describe the lints it knows. Practically speaking, this will not be /// used, since we abort if we have no input file, but it's included for completeness. </del> <ins> /// Whether to ask rustc to describe the lints it knows. </ins> crate describe_lints: bool, /// What level to cap lints at. crate lint_cap: Option<Level>,

Discussion:
I tried this code: I expected to see this happen: Rustdoc prints a list of all lints, the same way rustc does. Instead, this happened: Rustdoc ignored the flag. <!-- 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. --: rustdoc 1.53.0-nightly ( 2021-04-03) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
option is parsed into , but is then ignored: It should be pretty straightforward to instead call when this flag is set. claim
Make sure you call init_lints first, or it will be missing rustdoc's own lints.
Re adding a test for this... is there any way to have check only for whether some substring appears within stderr? Else every time a lint is /removed, or its level modified, the test will need updating—which seems far too brittle to me?
I mean, personally that seems ok to me as long as you can update it with . But if you think it's a hassle you could use .