jiebi/CodeConvo huggingface dataset:
Change:
<ins> // run-rustfix fn main() { let x = "com.example.app"; let y: Option<&str> = None; let _s = y.unwrap_or(|| x.split('.').nth(1).unwrap()); //~^ ERROR: mismatched types [E0308] } </ins>

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --should suggest if the argument is a closure instead of suggesting to call the closure Given the following code: <!-- Please provide a link to -- The current output is: <!-- The following is not always necessary. --Ideally the output should look like: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- 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 --
claim
This probably can be generalized if the code is written carefully enough.
Do you mean, we should handle other types like which may use with a closure?
I know nothing about the internals of rustc diagnostics but a general way would be to check if a similar method in name accepts a closure and suggest that first, if nothing similar can be found then suggest calling the closure
I mean something more like what is suggesting, where you check if exists whose signature is compatible with a closure. But that requires doing a method probe, then doing some delicate logic to check argument compatibility.
Change:
<ins> error[E0308]: mismatched types --> $DIR/const-in-fn-call-generics.rs:11:21 | LL |         generic::<{ true }>() |                     ^^^^ expected `u32`, found `bool` error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'called on a value'', 'thread 'rustc' panicked at 'called on a value'' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [typeck] type-checking [checkmatch] match-checking -- label +F-constgenerics +F-constevaluatablechecked
Slightly minimized with fewer errors: The compiler seems to have trouble figuring out whether the type of matches the returned type <details<summaryProgram output</summary</summary

<!-- 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<strongICE location label +F-fn_delegation
Adding more methods in trait creates more ICE :eyes: <details<summary<strongBacktrace</strong</summary<p</p</details
Change:
&self, pred: impl Upcast<TyCtxt<'tcx>, ty::Predicate<'tcx>>, ) -> bool { <ins> let pred: ty::Predicate<'tcx> = pred.upcast(self.tcx); // We sometimes have to use `defining_opaque_types` for predicates // to succeed here and figuring out how exactly that should work // is annoying. It is harmless enough to just not validate anything // in that case. We still check this after analysis as all opaque // types have been revealed at this point. if pred.has_opaque_types() { return true; } </ins> let infcx = self.tcx.infer_ctxt().build(); let ocx = ObligationCtxt::new(&infcx); ocx.register_obligation(Obligation::new(

Discussion:
<!-- [31mICE[0m: Rustc '-Zvalidate-mir -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'broken MIR in Item(DefId(0:7 ~ a[e8bd]::hello)) (after pass CheckPackedRef) at bb3[6]:'', 'thread 'rustc' panicked at 'broken MIR in Item(DefId(0:7 ~ a[e8bd]::hello)) (after pass CheckPackedRef) at bb3[6]:'' 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: [mirbuilt] building MIR for [hasffiunwindcalls] checking if contains FFI-unwind calls --
another one from rust #![feature(typealiasimpltrait)] fn rpit() -impl Sized {} pub type Tait = impl Sized; pub fn foo() -Box<dyn std::future::Future<Output = Tait{ Box::new(async { let out: Tait = rpit(); _out }) } ``
another one that is a bit smaller than the original example:
Change:
<ins> error[E0283]: type annotations needed --> $DIR/issue-72616.rs:20:30 | LL |         if String::from("a") == "a".try_into().unwrap() {} |                              ^^ -------------- this method call resolves to `std::result::Result<T, <Self as TryInto<T>>::Error>` |                              | |                              cannot infer type | = note: cannot satisfy `String: PartialEq<_>` error: aborting due to previous error For more information about this error, try `rustc --explain E0283`. </ins>

Discussion:
This is either a regression of or it was closed prematurely. Fairly minimal reproducer: - I'm still not entirely sure what is actually wrong here - is it the lifetime as in ? Anyhow - the message doesn't refer to any T that needs to be specified, and the named explicit type is not sufficient to fix the issue even when given. Happens with nightly too.
Right, so the triggering problem here is the call - with that fixed it all falls into place, but the error message is still poor.
I got hit by this bug too and in my case the fix isn't obvious (it's a mix of an iterator and ). What did you mean by "fixing the get() call"?
It has a parameter type that is a bit bonkers given the type of the Hash, which causes the type inference of the to go off into the weeds I think; doesn't change that there is a bug - this is about the diagnostics after all. is a fixed version of the broken code.
The error message should have been fixed by , marking as .
Change:
} } <ins> combine_duplicate_switch_targets(terminator); </ins> self.super_terminator(terminator, location); } }

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: I expected to see this happen: no branch instructions emitted, makes an assumption that is , so should be inlined and optimized as a panic. Instead, this happened: there is a discriminant check still emitted. <!-- Provide the most recent version this worked on, for example: It most recently worked on: --It most recently worked on: nightly-2023-03-26 <!-- Provide the version you are using that has the regression. --See godbolt: Regression occurred in (cc searched nightlies: from nightly-2023-03-01 to nightly-2023-04-01 regressed nightly: nightly-2023-03-27 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: aarch64-unknown-linux-gnu Reproduce with: </details<details</summary(if you want to test on replace with ) </details<details</summary</details originally noticed the problem and opened , then suggested that this is a compiler issue, then that this is a regression, then bisected and opened this issue.
The end of this regression window is over 2 weeks from now. Why? Godbolt usually has pretty old nightlies. If I add : you can see we have duplicate switch targets, which means that either this commit is broken or godbolt doesn't have it:
godbolt seems to have ?
Because I knew that reproduces the regression, and wanted to cut some time bisecting. For reference I can reproduce the same issue with . <details<summary+nightly-2023-04-19 --emit=mir</summary</details
To be clear, separate from this issue I believe that this MIR: is a bug. I do not know what impact resolving that would have on this issue. But the helper that combines switch targets was (notionally) supposed to prevent this.
Yeah, I'm pretty sure that is the root cause.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
use rustc_hir::lang_items::LangItem; use rustc_hir::Mutability; use rustc_index::vec::IndexVec; <del> use rustc_middle::ty::{AssocKind, TyCtxt}; </del> <ins> use rustc_middle::ty::TyCtxt; </ins> use rustc_session::Session; use rustc_span::hygiene::MacroKind; use rustc_span::source_map::DUMMY_SP;

Discussion:
: cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Nearly 100% of that time is spent in . ! Is this even required for intra-doc links? AFAIK this is only for and , which don't have associated items.
... why is taking a quarter of the time?
I think this could be sped up quite a bit by only considering traits that have an associated item of the right name. Then rustdoc wouldn't have to go through the trait system at all, just look at it long enough to see it wouldn't work even if it did apply to the type.
Relevant code: We could change to take a parameter, that wouldn't be too invasive I think.
It probably also doesn't help that simplifies the type to an extent where all generic args are erased and then iterates on all trait implementations of it: If you have gazillions of then that's a problem :) Reducing the number of traits this (rather expensive) search is done is a good idea!
I think the strategy similar to would be helpful here too, but I guess the lower hanging fruit (checking whether the trait contains the name in the first place) should be tried before.
Discussed in Discord with , I'll be trying my hand at this one :rocket: claim
Change:
/// 1. The `pieces` slice must be at least as long as `fmt`. /// 2. Every [`rt::v1::Argument::position`] value within `fmt` must be a ///    valid index of `args`. <del> /// 3. Every [`Count::Param`] within `fmt` must contain a valid index of </del> <ins> /// 3. Every [`rt::v1::Count::Param`] within `fmt` must contain a valid index of </ins> ///    `args`. #[doc(hidden)] #[inline]

Discussion:
I recently broke the command , see , which demonstrates that CI doesn’t test rustdoc on the standard library with these flags. In effect, code with broken intra doc links in or other issues with items (and probably also for private items?) aren’t detected and can be merged into . Maybe we want to add a test for it? Possibly it’s even true that normal will always succeed if the one with does so we wouldn’t even need to test both with and without those flags? (Correct me if I’m wrong on that last point.) label T-infra, A-docs, A-testsuite, C-enhancement
it seems weird that we'd support this - why would you run document-hidden-items at all?
Because it’s super useful when you’re trying to understand implementation details. I’ve recently been contributing on specializations of iterators involving traits like which is public but . The broken link intra doc link actually hindered my progress reviewing a PR for a few hours until I realized that I could add . But in any case, it’s mostly just an argument of: Hidden items can and do have doc comments and it can be useful to render them (with ), so why shouldn’t we make sure to keep them working? Note that the PR mentioned in didn’t even modify the comment in question that got broken but instead just modified code in the module and with the effect of subsequently removing an import, in turn breaking the hidden doc comments. It’s hard to consistently keep those doc comments clean/working without an automated test, IMO.
Gotcha - this seems reasonable to me, but it couldn't replace building without those flags because they're not actually tested, x.py just builds them directly for upload to But it should be pretty cheap to run it twice since it's just the libraries.
Mentoring instructions: looks like already --document-private-items, so we just need to add to this command and we can close the issue :)
Change:
//~^ WARN this pattern is redundant //~| HELP remove this } <del> println!("{} {}", a, b); </del> <ins> println!("{} {}", registry_no, b); </ins> } }

Discussion:
This code snippet () results in the following lint output: The should contain the literal string , not the expanded macro that it repreesnts.
Ah, I think this is because we should be using (to get the code the user actually wrote) (to render the AST); I could PR this tonight.
Change:
fn deref_mut(&mut self) -> &mut T { &mut **self } } <ins> // FIXME(#21363) remove `old_impl_check` when bug is fixed #[old_impl_check] impl<'a, T> Iterator for Box<Iterator<Item=T> + 'a> { type Item = T; fn next(&mut self) -> Option<T> { (**self).next() } fn size_hint(&self) -> (usize, Option<usize>) { (**self).size_hint() } } </ins> #[cfg(test)] mod test { #[test]

Discussion:
This code fails to compile: error message: A similar error occurs if is used instead of . However, if you comment out the for loop, the call to works just fine. I thought maybe it had something to do with auto-deref, so I tried dereferencing the iterator: but dumps core: I'm not sure, but this may be related to ? dumps core when I try too. version:
CC
I think the problem is worse than this; trait objects in general don’t seem to be being recognised as implementing their traits: All three fail:
I'm not sure this is a bug at all. You're pretty much asking for an automatic - I did come up with a & -based model that would kinda work for this and IIRC pointed out that object-safe traits would eventually qualify for this. We do have object safety now, so it might be doable, but I wouldn't bet on it making into 1.0. In the meanwhile, does work? If it doesn't, is it just the case of missing in a couple places?
This a particular case of . See comments over there. is leaning towards an opt-in syntax extension that handles the boiler plate code, instead of automatic s by the compiler.
ByRef for trait objects seems to hit the same llvm assertion: output:
Interesting. So if I have a value with type where is a trait, then we can't say that implements in the general case? (Assuming object safety.) So my guess is that can still call because of auto deref? Shouldn't that mean it can work with ? Maybe that is what is about... You have to explicitly deref a to use it in ? (Sorry for all the questions. I'm just confused!)
doing autoderef on the iterator in seems like something reasonable to have. looks like the compiler is mistakenly treating an unsized lvalue as an rvalue, in trans.
On Mon, Jan 12, 2015 at 01:33:08PM -0800, Andrew Gallant wrote: Actually, I believe it works with , but not with the other types.
Just thank you for this issue. It resolves all my problems perfectly!
Change:
args.templates.push(template); continue; } else { <del> return Err(p.expect_one_of(&[], &[]).unwrap_err()); </del> <ins> return p.unexpected(); </ins> }; allow_templates = false;

Discussion:
The : pointed me to -- cc I see that there were regressions with during that review, but not exactly like what I'm seeing here. searched nightlies: from nightly-2020-09-28 to nightly-2020-10-04 regressed nightly: nightly-2020-09-30 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details
It's probably relevant that the actual token is passed as an arch-conditional parameter here:
Yes, I've missed this case, sorry. Will fix soon.
Fixed in
Works for me, thanks!
Change:
.span_to_lines(parts[0].span) .expect("span_to_lines failed when emitting suggestion"); <del> assert!(!lines.lines.is_empty()); </del> <ins> assert!(!lines.lines.is_empty() || parts[0].span.is_dummy()); </ins> let line_start = sm.lookup_char_pos(parts[0].span.lo()).line; draw_col_separator_no_space(&mut buffer, 1, max_line_num_len + 1);

Discussion:
Problem returns invalid span data, particularly and are set to 0, though . This happens with a completly empty file. Tested on the following cargo version: Whilst on the stable version the returned span array is empty: Steps Now you can see invalid span in file. I've already created and formatted and files with the output of different cargo versions. Here are the crutial differences and Context
Moved to rust-lang/rust, where diagnostics live. Seems to be caused by , cc
additional info: The regression is also present on the older version of nightly rustc: This was the version where I initially spotted the issue, then updated and rechecked, but it was still present in .
Probably caused by
triage: P-high. Assigning to self.
Change:
initial_binding.res() }); let res = binding.res(); <ins> if res == Res::Err || !this.ambiguity_errors.is_empty() { this.tcx .sess .delay_span_bug(import.span, "some error happened for an import"); return; } </ins> if let Ok(initial_res) = initial_res { <del> if res != initial_res && this.ambiguity_errors.is_empty() { </del> <ins> if res != initial_res { </ins> span_bug!(import.span, "inconsistent resolution for an import"); } <del> } else if res != Res::Err && this.ambiguity_errors.is_empty() && this.privacy_errors.is_empty() { </del> <ins> } else if this.privacy_errors.is_empty() { </ins> this.tcx .sess .create_err(CannotDetermineImportResolution { span: import.span })

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. --need <!-- 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
Crashes on but not on
Regression in nightly-2023-07-01 Regression in Regression in cc
reduced:
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
field, subst, field_path, <ins> id, </ins> ) { return Some(path); }

Discussion:
Lets consider the following code () : Here, we try to access a property on an object of type . Up to the 1.50 version, the error message was the following : However, since Rust 1.51 and onward, the diagnostic message changed to this: While there is indead a property on the struct, this can't be accessed like that, applying the compiler suggestion implies making the property of public, which is not possible. The compiler should not look at non- properties when searching for properties with a matching name for diagnostic purposes. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
label +A-diagnostics
Related issue:
Change:
// PTHREAD_MUTEX_NORMAL which is guaranteed to deadlock if we try to // re-lock it from the same thread, thus avoiding undefined behavior. let mut attr = MaybeUninit::<libc::pthread_mutexattr_t>::uninit(); <del> let r = libc::pthread_mutexattr_init(attr.as_mut_ptr()); debug_assert_eq!(r, 0); let r = libc::pthread_mutexattr_settype(attr.as_mut_ptr(), libc::PTHREAD_MUTEX_NORMAL); debug_assert_eq!(r, 0); let r = libc::pthread_mutex_init(self.inner.get(), attr.as_ptr()); debug_assert_eq!(r, 0); let r = libc::pthread_mutexattr_destroy(attr.as_mut_ptr()); debug_assert_eq!(r, 0); </del> <ins> cvt_nz(libc::pthread_mutexattr_init(attr.as_mut_ptr())).unwrap(); let attr = PthreadMutexAttr(&mut attr); cvt_nz(libc::pthread_mutexattr_settype(attr.0.as_mut_ptr(), libc::PTHREAD_MUTEX_NORMAL)) .unwrap(); cvt_nz(libc::pthread_mutex_init(self.inner.get(), attr.0.as_ptr())).unwrap(); </ins> } #[inline] pub unsafe fn lock(&self) {

Discussion:
In libstd/sys/unix there are numerous cases where return code is checked for error using following pattern: That means, that error checking is performed only when compiled in non-optimized mode or after explicitly enabling debug assertions. This is a little bit worrying, especially when used on platforms where those functions can indeed fail and break safety.
(For anyone who was confused by the given example, pthreadmutexattrinit can fail with ENOMEM.)
On some platforms types like pthreadmutext, pthreadcondt, etc., are "fat" structures that have sufficient size to hold everything necessary and their initialization will never fail (unless initialized incorrectly). But on others they are opaque pointers to and require an additional memory allocation. Search for those typedefs in libc crate, gives a rough approximation of affected platforms. Sadly this also affects static mutexes, so even lock / unlock could potentially fail. Either way you could end up with a mutex which is not mutually exclusive at all.
When mutex initialization fails this leads to non-functioning mutex and unsoundness. The pthreadmutexlock might also fail for recursive mutexes used in std::io and cause a mismatch in the number of locks / unlocks, but one needs to go out of the way to cause that. modify labels: C-bug I-unsound
Change:
<ins> // Copyright 2018 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. // aux-build:custom-attr-only-one-derive.rs #![feature(rust_2018_preview)] #[macro_use] extern crate custom_attr_only_one_derive; #[derive(Bar, Foo)] #[custom = "test"] pub enum A { B, C, } fn main() {} </ins>

Discussion:
Originally reported as this is reduced to: compiles with:
cc I'm not really sure what this classifies under, it seems like maybe although doesn't break it, only does. After though it may be broken by (I'm not 100% sure where this is happening)
I'm not really sure what this classifies under, it seems like maybe although doesn't break it This falls under and .
I hit this error last week when trying to update a crate that used 's derive macros. I found that ing the macro would give me the attribute error, but ing the crate worked.
I think that may be a separate bug, can you file a different issue? I believe I've fixed this issue in