jiebi/CodeConvo huggingface dataset:
Change:
} }; <ins> if let Async::Yes { span, .. } = asyncness { // Feature-gate `async ||` closures. self.sess.gated_spans.gate(sym::async_closure, span); } </ins> Ok(self.mk_expr( lo.to(body.span), ExprKind::Closure(capture_clause, asyncness, movability, decl, body, lo.to(decl_hi)),

Discussion:
This code (): prints out This is pretty unhelpful for beginners - normally this happens when they try to use in a closure, which tells them they need async: But when they do they get an error about async being unstable, which they have no idea how to solve. The fix is to remove the pipe symbols: However, this requires knowledge that async blocks desugar internally into closures, which is not at all clear from the syntax. It would be better for the compiler to suggest it:
Hey, I saw this and it looked like it might be easy so I took a shot with I haven't fixed the tests yet because I wasn't sure if this approach is reasonable or not. You end up with Re-ordering the note and help, or adding a nested span on to put the help would be considerably more involved.
Given the current is equivalent to , it may be preferable to suggest instead of .
the point of this is that the user didn't mean though. If you add then you can no longer await it: For context, the original code was something like , where the user tried to use outside of an async function.
Thanks for clarifying. What suggestion is preferable seems to depend on the expected return type. Perhaps it is preferable to have both notes?
Change:
let prom = cid.promoted.map_or(String::new(), |p| format!("::promoted[{:?}]", p)); trace!("eval_body_using_ecx: pushing stack frame for global: {}{}", name, prom); <del> // Assert all args (if any) are zero-sized types; `eval_body_using_ecx` doesn't // make sense if the body is expecting nontrivial arguments. // (The alternative would be to use `eval_fn_call` with an args slice.) for arg in body.args_iter() { let decl = body.local_decls.get(arg).expect("arg missing from local_decls"); let layout = ecx.layout_of(decl.ty.subst(tcx, cid.instance.substs))?; assert!(layout.is_zst()) } </del> ecx.push_stack_frame( cid.instance, body,

Discussion:
Since , memoization of argumentless functions is restricted to intrinsics, because other functions could perform heap allocations and thus memoization would be incorrect. I doubt we have any argumentless intrinsic that is expensive enough that memoization is worth it, so I propose we remove the leftovers of that infrastructure. Cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I want to work on this but i never contributed to rust-lang before so i need some guidance.
Great! So... step 0 is to write as a comment here, this will make sure the issue is assigned to you and noone else tries to tackle it at the same time. The main change is to remove this function: entirely without a replacement. You'll then have to adjust the call site to act as if the function returned . This may allow some small cleanups at the call site; I expect nothing major to happen there. I do not think there will be further test changes due to this, so, should run through without any failures. If it doesn't, still open a PR and let us know of your findings.
claim
Change:
<ins> // compile-flags: -Zpolymorphize=on // build-pass #![feature(coroutines, coroutine_trait)] use std::ops::Coroutine; use std::pin::Pin; use std::thread; fn main() { let mut foo = || yield; thread::spawn(move || match Pin::new(&mut foo).resume(()) { s => panic!("bad state: {:?}", s), }) .join() .unwrap(); } </ins>

Discussion:
<!-- [31mICE[0m: Rustc '-Zprint-mono-items=eager -Zpolymorphize=on --crate-type=lib -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'assertion failed: coroutine constructed with incorrect number of substitutions'', 'thread 'rustc' panicked at 'assertion failed: coroutine constructed with incorrect number of substitutions'' File: --auto-reduced (treereduce-rust): original: Version information Command: &lt;!-- Include a backtrace in the code block by setting in your environment. E.g. . --&lt;details&lt;summary&lt;strongProgram output&lt;/strong&lt;/summary&lt;p&lt;/p&lt;/details&lt;!-- query stack: [collectandpartitionmonoitems] collectandpartitionmonoitems [exported_symbols] collecting exported symbols for crate --
without debug assertions: &lt;!-- [31mICE[0m: Rustc '-Zprint-mono-items=eager -Zpolymorphize=on --crate-type=lib -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at ', 'thread 'rustc' panicked at ' File: --auto-reduced (treereduce-rust): original: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [collectandpartitionmonoitems] collectandpartitionmonoitems [exported_symbols] collecting exported symbols for crate --
Regression in nightly-2024-02-07 cc
Change:
let nbuf = CString::new(n.as_bytes())?; unsafe { <del> let _guard = ENV_LOCK.write_with_guard(); </del> <ins> let _guard = env_lock(); </ins> cvt(libc::unsetenv(nbuf.as_ptr())).map(drop) } }

Discussion:
For example: i686-gnu, i686-gnu, i686-gnu-nopt, i686-gnu-nopt, i686-gnu, i686-gnu-nopt, i686-gnu, i686-gnu-nopt i686-gnu, i686-gnu, i686-gnu, x8664-gnu-distcheck, i686-gnu-nopt, x8664-gnu-tools, i686-gnu, i686-gnu-nopt, i686-gnu-nopt,
Posted a fix at .
Change:
}; if let Some(path) = path { <del> let arg_index = path </del> <ins> // We've encountered an `AnonConst` in some path, so we need to // figure out which generic parameter it corresponds to and return // the relevant type. let (arg_index, segment) = path </ins> .segments .iter() <del> .filter_map(|seg| seg.args.as_ref()) .map(|generic_args| generic_args.args) .find_map(|args| { </del> <ins> .filter_map(|seg| seg.args.as_ref().map(|args| (args.args, seg))) .find_map(|(args, seg)| { </ins> args.iter() .filter(|arg| arg.is_const()) .enumerate() .filter(|(_, arg)| arg.id() == hir_id) <del> .map(|(index, _)| index) </del> <ins> .map(|(index, _)| (index, seg)) </ins> .next() }) .unwrap_or_else(|| { bug!("no arg matching AnonConst in path"); }); <del> // We've encountered an `AnonConst` in some path, so we need to // figure out which generic parameter it corresponds to and return // the relevant type. let generics = match path.res { Res::Def(DefKind::Ctor(..), def_id) | Res::Def(DefKind::AssocTy, def_id) => { </del> <ins> // Try to use the segment resolution if it is valid, otherwise we // default to the path resolution. let res = segment.res.filter(|&r| r != Res::Err).unwrap_or(path.res); let generics = match res { Res::Def(DefKind::Ctor(..), def_id) => { </ins> tcx.generics_of(tcx.parent(def_id).unwrap()) } Res::Def(_, def_id) => tcx.generics_of(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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
managed to reduce the test case a bit.
Also happens for this code using a function instead of an associated type:
claim
initial example fixed by , associated function fixed by instead
Change:
<ins> //@edition: 2021 //@revisions: infer no_infer #![feature(type_alias_impl_trait)] type Bar = impl std::fmt::Display; async fn test<const N: crate::Bar>() { //[no_infer]~^ ERROR: type annotations needed //~^^ ERROR: `Bar` is forbidden as the type of a const generic parameter #[cfg(infer)] let x: u32 = N; } fn main() {} </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --(hand-reduced) <details<summary<strong(original)</strong</summary<p</p</details<!-- 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. --: Command: option is to avoid error message (there exists another error at the end of the backtrace) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details- ICE location: Might be related to unsolved ICE Issue- (issue fixed by adding test-case), where the issue points to
Change:
/// Borrow the value contained in the reference-counted box #[inline(always)] fn deref<'a>(&'a self) -> &'a T { <del> unsafe { &(*self.ptr).value } </del> <ins> &self.inner().value </ins> } }

Discussion:
To the extent possible, we should try to have all interior mutability be done via , , , or (not yet landed) . If one of these patterns doesn't suffice, it'd be nice to know why!
Nominating for P-Low
Tagging as E-Mentor; I can mentor.
Related to Other types that use interior mutability I can think of off the top of my head: -
I'm definitely interested. Though---having never been a part of a project like this before---not quite sure how the mentoring works just yet :P
This is the part: .
I don't understand the reasoning behind doing this for . Using a marker type makes the intent clearer, and will perform better with optimizations disabled. The type is also supposed to be when is and this will make it always non-. The type should also be .
Marker types do not seem clearer to me than , quite the opposite, but of course thi is a matter of opinion. At first I thought you were on to something regarding , but then I realize that I was mistaken. In particular, we need to settle on precisely what makes something not : must the interior mutability be something interior, something that you own, or just something you can reach? But this question is orthogonal to whether we use markers or . If I understand it, the use of would look something like this: In this case, whether or not is will hinge directly on what we decide about owning vs mutability. At present, the definition is based on reachability. But this definition may be stronger than what we need. I guess it depends on just what is to be used for. So after considering this some more, I still think that using is the right call for is the right call, but the real discussion is what precisely ought to mean, which is most properly discussed I think under . make sense?
I don't think we have a way of enforcing deep immutability. There are many existing types doing internal writes due to I/O. I don't know of a purpose for beyond the high-level semantic meaning (perceived inherited mutability) and type-based alias analysis (which is not deep) so that's the lens I'm viewing it through.
Every type using memory allocation needs to become non- if means deep immutability. The function is mutating memory via the pointer.

So it's not just a problem with I/O.
I don't believe that is an accurate summray of what was proposed, but it is a moot point, as in the latest plan there is no Freeze.
Is there a change to coming? is already using .
I think and I decided that is already using the right primitives and it was just that wasn't.
Though I didn't dig too deeply, maybe can confirm. But it looked to me like it was using the proper abstraction (is there more than one?)
Indeed, is correctly implemented as-is it appears.
I'm running into tests not compiling because something doesn't implement Freeze. Should I wait for to land before I continue?
I actually did not realized that is already on this issue. I'll let you handle this one :D
Assigning P-low as suggested.
Change:
use crate::coercion::{AsCoercionSite, CoerceMany}; use crate::{Diverges, Expectation, FnCtxt, Needs}; <del> use rustc_errors::Diagnostic; use rustc_hir::{self as hir, ExprKind}; </del> <ins> use rustc_errors::{Applicability, Diagnostic}; use rustc_hir::{ self as hir, def::{CtorOf, DefKind, Res}, ExprKind, PatKind, }; </ins> use rustc_hir_pretty::ty_to_string; use rustc_infer::infer::type_variable::{TypeVariableOrigin, TypeVariableOriginKind}; use rustc_infer::traits::Obligation;

Discussion:
The following code () gives the following error: which is weird, since the clause would never be visited even if it was present. The equivalent one-arm match compiles just fine (expectedly). Adding an branch to the is, of course, possible, but unelegant, and really shouldn't be needed, as it can be inferred at compile time.
You can match irrefutably without in this case: though maybe we should give this special diagnostics.
I think this is too niche to deserve a special diagnostics (and I don't think we should substantially work on diagnostics for until let_chains is implemented). is defined by a desugaring: becomes: so what you really wrote is: The block is typed at which does not unify with unless it is also typed at .
I didn't know was a valid syntax. If I did, I probably wouldn't have filed the issue, because of course, in hindsight, that's how you write an infallible . (With that knowledge in mind) I agree that it's only a diagnostics issue and no language change is needed here. And I fully agree that it's a niche low-priority quirk that should maybe be fixed "someday". (I don't know what but even then I'd guess that this one is lower priority than that).
I think the appropriate thing to do here would be to lint on , which would have clarified things.
We already do.
But we do only after typechecking, and we don't if there are any errors before then. Quite a few lints have similar issues related to not happening early enough.
How do you know that the pattern is irrefutable before match checking in HAIR?
You can't, but you can write the lint in such a way that it triggers regardless. We're getting to typechecking, we should be able to detect irrefutability by then. It just can't use the standard linting machinery (like a few other lints already do to avoid being silenced by accident).
Change:
<ins> // Regression test for issue #67690 // Rustc endless loop out-of-memory and consequent SIGKILL in generic new type // check-pass pub type T<P: Send + Send + Send> = P; //~^ WARN bounds on generic parameters are not enforced in type aliases fn main() {} </ins>

Discussion:
Hi, i have made some changes for a crate to support a generic type that implements from , but suddenly the code can't compile because it runs out of memory with 6, 8, 10 GB. This is the code i'm trying to compile: if changed the type for or it then compiles and runs fine. Source: It fails to compile on x86_64-unknown-linux-gnu with , . I'm attaching the Heaptrack files for further analysis.
It seems a problem with utilized in the , unfortunately memory report is strange, the execution time tracked is wrong besides the graph shows up the memory grow. I'm thinking ways to better troubleshoot, but the side effects of the issue is hard.
It'd be helpful to try and simplify the code, ideally to something that doesn't have dependencies (beyond std or so), or at least as few dependencies as possible. As a start putting up a github repository with a and as simple a crate as possible would be helpful for reproducing on our side (i.e., extracting the file you've linked from that crate -- or, if the crate is really necessary, then indicating as such). The heaptrack profile looks pretty useless unfortunately -- rustc on linux is shipped with jemalloc as the allocator which likely makes heaptrack tracking not really work too well.
Thank you, sorry for the late response (working) but i get it working on playground. I'm now trying to minimize them to focus on the issue.
Got it down to 18 lines. Still produces the same error. I have not tested if this goes out-of-memory. But receiving a would signal that. EDIT: After taking some more time, I got rid of Tokio and reduced it to 6 lines: Additionally, I advise to rename this issue to something like to make it very clear and concise.
One liner: . Strangely, this no longer crashes if you remove any of , , , or .

There's nothing special about Send or Sync, this also crashes: Even weirder, this does not crash: (I didn't come up with the one-liner, that was
I stopped rustc (SIGSTOP) and got a backtrace with gdb, it looks like it's trying to generate infinite errors: <details<summarybacktrace</summary</details
It looks like this is a problem with the error reporter itself: it's affected by the length of the name (!!) OOM: No OOM:
I figured out the issue has to do with how the error printer places the annotations, adding a newline after the trait names and before the plus solves the issue.
Probably caused by some code in here:
Change:
<ins> error[E0599]: no method named `foo` found for type `T` in the current scope --> $DIR/issue-65284-suggest-generic-trait-bound.rs:8:7 | LL |     t.foo() |       ^^^ method not found in `T` | = help: items from traits can only be used if the type parameter is bounded by the trait help: the following trait defines an item `foo`, perhaps you need to restrict type parameter `T` with it: | LL | fn do_stuff<T: Foo + Bar>(t : T) { |             ^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0599`. </ins>

Discussion:
Missing a trait bound for the trait that defines below: Results in the following suggestion with an extra colon after the plus.
you can look at and for inspiration on how to deal with this.
I came up with a different solution, but there may be a subtlety I'm missing:
Change:
<ins> // Copyright 2013-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. // ignore-android: FIXME(#10381) // compile-flags:-g1 // Make sure functions have proper names // debugger:info functions // check:static void limited-debuginfo::main(); // check:static void limited-debuginfo::some_function(); // check:static void limited-debuginfo::some_other_function(); // check:static void limited-debuginfo::zzz(); // debugger:rbreak zzz // debugger:run // Make sure there is no information about locals // debugger:finish // debugger:info locals // check:No locals. // debugger:continue #[allow(unused_variable)]; struct Struct { a: i64, b: i32 } fn main() { some_function(101, 202); } fn zzz() {()} fn some_function(a: int, b: int) { let some_variable = Struct { a: 11, b: 22 }; let some_other_variable = 23; zzz(); } fn some_other_function(a: int, b: int) -> bool { true } </ins>  No newline at end of file

Discussion:
Previously we had and where the first was essentially line-numbers only and the second was the full local variables etc. information. was replaced by and the former was removed. A equivalent has lower compilation and runtime overhead.
(Background: said he removed because he didn't realise there was a difference between it and .)
The differences between the old and options can be found as part of . Sorry the diff is large, I assumed that these were the same thing and didn't realize they served different purposes!
Maybehaps -Z debug-info should be renamed to something like -Z line-info? Richard Diamond , Alex Crichton :
('cause I didn't know either) Richard Diamond , Richard Diamond < :
Clang has -gline-tables-only, which seems like reasonable prior art.
GCC has where level is 0-3: means no debug info. is equivalent to . is the same as just . has some more debug info related to C macros. I think that's rather nice and short to type but one has to remember more what's what. I'm not against but I think I'd prefer with being the same as .
I just now saw that there is no more distinction between debug-info and extra-debug-info. Thanks for linking the change set here. Some of these changes need to be reverted/adapted if we want to have a line-tables-only version again (which shouldn't be much of a problem though).
Change:
<ins> // This test ensures that the item information don't take 100% of the width if unnecessary. goto: file://|DOC_PATH|/lib2/struct.Foo.html // We set a fixed size so there is no chance of "random" resize. size: (1100, 800) // We check that ".item-info" is bigger than its content. assert-css: (".item-info", {"width": "807px"}) assert-css: (".item-info .stab", {"width": "343px"}) </ins>

Discussion:
I'm not sure if this change is intentional or not, but I thought it's worth reporting in case it's a bug. ! !
cc Was this change intentional?
I don't think so!
We found it out with and we weren't sure whether it was good or not (from a "look" point of view) and simply decided to wait and see if people liked it or not. So, should we revert it or not? :)
As a random person on the internet, I prefer the old look better. Although I admit that's at least partially due to familiarity with it.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
I would revert it
I'll change the look then.
I think I might like the new look better, but it's a slight preference and I seem to be outvoted. :)
I don't think we should be changing the UI by accident. I'm open to a discussion in changing it, but it shouldn't have changed without a discussion, so we should change it back in the meantime.
Agreed. I'll send a fix in the next two days.
Change:
dependencies = [ "cargo_metadata 0.12.0", "clippy_lints", <del> "compiletest_rs", </del> <ins> "compiletest_rs 0.6.0", </ins> "derive-new", "filetime", "quote",

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. 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!
Change:
ObligationCauseCode::Coercion { source: _, target } => { err.note(&format!("required by cast to type `{}`", self.ty_to_string(target))); } <del> ObligationCauseCode::RepeatVec => { </del> <ins> ObligationCauseCode::RepeatVec(is_const_fn) => { </ins> err.note( "the `Copy` trait is required because the repeated element will be copied", ); <ins> if is_const_fn { err.help( "consider creating a new `const` item and initializing with the result  of the function call to be used in the repeat position, like  `const VAL: Type = const_fn();` and `let x = [VAL; 42];`", ); } if self.tcx.sess.is_nightly_build() && is_const_fn { err.help( "create an inline `const` block, see PR  #2920 <https://github.com/rust-lang/rfcs/pull/2920>  for more information", ); } </ins> } ObligationCauseCode::VariableType(hir_id) => { let parent_node = self.tcx.hir().get_parent_node(hir_id);

Discussion:
The following code: gives the following error: However, is a , so this code can be made to compile by creating a new item: We should suggest this to user when a function is being called in the array initializer. <strikeAssuming that is accepted, we could eventually suggest an inline block.</strikeOn Nightly, we could suggest an inline block. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think this would make a good first issue for someone looking to get started contributing. I'd be happy to mentor anyone who wants to work on this.
claim
Is this still an issue that I can work on?
Yes, assuming that is no longer working on this.
Should I claim it?
It looks like DavidHusicka hasn't had any activity this month, so I think it would be fine for you to take the issue. Feel free to reach out to me if you have any questions about how to get started implementing this.
claim