jiebi/CodeConvo huggingface dataset:
Change:
self.note_obligation_cause(&mut err, &obligation); self.point_at_returns_when_relevant(&mut err, &obligation); err.emit(); } }

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. --Given the following code: <!-- Please provide a link to --The current output is: We shouldn't show here. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
without
another one 
What ideal output would you suggest? Should we remove the suggestion line like:
Ideally we should be checking that the return type . If it's not suggestable, don't mention it.
claim
I actually believe that neither the E0029 nor the E0277 should have been emitted. I would check explicitly for and change the error to be (that way the error isn't printed out, but rustc will ICE if no other error is emitted, which should have happened).
The PR will prevent E0029 and E0277 from printing out after checking the type references.
Change:
// Types with identity (print the module path). ty::Adt(ty::AdtDef(Interned(&ty::AdtDefData { did: def_id, .. }, _)), substs) | ty::FnDef(def_id, substs) <del> | ty::Alias(_, ty::AliasTy { def_id, substs, .. }) </del> <ins> | ty::Alias(ty::Projection | ty::Opaque, ty::AliasTy { def_id, substs, .. }) </ins> | ty::Closure(def_id, substs) | ty::Generator(def_id, substs, _) => self.print_def_path(def_id, substs), ty::Foreign(def_id) => self.print_def_path(def_id, &[]), <ins> ty::Alias(ty::Inherent, _) => bug!("type_name: unexpected inherent projection"), </ins> ty::GeneratorWitness(_) => bug!("type_name: unexpected `GeneratorWitness`"), ty::GeneratorWitnessMIR(..) => bug!("type_name: unexpected `GeneratorWitnessMIR`"), }

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 --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
regression in cc
claim
another one `

<!-- 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 --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regression in cc
Thanks :) claim
Change:
<ins> warning: the feature `dyn_star` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/return.rs:3:12 | LL | #![feature(dyn_star)] |            ^^^^^^^^ | = note: see issue #91611 <https://github.com/rust-lang/rust/issues/91611> for more information = note: `#[warn(incomplete_features)]` on by default warning: 1 warning emitted </ins>

Discussion:
() This happens whether or not the returned type implements the trait in question. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details modify labels +F-dyn_star
Change:
pointing_at_return_type = self.suggest_missing_return_type(err, &fn_decl, expected, found, can_suggest); let fn_id = self.tcx.hir().get_return_block(blk_id).unwrap(); <del> self.suggest_missing_return_expr(err, expr, &fn_decl, expected, found, fn_id); </del> <ins> self.suggest_missing_break_or_return_expr( err, expr, &fn_decl, expected, found, blk_id, fn_id, ); </ins> } pointing_at_return_type }

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. --Given the following code: The current output is: Ideally the output should look like: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --It may not be immediately clear to a user why implicit-return/break style works for expressions, but not for . Adding a hint to explicitly break with would be helpful. <!-- If dramatically different output is caused by small changes, consider also adding them 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-suggestion-diagnostics
claim
Change:
), )) { <ins> let mut span = expr.span; while expr.span.eq_ctxt(span) && let Some(parent_callsite) = span.parent_callsite() { span = parent_callsite; } </ins> let sugg = if expr.precedence().order() >= PREC_POSTFIX { <del> vec![(expr.span.shrink_to_hi(), ".into()".to_owned())] </del> <ins> vec![(span.shrink_to_hi(), ".into()".to_owned())] </ins> } else { <del> vec![(expr.span.shrink_to_lo(), "(".to_owned()), (expr.span.shrink_to_hi(), ").into()".to_owned())] </del> <ins> vec![(span.shrink_to_lo(), "(".to_owned()), (span.shrink_to_hi(), ").into()".to_owned())] </ins> }; diag.multipart_suggestion( format!("call `Into::into` on this expression to convert `{expr_ty}` into `{expected_ty}`"),

Discussion:
The suggestion converts the code to: which is invalid. It should suggest: The suggestion works correctly for non-macro string values. This suggestion was introduced in . No response
It cannot be reproduced on .
I'm able to reproduce it locally. It seems to be suggesting a change in : (note the path) I assume that this is due to macro expansion. It might not be working on the playground because the playground doesn't have the component installed but that's a total guess.
The presence of only affects the human-readable rendering. The important part to me is the JSON output which has even without rust-src. Ideally it would be something closer to what it looks like with :
It seems to affect all macro expansions ():
Is the solution to just disable this suggestion for macro-expanded code? As an aside, perhaps the playground should get , especially because of its prevalence in sharing code which might need the additional context.
I think it's possible to achieve the desired output found in the description, although I'm not sure how exactly. Typically, you would use on the span to peel away the layers of macro invocations, though for that you would need to provide a parent to mark the end of the chain. doesn't need such a stopper but here its use would be incorrect if the macro call itself (e.g. ) was inside of a macro expansion. Since we don't have a parent (afaiaa), earlier I briefly tried to create a parent for via I think but that didn't work. Maybe could work, not sure. This approach is a catch-22 I believe.
Yeah, would that be the desired solution though? Can this be generalized to all the other type mismatch suggestions?
That's a good question. It was mostly an experiment to see if this specific issue can be solved with .
Change:
] [[package]] <ins> name = "object" version = "0.36.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "576dfe1fc8f9df304abb159d767a29d0476f7750fbf8aa7ad07816004a207434" dependencies = [ "compiler_builtins", "memchr", "rustc-std-workspace-alloc", "rustc-std-workspace-core", ] [[package]] </ins> name = "odht" version = "0.3.1" source = "registry+https://github.com/rust-lang/crates.io-index"

Discussion:
The relevant commit seem to be located at <details<summaryError</summary<p</p</details
Ah. cc
Ah, this was fixed in
Okay, it seems like this is just a misunderstanding. keywords cannot be searched ...
This won't be actually fixed in std until lands.
Change:
target_os = "fuchsia", target_os = "redox", target_os = "hurd", <del> target_os = "freebsd", </del> target_os = "netbsd", target_os = "dragonfly" ))]

Discussion:
Apologies if this isn't the right place, it isn't obvious to me if this originates in rustc or should be upstreamed to FreeBSD. My limited understand of the warnings however suggests it could be a misuse of s on our end. The following comment from seems relevant: I can't reproduce this on latest stable, just latest nightly so far.
Bisected with : regressed nightly: nightly-2024-01-24 searched commit range: regressed commit: I think it is probably ( which is awkward because all that change did was enable thread-local support on FreeBSD.
Can reproduce too, however no problem on netbsd (reading ). It might be valuable to get an insight of what might happen in the system side of things.
Rustc doesn't dlclose any of the libraries it dlopen's. And if you don't use proc macros or a codegen backend other than the default LLVM, it doesn't dlopen any library.
ktrace for the curious: <details<summarykdump</summary</details
Change:
// Temporarily count the directive as determined so that the resolution fails // (as opposed to being indeterminate) when it can only be defined by the directive. if !determined { <del> module_.decrement_outstanding_references_for(target, ns, directive.is_public) </del> <ins> module_.resolutions.borrow_mut().get_mut(&(target, ns)).unwrap() .decrement_outstanding_references(directive.is_public); </ins> } let result = self.resolver.resolve_name_in_module(target_module, source, ns, false, true);

Discussion:
Unfortunately, I can't reproduce this at a smaller scale. This issue occurs with as of commit . Rust version is Currently the tests (run from the directory with ) pass. However, applying the following patch: causes the following compiler error: which is claiming that an import conflicts with itself. I have pushed up the branch with that change applied for easy reproduction. Again, I'm sorry that I cannot provide a report on a smaller scale, but this appears to be some edge case blowing up. I have no clue why adding a module with a few imports and nothing else would be causing this issue.
Bisecting to find the nightly which caused this
I can confirm that this issue does not occur on . Unfortunately, there was a bug that prevented us from compiling on that wasn't fixed until , so I cannot provide anything more specific than that.
cc
Thanks for the report! This bug was introduced in . I diagnosed the issue and will fix it ASAP.
Change:
add_configuration(&mut cfg, &mut sess, &*codegen_backend); let mut check_cfg = config::to_crate_check_config(check_cfg); <del> check_cfg.fill_well_known(); </del> <ins> check_cfg.fill_well_known(&sess.target); </ins> sess.parse_sess.config = cfg; sess.parse_sess.check_config = check_cfg;

Discussion:
doesn't seem to know that custom targets can extend the set of values. The following creates a custom spec with a . No warning Got the warning: cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Change:
}); if let Some(lt) = lifetime.cloned() { let lt_def_id = cx.tcx.hir().local_def_id(param.hir_id); <del> let cleaned = if !lt.is_elided() { lt.clean(cx) } else { self::types::Lifetime::elided() }; </del> <ins> let cleaned = if !lt.is_elided() { lt.clean(cx) } else { Lifetime::elided() }; </ins> substs.insert(lt_def_id.to_def_id(), SubstParam::Lifetime(cleaned)); } indices.lifetimes += 1;

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. --Minimized example: Command: <!-- 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. --Platform: See backtrace <!-- 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 --<!-- TRIAGEBOT_END --
I'll look into it! claim
Minimized this to a local-crate-only test, and working on a solution currently:
Change:
use super::Selection; use super::SelectionContext; use super::SelectionError; <del> use super::TraitQueryMode; </del> use super::{ ImplSourceClosureData, ImplSourceDiscriminantKindData, ImplSourceFnPointerData, ImplSourceGeneratorData, ImplSourcePointeeData, ImplSourceUserDefinedData,

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code (minimized from [this test] in my library): [this test]: I expected to see this happen: Compile without errors. Instead, this happened: Compiled with errors: Note that it says is not implemented for , but then lists it as an existing implementation. It most recently worked on: 1.55.0 : <!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --
modify labels: +regression-from-stable-to-stable
Bisects to . cc searched nightlies: from nightly-2021-07-01 to nightly-2021-10-01 regressed nightly: nightly-2021-09-03 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
Any advancements on this issue? I currently can't upgrade to Rust 1.56 due to this exact problem
I might try my hand at diagnosing it, but someone with more context would definitely be faster at it.
Sorry for the delay in getting to this. I've opened with a fix.
I noticed that this regression was found in the 1.56 beta crater run: https://crater- Was it just overlooked at that time?
Seems kinda major to Yeah, this seems rather significant. It's right there in the results. https://crater-
Change:
// option. This file may not be copied, modified, or distributed // except according to those terms. <del> use syntax_pos::DUMMY_SP; </del> use rustc::mir::{self, Mir, Location}; use rustc::ty::{self, TyCtxt}; use util::elaborate_drops::DropFlagState;

Discussion:
MIR borrowck considers variables still initialized after their storage ends, so if an immutable variable is defined and used in a loop, this causes an error. e.g.: Which causes:
working on it
Change:
let ctxt = BreakableCtxt { coerce, <del> may_break: false, // will get updated if/when we find a `break` </del> <ins> may_break: false, // Will get updated if/when we find a `break`. </ins> }; let (ctxt, ()) = self.with_breakable_ctxt(expr.id, ctxt, || {

Discussion:
Having the following main function results in an illigal instruction on stable, beta and nighlty. It should be noted that when is not used after the loop, the illigal instruction does not occur Interestingly putting the same while-loop in a function works fine:
Update: A more simple version that also results in an illigal instruction: after some more trying, it can be shortened to this (and works for functions other than in main, as shown here: ) : adding a statement at the end of main seems to 'fix' the problem
Checking with godbolt, 1.25 and above: results in undefined instruction (this issue) 1.18 to 1.24: ICE with broken MIR 1.17: becomes no-op 1.16 and below: Error "use of undeclared label "
Err the last example is even featured in (introduced in ), but why this seems not tested at all . Edit: It generates an at MIR level. <details<summaryThe initial MIR already contains an unreachable.</summary</details<details<summary-Zunpretty=hir,typed</summary</details
It's because in the example that is tested, there's no semicolon: Why that makes a difference, I haven't determined yet.
The problem is, for some reason, the type checker inferred to have type , and thus the rest of the block is . However, without the the inferred type is just as expected.
Maybe slightly off-topic, but why are references to the label even allowed in the condition, rather than solely the body? You don't achieve extra expressiveness, as it's equivalent to returning false in the condition, and it makes things more complicated.
having code like this results in an ICE:
Because it is consistent with the desugaring of the while loop to a which is a valid and fairly sensible code.
I think the bug in in the type-checker then: it should not be giving the type of , clear. — you interested in fixing? I can give a few tips...
Marking as P-medium: technically a regression, but a very old one, and kind of a corner case. Still, I'll try to leave some notes on how to fix.
yeah, I can have a look into this. Might be a little delayed, but definitely within the next couple of weeks.
Change:
The standard library includes type aliases and function definitions for the C standard library in the `libc` module, and Rust links against `libc` and `libm` by default. <ins> # The "nullable pointer optimization" Certain types are defined to not be `null`. This includes references (`&T`, `&mut T`), owning pointers (`~T`), and function pointers (`extern "abi" fn()`). When interfacing with C, pointers that might be null are often used. As a special case, a generic `enum` that contains exactly two variants, one of which contains no data and the other containing a single field, is eligible for the "nullable pointer optimization". When such an enum is instantiated with one of the non-nullable types, it is represented as a single pointer, and the non-data variant is represented as the null pointer. So `Option<extern "C" fn(c_int) -> c_int>` is how one represents a nullable function pointer using the C ABI. </ins>

Discussion:
The FFI tutorial should reflect the fact that: is guaranteed to be a pointer with None represented as NULL. is the recommended way to represent a nullable fn pointer.
Nominating for milestone.
Accepted for well-defined
part of
Nominating to remove from milestone.
We can ship 1.0 without this, though it would be good to have this. Leaving as P-high, but removing from 1.0 milestone.
Taking this.
Change:
} } } <ins> match *kind { TerminatorKind::DropAndReplace { ref value, .. } => { self.assign(place, ValueSource::DropAndReplace(value), location); self.visit_operand(value, location); } _ => {} } </ins> } else { // Qualify any operands inside other terminators. self.super_terminator_kind(kind, location);

Discussion:
In the following example, and are allowed but isn't: The reason is that is lowered to in MIR, and that's not handled in const-checking as a and an assignment (which it functionally is). EDIT: nevermind, promotion works based on temporaries, so it shouldn't be affected. cc
I'm going to label this as a bug since it seems covered by from a T-Lang perspective.
Change:
Flags { verbose: m.opt_count("v"), <del> stage: m.opt_str("stage").map(|j| j.parse().unwrap()), </del> <ins> stage: stage, </ins> keep_stage: m.opt_str("keep-stage").map(|j| j.parse().unwrap()), build: m.opt_str("build").unwrap_or_else(|| { env::var("BUILD").unwrap()

Discussion:
When you compile rust you get: Regression of cc Maybe rustbuild should be compiled with to prevent errors like these in the future?
cc
Yeah when we fix this let's tag rustbuild with
Change:
use crate::test::{ filter_tests, parse_opts, run_test, DynTestFn, DynTestName, MetricMap, RunIgnored, <del> ShouldPanic, StaticTestName, TestDesc, TestDescAndFn, TestOpts, TrFailed, TrFailedMsg, </del> <ins> ShouldPanic, StaticTestName, TestDesc, TestDescAndFn, TestOpts, TrFailedMsg, </ins> TrIgnored, TrOk, }; use std::sync::mpsc::channel;

Discussion:
When a fails because there was no panic it should produce an error message to that effect. For example, the following test: when run with produces the following output: There is no indication why it failed. Which can be problematic if the test itself is created by a macro. Example:
I'm not familiar with the code, but I'd guess that you just need to change in here: to . (And add a test to make sure it works.)
Thanks.I would like to work on this.
go ahead! If you have any questions, feel free to ask them here.
Hi.I've the in and trying to write a test but is this right approach?
actually, I think you can get away with just changing this line: to update it to your , because such a test already exists for this case.
Thanks
The previous fix was closed, so this issue is open again. The contains detailed instructions.
I'd like to finish this out if is no longer working on it.
Change:
//! [`RwLock<T>`]: ../../std/sync/struct.RwLock.html //! [`Mutex<T>`]: ../../std/sync/struct.Mutex.html //! [`OnceLock<T>`]: ../../std/sync/struct.OnceLock.html <ins> //! [`LazyLock<T, F>`]: ../../std/sync/struct.LazyLock.html </ins> //! [`Sync`]: ../../std/marker/trait.Sync.html //! [`atomic`]: crate::sync::atomic

Discussion:
These types are now, however, the docs don't properly mention them everywhere yet: lists OnceCell in the overview, but not LazyCell. The docs should also explain when I should use which of these types, as they are superficially pretty similar. lists Once and OnceLock, but not LazyLock. The same point about "when to use which type" applies. (It seems like is basically the same as , but I am not sure.) Cc
thatnks for the PR! The question of Once vs OnceLock seems to remain unresolved though. If Once is to OnceLock what is to Mutex, then it should probably be considered extremely niche as one can't even safely protect any data that way?
Yeah, I do indeed have nothing useful to say about Once, basically, because it doesn't seem very useful except as a raw implementation primitive of OnceLock. I suppose we could add a comment that soft-discourages it?
Yeah I think that would be useful.