jiebi/CodeConvo huggingface dataset:
Change:
#[unstable(feature = "trusted_len", issue = "37572")] unsafe impl<I: TrustedLen> TrustedLen for Take<I> {} <del> #[doc(hidden)] #[unstable(feature = "trusted_random_access", issue = "none")] unsafe impl<I> TrustedRandomAccess for Take<I> where I: TrustedRandomAccess, { const MAY_HAVE_SIDE_EFFECT: bool = I::MAY_HAVE_SIDE_EFFECT; } </del>

Discussion:
Look at this iterator. We all know that when ’s resulting implements , then the side-effects can be re-ordered. However, judging by the implementation of one would probably at least expect that it’s impossible to hit the without first either going through at least or first. Right? Well, here we go! on beta on stable 1.52.0 () label T-libs-impl, A-iterators, A-specialization, regression-from-stable-to-beta
cc
~As mentioned in the other issue, I think this is just another instance of ~ Edit: Nevermind, not really since it doesn't involve calling on Zip, rather this is about use of in Zip.
It’s related to . I guess the “random” aspect of is a bit weird for iterators like . You can do the same thing (accessing the from the center without “walking” there) with only, too, on stable already like so: <hrThis issue is only “really” a regression if out-of-order side-effects for iterators aren’t wanted.
steffahn brought up some general concerns about the implemention on () in I'll have to think some more about whether combining Take, TRA and backwards iteration is even doing the right thing under all circumstances, beyond the side-effects issue raised here. I am generally in favor of eliminating iterator side-effects that are not necessary to produce the final results. But of course that's currently undocumented and possibly surprising behavior and needs to be approved by the libs team, which hasn't happened so far. So while I like what it does it shouldn't have landed without discussion. I don't think so? At least that would be another implementation gap. That's what the whole thing is supposed to prevent. Oh, sure, that definitely is
https://rust- I'll submit a revert PR.
Change:
let real_path_ty = fcx.node_ty(pat.id); let (arg_tys, kind_name) = match real_path_ty.sty { <del> ty::ty_enum(enum_def_id, ref expected_substs) => { </del> <ins> ty::ty_enum(enum_def_id, ref expected_substs) if def == def::DefVariant(enum_def_id, def.def_id(), false) => { </ins> let variant = ty::enum_variant_with_id(tcx, enum_def_id, def.def_id()); (variant.args.iter().map(|t| t.subst(tcx, expected_substs)).collect::<Vec<_>>(), "variant")

Discussion:
struct variants have been unfeature gated, but there are corner cases that we did not intend. Here is (playpen compatible) code that demonstrates this: link:
Nomating for P-backcompat-lang, 1.0
Change:
<ins> error[E0597]: `n` does not live long enough --> $DIR/issue-69114-static-ty.rs:7:9 | LL |     FOO(&n); |     ----^^- |     |   | |     |   borrowed value does not live long enough |     argument requires that `n` is borrowed for `'static` LL | LL | } | - `n` dropped here while still borrowed error: aborting due to previous error For more information about this error, try `rustc --explain E0597`. </ins>

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried : I expected to see this: Instead, happens undefined behavior. Program successfully compiles in the Rust but fails to compile in (thats what I want).
Regressed in , likely cc
Visited in the compiler team triage meeting. It would be good to look into closing this ASAP. do you think you'll have time to investigate? If not, I'd want to find someone else.
We've assigned this speculatively to -- if you think you won't be able to investigate promptly, though, feel free to unassign and ping t-compiler for reassignment,
I expected the behavior to match that of this example (which still errors): I wonder if the gets erased somehow. Maybe an "user type annotation" is required on the from a , to give it a lifetime'd type?
Change:
debug!("save: remove old file"); } Err(err) if err.kind() == io::ErrorKind::NotFound => (), <del> Err(err) => { sess.dcx().emit_err(errors::DeleteOld { name, path: path_buf, err }); return; } </del> <ins> Err(err) => sess.dcx().emit_fatal(errors::DeleteOld { name, path: path_buf, err }), </ins> } let mut encoder = match FileEncoder::new(&path_buf) { Ok(encoder) => encoder, <del> Err(err) => { sess.dcx().emit_err(errors::CreateNew { name, path: path_buf, err }); return; } </del> <ins> Err(err) => sess.dcx().emit_fatal(errors::CreateNew { name, path: path_buf, err }), </ins> }; write_file_header(&mut encoder, sess);

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. --With as a dependency. <!-- 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. --: This is repeated for what seems like every parallel compilation unit.
It appeared to be related to running out of space in the target directory.
Thank you for opening the issue and that explanation. This is probably fixed by (which will be in 1.76 but not 1.75) but I'll try to reproduce the crash just in case it isn't fixed by that.
The reproducer script I cooked up for reproduces this ICE backtrace on stable, so I'm linking this to that PR.
Change:
// the rexport defines the path that a user will actually see. Accordingly, // we add the rexport as an item here, and then skip over the original // definition in `visit_item()` below. <ins> // // We also skip `#[macro_export] macro_rules!` that have already been inserted, // it can happen if within the same module a `#[macro_export] macro_rules!` // is declared but also a reexport of itself producing two exports of the same // macro in the same module. let mut inserted = FxHashSet::default(); </ins> for export in self.cx.tcx.module_exports(CRATE_DEF_ID).unwrap_or(&[]) { if let Res::Def(DefKind::Macro(_), def_id) = export.res { if let Some(local_def_id) = def_id.as_local() { if self.cx.tcx.has_attr(def_id, sym::macro_export) { <del> let hir_id = self.cx.tcx.hir().local_def_id_to_hir_id(local_def_id); let item = self.cx.tcx.hir().expect_item(hir_id); top_level_module.items.push((item, None)); </del> <ins> if inserted.insert(def_id) { let hir_id = self.cx.tcx.hir().local_def_id_to_hir_id(local_def_id); let item = self.cx.tcx.hir().expect_item(hir_id); top_level_module.items.push((item, None)); } </ins> } } }

Discussion:
<brIn current stable, and nightly-2021-08-28: ! <brIn current beta, current nightly, and nightly-2021-08-29: ! <brNotice that appears twice in the sidebar under the list of macros exported by the crate. Bisects to .
searched nightlies: from nightly-2021-08-10 to nightly-2021-09-26 regressed nightly: nightly-2021-08-29 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
It looks like in both versions there's also a bug where is not shown.
I think the fix here is to show "pub use repro as repro2" in the crate root - it sounds like currently it's being unconditionally inlined and then on top of that using the original name instead of the new one.
This also affect the unstable json output of rustdoc. If we take the example given by there are 3 items (1 reexport + 2 macro) instead of only two: The bug seems that the macro appears for whatever reason 2 times instead of only one.
Change:
if let (None, Some(ty)) = (self.found_local_pattern, self.node_ty_contains_target(local.hir_id)) { <ins> // FIXME: There's a trade-off here - we can either check that our target span // is contained in `local.span` or not. If we choose to check containment // we can avoid some spurious suggestions (see #72690), but we lose // the ability to report on things like: // // ``` // let x = vec![]; // ``` // // because the target span will be in the macro expansion of `vec![]`. // At present we choose not to check containment. </ins> self.found_local_pattern = Some(&*local.pat); self.found_node_ty = Some(ty); }

Discussion:
This compiles just fine: But this gives a compiler error: It seems really weird that the second statement is affected like this? Empty project (created with ), unmodified (so no extra dependencies): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It is actually that the first statement has type error, but somehow the error is reported to the second statement. The first statement alone reports the error correctly and by fixing the error, the following compiles fine
This happens on Nightly and on Stable.
Labeling as this was a regression introduced by 1.41.0.
Assigning .
Problem seems to be that we always assume the last closure was the source of the inference failure
Just sticking a return after is enough to get the correct diagnostic in this specific instance. However, we clearly need to be smarter than that, as in a sequence of closures, any of them could be the source of an inference error (current implementation always assumes last, just adding a return always assumes first).
Definitely not the case - looking into some alternative fixes. claim
Ok this is even more subtle than I first thought. There's just far too much ambiguity here for this diagnostic code to produce a sensible suggestion. Any time a sub-expression/local pattern/argument pattern/closure's type contains the inference target it immediately becomes a candidate for suggesting on. In this case though, the inference target is , so any code that has anything to do with strings will trip the diagnostic...
Compiling the above results in this - clearly the has nothing to do with the error...
I have a similar message to: But what I don't understand is: why does it complain it can't infer the type if it clearly knows the type?
Change:
use self::TupleArgumentsFlag::*; /// The type of a local binding, including the revealed type for anon types. <del> #[derive(Copy, Clone)] </del> <ins> #[derive(Copy, Clone, Debug)] </ins> pub struct LocalTy<'tcx> { decl_ty: Ty<'tcx>, revealed_ty: Ty<'tcx>

Discussion:
Because of the method error, doesn't get a type (not even , AFAICT), and then it gets inferred to from another call in the function, which results in the unsized variable error.
cc
I'd expect a simple fix for this would be to actually set as 's type, so it can't be inferred to anything else, although that could make other errors less informative.
I just spent a lot of time looking at a error. The errors were hidden by a couple of screens of "doc comment not used by rustdoc" warnings. Because was unknown, the compiler assumed it implemented no traits at all, leading to misleading errors below and user confusion: "why isn't it when this other similar type similar is?", "how can I find out if a type is " and so on. I don't know if works like that, but in this case it might be better to assume that the type implements any trait it's required to.
That doesn't really work out, since the issue here is that inference gets a free pass instead of inferring which would at least signal anything. The fix seems simple, I really don't know why I haven't tried it yet
I'm not saying that the type should be inferred to something else from the code below (like you said it was happening in the issue description) -- that seems bad. But on the other hand the compiler should probably not report an error every place the type or variable is used.
I just reread, and: That's not relevant here - the problem is inference flows up into the variable, which is correct in other cases but in this case it infers the slice type which is unsized. The error is a mere side-effect.
The underlying cause is that we have two maps for →, a general one and one for locals. When type checking we write to the general one but the one for locals is only written to once, during initialization, and the we read from it. If we kept it up to date or read from the general map, the knock-down error wouldn't appear.
Change:
use { parking_lot::{Condvar, Mutex}, rustc_data_structures::fx::FxHashSet, <del> rustc_data_structures::{defer, jobserver}, </del> <ins> rustc_data_structures::jobserver, </ins> rustc_span::DUMMY_SP, std::iter, <del> std::process, </del> std::sync::Arc, };

Discussion:
I noticed that when parallel rustc panics due to deadlock, it would say instead of . Is this intended?
Hm, I did recently land but I'm not sure if it would cause this issue. It should only affect threads that Rust doesn't create itself and in any case it switches the default name from (which gets rendered as ) to the OS thread name (if available). So if anything I'd have thought it would have the opposite effect. Though maybe there's something about parallel's deadlocks I'm missing.
I think you're good since the problem is older than your pr :D
Oh good! I mean bad, but I was dreading a very long debugging session
well, if you feel bored or something.... :upsidedownface:
Serial rustc creates a single thread called rustc. I assume parallel rustc just doesn't name its rayon threads, no debugging session ahead.
We create a new thread to look for query cycles, it's unnamed at the moment and that's where the panic happens.
Change:
&& imp.items.iter().all(|i| { let item_id = i.item_id; item_id.is_local() <del> && !is_item_reachable( self.tcx, self.is_json_output, &self.cache.effective_visibilities, item_id, ) </del> <ins> && !self .cache .effective_visibilities .is_reachable(self.tcx, item_id.expect_def_id()) </ins> }) { <ins> debug!("ImplStripper: no public item; removing {imp:?}"); </ins> return None; } else if imp.items.is_empty() && i.doc_value().is_empty() { <ins> debug!("ImplStripper: no item and no doc; removing {imp:?}"); </ins> return None; } }

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected the documentation for the type alias to show the method and the implementation of . Instead, the type alias does not show the method . It does however show the implementation of . ! By publicly exposing through , the documentation of on the alias is documented as I expected, but then is publicly reachable, which in my case is unwanted due to being an internal implementation detail. This also works when making the statement , which gets the docs to look like I expected them to. ! <!-- 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. --: Thanks for helping me figure out why what I was expecting wasn't happening though it looked like it should.
I think it's ok to document an impl on a reexported if the reexported item is not doc hidden. I'll send a fix in the next weeks.
Change:
set(&mut config.vendor, build.vendor); if let Some(ref install) = toml.install { <del> config.prefix = install.prefix.clone(); </del> <ins> config.prefix = install.prefix.clone().map(PathBuf::from); config.mandir = install.mandir.clone().map(PathBuf::from); config.docdir = install.docdir.clone().map(PathBuf::from); config.libdir = install.libdir.clone().map(PathBuf::from); </ins> } if let Some(ref llvm) = toml.llvm {

Discussion:
No destdir is passed to in
That causes fail in Gentoo build
As far as I understand, we need to to pass to function and add value of to prefix here
Change:
$source_type, &[], ); <del> if let Subcommand::Check { all_targets: true, .. } = builder.config.cmd { cargo.arg("--all-targets"); } </del> <ins> cargo.arg("--all-targets"); </ins> // Enable internal lints for clippy and rustdoc // NOTE: this doesn't enable lints for any other tools unless they explicitly add `#![warn(rustc::internal)]`

Discussion:
It's possible to have errors in files such as: and , and have pass. I would expect to be equivalent of and check every file that CI checks. Otherwise, I run , push code to a PR, and only find later that I have a typo or such.
We don't check tests by default, but you can pass --all-targets () to check tests. I believe this is consistent with cargo check behavior? One reason we don't check tests by default is that causes duplicate error messages for the 'base' crate typically which are annoying (and most changes don't actually need them). If Cargo handled that and didn't show duplicate messages, I imagine we could change the default as well.
Oh, you're right. So my mistake was assuming that is more thorough than it is (my text editor invokes it for me, even for tests, so I didn't realize the command doesn't do everything itself).
Just FYI, 1.55 now deduplicates messages.
Oh, great news -- in that case I'm going to go ahead and reopen this as it seems likely to make sense to check tests (by default, and likely without an option to disable that). Should be a pretty simple adjustment to bootstrap.
Change:
struct RemapHiddenTyRegions<'tcx> { tcx: TyCtxt<'tcx>, <ins> /// Map from early/late params of the impl to identity regions of the RPITIT (GAT) /// in the trait. </ins> map: FxIndexMap<ty::Region<'tcx>, ty::Region<'tcx>>, num_trait_args: usize, num_impl_args: usize, <ins> /// Def id of the RPITIT (GAT) in the *trait*. </ins> def_id: DefId, <del> impl_def_id: DefId, </del> <ins> /// Def id of the impl method which owns the opaque hidden type we're remapping. impl_m_def_id: DefId, /// The hidden type we're remapping. Useful for diagnostics. </ins> ty: Ty<'tcx>, <ins> /// Span of the return type. Useful for diagnostics. </ins> return_span: Span, }

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: expected lifetime parameter, but found another generic parameter', 'error: internal compiler error: expected lifetime parameter, but found another generic parameter' 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: [collectreturnpositionimpltraitintraittys] comparing an impl and trait method signature, inferring any hidden types in the process [typeof] computing type of --
cc
Change:
Ok(P(T::recovered(Some(QSelf { ty, path_span, position: 0 }), path))) } <del> pub(super) fn maybe_consume_incorrect_semicolon(&mut self, items: &[P<Item>]) -> bool { </del> <ins> pub fn maybe_consume_incorrect_semicolon(&mut self, items: &[P<Item>]) -> bool { </ins> if self.eat(&token::Semi) { let mut err = self.struct_span_err(self.prev_token.span, "expected item, found `;`"); err.span_suggestion_short(

Discussion:
We have a Rust-2015 doc test which has an which started failing to build on nightly 2021-11-21 (but passes on stable/2021-11-20). It now fails with
Probably caused by (; no rollup?).
That seems unlikely, is more plausible. doesn't affect doctests.
Oh, I think I got misled by the "rustdoc" bit.
I can't reproduce this. I tried /// extern crate inner; /// and running , but all the tests passed fine. can you link the original code?
The failure is You can see the first failure in CI at
The following seems like a minimal reproduction when used with 2015: /// extern crate mycrate; /// mycrate::foo(); /// Bisected to .
cc , I think it might make sense to revert temporarily unless you already have an idea for a fix.
Change:
} pub fn env(&mut self, key: impl AsRef<OsStr>, value: impl AsRef<OsStr>) -> &mut Cargo { <ins> // These are managed through rustflag/rustdocflag interfaces. assert_ne!(key.as_ref(), "RUSTFLAGS"); assert_ne!(key.as_ref(), "RUSTDOCFLAGS"); </ins> self.command.env(key.as_ref(), value.as_ref()); self }

Discussion:
Compare , this was intentional Items which are private, like , have disappeared
The warnings is removed in .
The haven't never been public. Not sure if I made it disappeared. cc
Also this page is 404 now. Before it listed all the internal crates.
I don't see how your PR could've done that -- cc I think you recently had a PR touching document-private-items?
The PR just changed some warnings around intra-doc-links, nothing to do with . My suspicion since the index page is gone is that something changed in bootstrap.
I take it back, I did modify href in That was a few weeks ago now and should have documented strictly more items, though.
This is the issue I pointed out in the second part of I clearly didn't explain the issue well enough.
Change:
<ins> error[E0631]: type mismatch in closure arguments --> $DIR/issue-41366.rs:10:5 | LL |     (&|_|()) as &dyn for<'x> Fn(<u32 as T<'x>>::V); |     ^^-----^ |     | | |     | found signature of `fn(_) -> _` |     expected signature of `for<'x> fn(<u32 as T<'x>>::V) -> _` | = note: required for the cast to the object type `dyn for<'x> std::ops::Fn(<u32 as T<'x>>::V)` error[E0271]: type mismatch resolving `for<'x> <[closure@$DIR/issue-41366.rs:10:7: 10:12] as std::ops::FnOnce<(<u32 as T<'x>>::V,)>>::Output == ()` --> $DIR/issue-41366.rs:10:5 | LL |     (&|_|()) as &dyn for<'x> Fn(<u32 as T<'x>>::V); |     ^^^^^^^^ expected bound lifetime parameter 'x, found concrete lifetime | = note: required for the cast to the object type `dyn for<'x> std::ops::Fn(<u32 as T<'x>>::V)` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0271`. </ins>

Discussion:
Probably somewhat related to This ICE's on stable, beta and nightly: Playground: Backtrace:
The ICE doesn't appear on the latest nightly (), marked as E-needstest

Running the following code triggers an internal compiler error and the error message says that it's a bug and I should report it, so I'm doing that now:
mcve:
Note, that this does not ICE anymore on nightly, instead it gives me: Can this be closed

I'm experimenting with a parser combinator and ran into an issue with closure lifetime inference. This might be a duplicate of , since it uses a similar (but simpler) mechanism to produce the same error message. However, in the code below the error is potentially a lot further away, and since I need to return values from the closure I'm having trouble finding any way to make it work by explicitly specifying a signature. Since it involves more moving parts, I'm also not sure how to confirm if the underlying issue is the same. I removed all parts that aren't involved in triggering the error message (the original use case has trait methods with related return types). It comes down to the following error message: And here is the triggering code:
After some experimentation, I tried a possible fix, which lead to an ICE. I changed to which gives me: My is: And here is the :
The ICE reduced:
Triage: still ICEs
Still ICEs:
The reduced example doesn't show the ICE, from 1.35.0 (tested on godbolt). Marked as E-needstest
And the original code is now accepted, so adding tests is enough to close this ticket.