jiebi/CodeConvo huggingface dataset:
Change:
python3 ../x.py test --stage 2 src/tools/tidy &&  python3 ../x.py test --stage 0 core alloc std test proc_macro &&  # Build both public and internal documentation. <del> RUSTDOCFLAGS="--document-private-items" python3 ../x.py doc --stage 0 library/test &&  </del> <ins> RUSTDOCFLAGS="--document-private-items --document-hidden-items" python3 ../x.py doc --stage 0 library/test &&  </ins> /scripts/validate-toolstate.sh &&  /scripts/validate-error-codes.sh &&  reuse lint && 

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:
<ins> fn map(x: Option<Box<()>>) -> Option<Box<()>> { match x { None => None, Some(x) => Some(x), } } fn main() { map(None); } // EMIT_MIR rustc.map.SimplifyLocals.diff </ins>

Discussion:
The doesn't have any effect. (Labeling because this prevents codegen of the like . Which may result in a few extra instructions being emitted to move registers and jump to the return block for cg_clif.) modify labels: +A-mir +A-mir-opt +A-cranelift
We already have a pass that propagates the terminator, it should be possible to make it handle as well. (however can leave sideeffects visible to the caller, so maybe this should be a proper dead code elimination pass instead)
For background, this is a side-effect of (see the MIR diagram in the PR summary) and . The MIR for the above example used to contain a frivolous open drop of . After my changes to drop elaboration, all branches of the open drop become no-op s, which are then removed by the pass. The read of the discriminant as part of the open drop remains, however. To my knowledge, we don't have a dead-code elimination pass for the MIR, which would be the proper way to handle this.
Change:
} } <del> if let Node::Expr(expr) = tcx.hir_node(call_hir_id) { </del> <ins> if let Node::Expr(expr) = call_node { </ins> if let hir::ExprKind::Call(hir::Expr { span, .. }, _) | hir::ExprKind::MethodCall( hir::PathSegment { ident: Ident { span, .. }, .. },

Discussion:
When calling in a fn that expects we currently emit: We should check whether and suggest the removal of the call. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
feel free to reach out either on this ticket or on a PR, but be warned that this has the potential to be quite involved. It is a great introduction to how some parts of fit together though.
I've been looking into this for a while now, and my idea was to: Check if there a .into() call, check if the type of self was T and finally check if the argument of the function was Into<T. However I cannot figure how to get the type of Self. As far as my understanding goes, rustc hasn't yet inferred the type.
You can query the in-progress type table with the for the expression. You're gonna have an with a . From the first argument in that variant you can take the first element and get the expression for in . Then you can use the for that expression to do I do not know if we will have populated 's type by then, but if we have, then that will give you the type of . Then, if you're in an you can use to see if the inferred type for can be coerced to in the original example. I know this is a bit vague, but for this is inherently exploratory work :)
Hi, are you still working on this issue
No, feel free to claim it if you want
release-assignment
Change:
expand_glob_delegation_outside_impls = glob delegation is only supported in impls <ins> expand_glob_delegation_traitless_qpath = qualified path without a trait in glob delegation </ins> expand_helper_attribute_name_invalid = `{$name}` cannot be a name of derive helper attribute

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'internal error: entered unreachable code'', 'thread 'rustc' panicked at 'internal error: entered unreachable code'' 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: [resolverforloweringraw] getting the resolver for lowering -- label +F-fndelegation
^_^
Fixed in
Change:
|               ^ the trait `Copy` is not implemented for `Foo` | = note: the `Copy` trait is required because this value will be copied for each element of the array <ins> = help: consider using `core::array::from_fn` to initialize the array = help: see https://doc.rust-lang.org/stable/std/array/fn.from_fn.html# for more information </ins> help: consider annotating `Foo` with `#[derive(Copy)]` | LL + #[derive(Copy)]

Discussion:
For this snippet (): rustc gives: Since , for const-able values, rustc suggests the creation of a constant binding. Here this is not possible because is not const fn. However, we can suggest instead.
Personally, I prefer over a separate binding. Even in the case, the generated code will call the initialization function many times. Maybe in the case where bindings are possible, we can suggest both? Where they are not possible, we don't suggest anything right now, so at the least we should suggest there. what do you think?
Once is stable we can suggest that :3. But until then sounds reasonable.
Agreed, good point about . It seems to have a stabilization PR open with an FCP, which is blocked: . Maybe there might be progress on it this month: . Even if we stabilize inline const, it might make sense to wait with suggesting it for a while so that we don't make code depend on the latest MSRV immediately. So therefore, I think that it might still make sense to implement this in the meantime.
I think this should (in the future) suggest  instead, since the function would only be called once if were , whereas calls it for every element.
Change:
<ins> error: lifetime may not live long enough --> $DIR/variance-associated-types2.rs:13:12 | LL | fn take<'a>(_: &'a u32) { |         -- lifetime `'a` defined here LL |     let _: Box<dyn Foo<Bar = &'a u32>> = make(); |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^ type annotation requires that `'a` must outlive `'static` | = help: consider replacing `'a` with `'static` error: aborting due to previous error </ins>

Discussion:
IIUC currently a trait object is always covariant in its associated types, regardless of their positions. This makes it possible to pass a non-static reference to a function expecting a static reference:
With rustc 1.0.0 ..= 1.16.0, the following error was emitted:
-- this looks plausibly similar to , but I don't know enough to be certain.
Oh wow how are these not invariant? Cc
Assigning as and removing .
Just in case, in my last action I've removed by accident and it back :).
Wait, these are supposed to be invariant. This is definitely a bug. It would be great to figure out just which nightly regressed this, maybe somebody can run cargo bisect? cleanup
Er, I guess I meant this? ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
searched toolchains nightly-2016-06-01 through nightly-2020-01-01 regression in nightly-2017-03-12 ... Previous error message: I used a slightly modified variant (just removed the IIRC): <details<summaryCode used</summary</details
Most likely candidate seems to be , cc
Thanks! Super useful.
After discussing a bit with this sounds more like than .
modify labels:-E-needs-bisection
Crater run from the fix (thanks to for the analysis). I was thinking about that and I realize that it's plausible that we could do variance inference on associated types and use that to inform the variance for types. It is sensible, for example, that a is covariant with respect to (that is the trait used in one of the affected examples). I'm a bit nervous about this though. For one thing, the core operations exposed by a type are clearly just its methods, but people can also project out from types (though that projection is generally considered invariant over the input types). But for another, it seems to give rise to some asymmetry and complexity around traits and variance that we have thus far avoided (and which I might prefer to continue to avoid).
Change:
<ins> // check-pass // edition:2021 macro_rules! m { () => { async {}.await }; } async fn with_await() { println!("{} {:?}", "", async {}.await); } async fn with_macro_call_expr() { println!("{} {:?}", "", m!()); } async fn with_macro_call_stmt_semi() { println!("{} {:?}", "", { m!(); }); } async fn with_macro_call_stmt_braced() { println!("{} {:?}", "", { m!{} }); } fn assert_send(_: impl Send) {} fn main() { assert_send(with_await()); assert_send(with_macro_call_expr()); assert_send(with_macro_call_stmt_semi()); assert_send(with_macro_call_stmt_braced()); } </ins>

Discussion:
This has already tripped up some people which seem to get quite confused with this error message, so I'd rather we not regress here: I tried this code: I expected to see this happen: Code compiles fine: the type of is . Instead, this happened: The type of is not send, since the backing state-machine generator produced for it now captures part of the internals involving a reference to the , which is not . It most recently worked on: beta : modify labels: +regression-from-stable-to-nightly -regression-untriaged
Might be related to / ?
I was also suspecting one of those, although I have to admit not having looked into it any further
Does it work with btw ? That should completely disable drop range tracking. (I've launched a try build there so that we have artifacts ready for that soon). There were also recent changes in the formatting macros/machinery last week IIRC. That could be related as well. This should be easy enough to bisect, and make sure where the regression is coming from.
Answering my own questions: doesn't change this, my guess is that it's actually unrelated to initially landed as part of and that rollup's commit doesn't reproduce the issue the change I mentioned was and its commit does reproduce the issue. This PR seems to have caused it indeed.
Nice investigation
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
Change:
let s = s.as_bytes(); let (integral, s) = eat_digits(s); match s.first() { <del> None => Valid(Decimal::new(integral, b"", 0)), </del> <ins> None => { if integral.is_empty() { return Invalid; // No digits at all } Valid(Decimal::new(integral, b"", 0)) } </ins> Some(&b'e') | Some(&b'E') => { if integral.is_empty() { return Invalid; // No digits before 'e'

Discussion:
I tried this code: I expected to see this happen: "Error: invalid float literal" Instead, this happened: OK: 0 It seems the "leading +" and "leading -" is broken. Further, with i32 and i64 is emits an error but IMO an incorrect one: "cannot parse integer from empty string" I would expect: "Invalid integer literal" : rustc 1.5.0-nightly ( 2015-10-11) binary: rustc commit-hash: commit-date: 2015-10-11 host: x86_64-unknown-linux-gnu release: 1.5.0-nightly
Oh my, the float part is embarrassing. Preparing a fix right now.
Thanks for taking a look Looks like this is working as expected on stable and has leaked into beta/nightly, so tagging as such.
Yes, this is a bug (not checking for empty strings in the right places) of the dec2flt code. The bug is also in beta, so the PR (which I'll file very soon) should probably be backported to beta.
Change:
<ins> // Copyright 2015 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. use std::fmt; // This ia file with many multi-byte characters, to try to encourage // the compiler to trip on them.  The Drop implementation below will // need to have its source location embedded into the debug info for // the output file. // αααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααα // ββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ // γγγγγγγγγγγγγγγγγγγγγγγγγγγγγγγγγγγγγγγγγγγγγγγγγγγγγγγγγγγγγγγγγγγγγγ // δδδδδδδδδδδδδδδδδδδδδδδδδδδδδδδδδδδδδδδδδδδδδδδδδδδδδδδδδδδδδδδδδδδδδδ // εεεεεεεεεεεεεεεεεεεεεεεεεεεεεεεεεεεεεεεεεεεεεεεεεεεεεεεεεεεεεεεεεεεεεε // ζζζζζζζζζζζζζζζζζζζζζζζζζζζζζζζζζζζζζζζζζζζζζζζζζζζζζζζζζζζζζζζζζζζζζζ // ηηηηηηηηηηηηηηηηηηηηηηηηηηηηηηηηηηηηηηηηηηηηηηηηηηηηηηηηηηηηηηηηηηηηηη // θθθθθθθθθθθθθθθθθθθθθθθθθθθθθθθθθθθθθθθθθθθθθθθθθθθθθθθθθθθθθθθθθθθθθθ // ιιιιιιιιιιιιιιιιιιιιιιιιιιιιιιιιιιιιιιιιιιιιιιιιιιιιιιιιιιιιιιιιιιιιιι // κκκκκκκκκκκκκκκκκκκκκκκκκκκκκκκκκκκκκκκκκκκκκκκκκκκκκκκκκκκκκκκκκκκκκκ pub struct D<X:fmt::Debug>(pub X); impl<X:fmt::Debug> Drop for D<X> { fn drop(&mut self) { // λλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλ println!("Dropping D({:?})", self.0); } } </ins>

Discussion:
I’m getting an ICE when compiling using
I was able to trace down the bug. It is due to me using a unicode character in the documentation of a function this somehow triggers the compiler bug. A minimal example is:
I believe Servo is also currently hitting this in the script crate during our current rust upgrade.
Yes, at least the failing assertion is the same. Removing non-ASCII characters from doc comments didn’t seem to help, though.
cc might this be another overflow error?
recommended on IRC to build with , but log output seems to be disabled in Nightly. So I built Rust with debugging enabled and tried again. (This took forever because of .) There was a lot of output, here is just the end of it:
This is lines / 299MB of output.
my current hypothesis is that this is the problem; it is at the very least very suspicious considering that five lines up in the previous statement we are normalizing the position to zero by subtracting the , not adding it.
(other good news: I have figured out how to make a regression test for this that will integrate into the rust test suite.)
Change:
// Handle Reference types, as these are the only relocations supported by const eval. // Raw pointers (and boxes) are handled by the `leftover_relocations` logic. let ty = mplace.layout.ty; <del> if let ty::Ref(_, _, mutability) = ty.sty { </del> <ins> if let ty::Ref(_, referenced_ty, mutability) = ty.sty { </ins> let value = self.ecx.read_immediate(mplace.into())?; // Handle trait object vtables if let Ok(meta) = value.to_meta() { <del> let layout = self.ecx.layout_of(ty.builtin_deref(true).unwrap().ty)?; if layout.is_unsized() { if let ty::Dynamic(..) = self.ecx.tcx.struct_tail(layout.ty).sty { if let Ok(vtable) = meta.unwrap().to_ptr() { // explitly choose `Immutable` here, since vtables are immutable, even // if the reference of the fat pointer is mutable self.intern_shallow(vtable, Mutability::Immutable)?; } </del> <ins> if let ty::Dynamic(..) = self.ecx.tcx.struct_tail(referenced_ty).sty { if let Ok(vtable) = meta.unwrap().to_ptr() { // explitly choose `Immutable` here, since vtables are immutable, even // if the reference of the fat pointer is mutable self.intern_shallow(vtable, Mutability::Immutable)?; </ins> } } }

Discussion:
The build of smoltcp on nightly started failing recently with an ICE: https://travis- ~I suspect this might be caused by E0713, but it shouldn't be an ICE in any case.~
I believe the fundamental cause of the error is that the code looks like the following: That's pretty obviously unsound.
Correction for earlier comment: E0713 is completely unrelated. I've eliminated the problematic code that caused it in m-labs/smoltcp but the crash is still there.
cc (also, such an ICE should say "const checking" or similar - we should maybe even rename the pass itself in the compiler - the "qualify" part isn't as primary for MIR as it is for the AST side).
<details<summaryFull backtrace</summary</details<details<summaryfunction </summary</details
MCVE: : ok : ICE I'm bisecting it now.
Bisected to / .
Oh, I forgot about the ZST trickery, sorry, will have a fix tomorrow
What's the ZST here? in ?
Yes. That's a that gets unsized to .
Change:
self.pred_count[*target] += 1; self.pred_count[current] -= 1; } <del> *changed = true; </del> self.basic_blocks[current].terminator = Some(terminator); } }

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. --repo @ Rustc simply hangs when running Edit: while rustc is crunching on the hang:
cc ? edit: I assume this is due to
O_o yea, I'll have a look
Wild speculation: might have the same cause (EDIT: Backtrace says yes)
Change:
"Cross-compiling is not yet supported with `download-rustc`", ); <del> // #102002, cleanup stage1 and stage0-sysroot folders when using download-rustc so people don't use old versions of the toolchain by accident. let _ = fs::remove_dir_all(host_dir.join("stage1")); let _ = fs::remove_dir_all(host_dir.join("stage0-sysroot")); </del> <ins> // #102002, cleanup old toolchain folders when using download-rustc so people don't use them by accident. for stage in 0..=2 { if stage != compiler.stage { let dir = sysroot_dir(stage); if !dir.ends_with("ci-rustc-sysroot") { let _ = fs::remove_dir_all(dir); } } } </ins> // Copy the compiler into the correct sysroot. let ci_rustc_dir =

Discussion:
with in no longer places & into but just into . Tested on Linux. . label T-infra A-bootstrap A-contributor-roadblock <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'm not convinced the binaries in are actually the newly compiled binaries; I think they may just never be copied from into a sysroot.
I am not familiar enough with the bootstrap process to be able to confirm or dispute this. As far as I'm concerned, I've relinked my toolchain to and everything appears to work flawlessly.
can you post the output of and ?
yeah that looks like it's not actually reflecting your changes, just using the latest nightly unmodified If it were working properly it would say -dev
Hmm, that can't be. I am currently working on fixing and modifications to the rustdoc source code are indeed properly reflected in the compiled binaries. Maybe the version string is just wrong but my local changes are picked up.
Actually, I have a counterquestion. Can you by chance reproduce this? Or is it just me and I'm just wondering why more people haven't stumbled upon this issue.
claim
cc
Change:
err.buffer(&mut self.errors_buffer); } <ins> /// User cannot make signature of a trait mutable without changing the /// trait. So we find if this error belongs to a trait and if so we move /// suggestion to the trait or disable it if it is out of scope of this crate fn is_error_in_trait(&self, local: Local) -> (bool, Option<Span>) { if self.body.local_kind(local) != LocalKind::Arg { return (false, None); } let hir_map = self.infcx.tcx.hir(); let my_def = self.body.source.def_id(); let my_hir = hir_map.local_def_id_to_hir_id(my_def.as_local().unwrap()); let td = if let Some(a) = self.infcx.tcx.impl_of_method(my_def).and_then(|x| self.infcx.tcx.trait_id_of_impl(x)) { a } else { return (false, None); }; ( true, td.as_local().and_then(|tld| { let h = hir_map.local_def_id_to_hir_id(tld); match hir_map.find(h) { Some(Node::Item(hir::Item { kind: hir::ItemKind::Trait(_, _, _, _, items), .. })) => { let mut f_in_trait_opt = None; for hir::TraitItemRef { id: fi, kind: k, .. } in *items { let hi = fi.hir_id(); if !matches!(k, hir::AssocItemKind::Fn { .. }) { continue; } if hir_map.name(hi) != hir_map.name(my_hir) { continue; } f_in_trait_opt = Some(hi); break; } f_in_trait_opt.and_then(|f_in_trait| match hir_map.find(f_in_trait) { Some(Node::TraitItem(hir::TraitItem { kind: hir::TraitItemKind::Fn( hir::FnSig { decl: hir::FnDecl { inputs, .. }, .. }, _, ), .. })) => { let hir::Ty { span, .. } = inputs[local.index() - 1]; Some(span) } _ => None, }) } _ => None, } }), ) } </ins> // point to span of upvar making closure call require mutable borrow fn show_mutating_upvar( &self,

Discussion:
Summary: The compiler suggests changing to when trying to modify in a method. For trait implemantions this does not work because it would require changing the trait definition too (which is often not possible). Example: I was trying to implement the trait from the standard library for a custom type: () This of course doesn't work since you can't modify data behind a reference: However, I noticed that the help message suggests changing the to , which is incorrect since that would require changing the trait definition in the standard library too. Suggestion: I don't know if this is possible, but maybe this help message should only be shown for "normal" methods and hidden when implementing trait methods?
Maybe only hide the suggestion if the trait comes from a foreign crate?
Or suggest to change the trait (if it is in this crate) not change the function in the part.
One more idea: suggest ///
Change:
self.ty_inhabitedness_forest(ty).contains(self, module) } <del> pub fn is_ty_uninhabited_from_all_modules(self, ty: Ty<'tcx>) -> bool { </del> <ins> pub fn is_ty_uninhabited_from_any_module(self, ty: Ty<'tcx>) -> bool { </ins> !self.ty_inhabitedness_forest(ty).is_empty() }

Discussion:
Probably one should never write this, and I wonder if it will be disallowed in the future. Happens on stable, beta and nightly, in all const-forms existing (includes const generics) <details<summaryBacktrace:</summary</details
Note: You could also write it the following way, in order to not need the attribute, as the previous code complains about recursion without that attribute.
Regression introduced in
cc due to Edit: I think I have a fix for this.