jiebi/CodeConvo huggingface dataset:
Change:
}; UsefulWithWitness(new_witnesses) } <ins> Useful(mut unreachables) => { if !unreachables.is_empty() { // When we apply a constructor, there are `arity` columns of the matrix that // corresponded to its arguments. All the unreachables found in these columns // will, after `apply`, come from the first column. So we take the union of all // the corresponding sets and put them in the first column. // Note that `arity` may be 0, in which case we just push a new empty set. let len = unreachables.len(); let arity = ctor_wild_subpatterns.len(); let mut unioned = FxHashSet::default(); for set in unreachables.drain((len - arity)..) { unioned.extend(set) } unreachables.push(unioned); } Useful(unreachables) } </ins> x => x, } }

Discussion:
The match remains exhaustive with highlighted pattern removed, but it does not produce any warnings: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I know where the problem comes from: this bit of code tries to handle unreachable sub-or-patterns diagnostics, but it's a bit of a hack. What remains is to come up with a better solution. claim
Change:
use rustc_errors::struct_span_err; use rustc_hir::def_id::{DefId, CRATE_DEF_INDEX, LOCAL_CRATE}; use rustc_hir::itemlikevisit::ItemLikeVisitor; <del> use rustc_hir::{ForeignItem, HirId, ImplItem, Item, ItemKind, TraitItem, CRATE_HIR_ID}; </del> <ins> use rustc_hir::{ForeignItem, HirId, ImplItem, Item, ItemKind, Node, TraitItem, CRATE_HIR_ID}; </ins> use rustc_middle::hir::map::Map; use rustc_middle::ty::query::Providers; use rustc_middle::ty::TyCtxt;

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. --Not minimal, but possibly helpful, from <!-- 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 --
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
This appears to have been caused by
claim
~A potential duplicate~
No that's a completely different error
Sorry I misread the error message, It is probably a duplicate of
Yep, that looks very similar
Change:
} } <ins> fn check_trait_item(&mut self, cx: &EarlyContext<'_>, it: &ast::AssocItem) { if let ast::AssocItemKind::TyAlias(..) = it.kind { self.check_case(cx, "associated type", &it.ident); } } </ins> fn check_variant(&mut self, cx: &EarlyContext<'_>, v: &ast::Variant) { self.check_case(cx, "variant", &v.ident); }

Discussion:
Associated types are types and thus should be capitalized. I think most code also does this. Recently I accidentally didn't capitalize it and was surprised that it doesn't lint for it: I'd expect it to say something. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
checking happens inside , add for , then inspect the kind of inside this checking.
I'd like to put my hand up for this if that's alright? It looks like a good one to get started on. claim
Change:
} impl Cargo { <ins> pub fn rustdocflag(&mut self, arg: &str) -> &mut Cargo { self.rustdocflags.arg(arg); self } </ins> pub fn rustflag(&mut self, arg: &str) -> &mut Cargo { self.rustflags.arg(arg); 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:
/// [not yet complete]: https://github.com/rust-lang/rust/issues/34601 mod where_keyword { } <del> #[doc(keyword = "while")] // /// Loop while a condition is upheld. /// /// The documentation for this keyword is [not yet complete]. Pull requests welcome! /// /// [not yet complete]: https://github.com/rust-lang/rust/issues/34601 mod while_keyword { } </del> // 2018 Edition keywords #[unstable(feature = "async_await", issue = "50547")]

Discussion:
I noticed the keyword seems to be missing from the [official documentation][docs]. Keywords like and are documented. Nor does come up when searching at the top. Is there a reason for it missing? [docs]:
These are probably just missing because nobody documentation for them yet, so feel free to send a PR.
If anyone is interested, you need to add documentation here:
I will take care of this one :)
Cool! Wanted to do it, but haven't been able to start on it yet. Perfect if you can take it over.
In that case, it will be nice to have you review the PR:
Partially resolved by I think this can be closed in favor of . What do you think ?
will close this when merged, and it addresses specifically, so we can also wait for that to land
Change:
If you're on Windows, please download either the [32-bit installer][win32] or the [64-bit installer][win64] and run it. <del> [win32]: https://static.rust-lang.org/dist/rust-1.0.0-beta-i686-pc-windows-gnu.msi [win64]: https://static.rust-lang.org/dist/rust-1.0.0-beta-x86_64-pc-windows-gnu.msi </del> <ins> [win32]: https://static.rust-lang.org/dist/rust-1.0.0-i686-pc-windows-gnu.msi [win64]: https://static.rust-lang.org/dist/rust-1.0.0-x86_64-pc-windows-gnu.msi </ins> ## Uninstalling

Discussion:
The rust book currently links to, an old beta version of rust, causing some problems using the tutorial. Example: Dining philosophers will not compile.
What's your rust version?
According to the installer: 1.0.0-beta. On windows x64.
It compiles on 1.0.0-beta.2 and up. You should update your compiler.
I believe is right here, so closing, but thanks for the report!
Change:
) -> InterpResult<'tcx, MPlaceTy<'tcx>> { debug!("eval_body_using_ecx: {:?}, {:?}", cid, ecx.param_env); let tcx = *ecx.tcx; <ins> assert!( cid.promoted.is_some() || matches!( ecx.tcx.def_kind(cid.instance.def_id()), DefKind::Const | DefKind::Static | DefKind::ConstParam | DefKind::AnonConst | DefKind::AssocConst ), "Unexpected DefKind: {:?}", ecx.tcx.def_kind(cid.instance.def_id()) ); </ins> let layout = ecx.layout_of(body.return_ty().subst(tcx, cid.instance.substs))?; assert!(!layout.is_unsized()); let ret = ecx.allocate(layout, MemoryKind::Stack);

Discussion:
Since , memoization of argumentless functions is restricted to intrinsics, because other functions could perform heap allocations and thus memoization would be incorrect. I doubt we have any argumentless intrinsic that is expensive enough that memoization is worth it, so I propose we remove the leftovers of that infrastructure. Cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I want to work on this but i never contributed to rust-lang before so i need some guidance.
Great! So... step 0 is to write as a comment here, this will make sure the issue is assigned to you and noone else tries to tackle it at the same time. The main change is to remove this function: entirely without a replacement. You'll then have to adjust the call site to act as if the function returned . This may allow some small cleanups at the call site; I expect nothing major to happen there. I do not think there will be further test changes due to this, so, should run through without any failures. If it doesn't, still open a PR and let us know of your findings.
claim
Change:
<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { let mut array = [1, 2, 3]; //~^ ERROR cannot determine a type for this local variable: cannot determine the type of this integ let pie_slice = array.slice(1, 2); } </ins>

Discussion:
Here is a very simple program which employs trait objects: : : : When this program is compiled and run, it fails with segmentation fault: This program is not correct. You can see that function produces a for arbitrary lifetime , but the local variable is valid only for body. A pointer to , however, is saved to the , and when it is accessed inside , a segmentation fault occurs. However, Rust still compiles it. I thought that borrowing checker should prevent this kind of errors. BTW, I can write or and it will compile either way, but I thought that when going from plain pointers to trait objects I should always specify exact kind of trait object. Not sure that I'm right here thought.
cc
Sounds similar to ; potential duplicate?
This appears to be fixed: Original example code updated to current rust: : : :
Awesome! flagging as needstest (not sure if one already exists)

(Doesn't happen with .)
Paging
Here's a truly minimal test case:
cc me
Variation: This gives a different error message:
Fixed in Can be closed.
Change:
}; let sources = map::new_str_hash::<source>(); <del> try_parse_sources(fs::connect(p, "sources.json"), sources); try_parse_sources(fs::connect(p, "local-sources.json"), sources); </del> <ins> try_parse_sources(fs::connect(syscargo, "sources.json"), sources); try_parse_sources(fs::connect(syscargo, "local-sources.json"), sources); </ins> let c = { pgp: pgp::supported(), root: p, bindir: fs::connect(p, "bin"), libdir: fs::connect(p, "lib"), workdir: fs::connect(p, "work"), <del> sourcedir: fs::connect(p, "sources"), </del> <ins> sourcedir: fs::connect(syscargo, "sources"), </ins> sources: sources, opts: opts };

Discussion:
There's some code for this in cargo now, but it doesn't quite do the right thing. See .
Also worth considering the difference between sysroot and the install prefix - they are not the same. For instance, I never install cargo, always running it out of the build directory, in which case the build directory is sysroot.
I think this is resolved.
Change:
<ins> // check-fail static STATIC_VAR_FIVE: &One(); //~^ cannot find type //~| free static item without body fn main() {} </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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
From
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-medium
Change:
} } <ins> pub fn inline_asm_dialect(&self) -> rustc_ast::LlvmAsmDialect { match self.asm_arch { Some(InlineAsmArch::X86 | InlineAsmArch::X86_64) => rustc_ast::LlvmAsmDialect::Intel, _ => rustc_ast::LlvmAsmDialect::Att, } } </ins> pub fn relocation_model(&self) -> RelocModel { self.opts.cg.relocation_model.unwrap_or(self.target.relocation_model) }

Discussion:
People used to gcc/clang inline assembly may try using the or directives directly in the assembly string, which can cause issues. Ideally, we should detect attempts to use those directives. Attempting to use should generate an error stating that that's the default. Attempting to use should generate an error and point to the option, ideally with a rustfix-applicable suggestion. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Is anyone currently working on this? I would like to do it if not.
Not to my knowledge, no.
claim
Change:
candidates.iter().map(|c| path_names_to_string(&c.path)).collect(); path_strings.sort(); <ins> let core_path_strings = path_strings.drain_filter(|p| p.starts_with("core::")).collect::<Vec<String>>(); path_strings.extend(core_path_strings); </ins> path_strings.dedup(); let (determiner, kind) = if candidates.len() == 1 {

Discussion:
rustc often offers a help to import something from std and core: Perhaps in such situations rustc could use an heuristic to suggest only one of the two imports.
cc feels like we should at least show first here?
This is quite useful in situations like the rust playground because there sometimes there are many different sources for a function, and sometimes the std one (that's most times the one you really want) gets elided in the "others" sources.
We already have a couple of hacks for these kind of suggestions, so I'd be fine with just modifying the code here to push any suggestion that starts with to the end of the list, or at the very least, after . As pointed above it might make sense to bias the sort to always put first. We could also consider removing all references to , but that makes me uneasy.
The regression test (), when run on the playground, does seem to have regressed between beta 1.57.0 and nightly 1.58.0, which is weird because it's a test, so it shouldn't have changed. Maybe it only regressed when there are external dependencies?
Change:
<ins> error[E0277]: `{float}` is not an iterator --> $DIR/float_iterator_hint.rs:4:14 | LL |     for i in 0.2 { |              ^^^ `{float}` is not an iterator | = help: the trait `Iterator` is not implemented for `{float}` = note: if you want to iterate between `start` until a value `end`, use the exclusive range syntax `start..end` or the inclusive range syntax `start..=end` = note: required for `{float}` to implement `IntoIterator` error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
rust version: Do you think it would be useful to add a hint here? Something in the lines of <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
i was hoping this to be my first PR to the compiler, if accepted as necessary. :D I need some guidance as to where this code might be though...
claim
hups sorry
I was testing the bot feature
The 'is not an iterator' message comes from the attribute. One solution would be to add a new case to that attribute which detects literals of the form (where both sides are numeric) and suggests the iterator syntax.
thanks!
is this in the right direction?
Change:
} } <ins> #[stable(feature = "encode_wide_fused_iterator", since = "1.62.0")] impl FusedIterator for EncodeWide<'_> {} </ins> impl Hash for CodePoint { #[inline] fn hash<H: Hasher>(&self, state: &mut H) {

Discussion:
iterates over (which point to a slice of bytes in memory). When the code points expire (no more bytes available in the slice), there is no chance of the iterator ever returning more values. Therefore, should implement . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It is currently fused in practice and I don't think there's a good reason to change that in the future. This would technically be an API change but one that should have no negative impact to existing code. Which is the long winded way of saying I agree.
Thanks for the quick response! I realize that this is an API change but didn't feel it'd warrant a "feature suggestion". I guess for now I'm just throwing the idea out there.
This is a great idea and I'd be happy to see a PR that implements it. I was just ticking off a checklist. It's not a breaking change and it is useful, so implementing it should not be at all controversial.
Sounds good, I'll get to it tomorrow! claim
Note that, procedurally, a new trait impl is insta-stable so will need a FCP. (That's totally ok, just wanted to note it. You can and should send a PR for it.)
Change:
if let Some(entry) = LINKCHECK_EXCEPTIONS.iter().find(|&(f, _)| file.ends_with(f)) { entry.1.contains(&link) } else { <ins> // FIXME(#63351): Concat trait in alloc/slice reexported in primitive page // // NOTE: This cannot be added to `LINKCHECK_EXCEPTIONS` because the resolved path // calculated in `check` function is outside `build/<triple>/doc` dir. // So the `strip_prefix` method just returns the old absolute broken path. if file.ends_with("std/primitive.slice.html") { if link.ends_with("primitive.slice.html") { return true; } } </ins> false } }

Discussion:
Missing Implementors for [][1] trait. Current output: ! While rustdoc displays [][2] trait implementors. Expected: Display Implementors for Join trait: : 1.47.0-nightly ( 2020-08-15) [1]: [2]: modify labels: T-rustdoc
This is a regression from stable-to-nightly: and beta one has Implementors section. cc
It has made it way to beta. Pattern trait is also affected: modify labels: I-prioritize
(Btw I think you can use as a shorthand)
The Borrow trait still has , I am not sure if this bug affect crates in ecosystem.
So I think this bug shouldn't affect stable traits, just most unstable traits I saw are affected.
There is high change that causing the regression, but I cannot prove that.
This is more likely to be than the refactor I think.
Yeah, I suspect that given it might make sense to revert anyway, since it doesn't actually accomplish the goal. Or someone more experienced with rustdoc may be able to suggest/implement a better patch.
New discovery: So far only trait exported to std affected. For example with Join trait, in alloc it is normal:
Oh right, I have MCVE, it needs two dummy crates. <details<summarydummy crate "unstabled"</summary</detailsCrate to run : modify labels: -E-needs-mcve
searched nightlies: from nightly-2020-06-04 to nightly-2020-07-17 regressed nightly: nightly-2020-07-17 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
That rollup includes both and ; of the two I think is the more likely culprit.
Marking as P-high .

appears on the current nightly's, even though it's not part of the (public) standard libraries. This appears to be , so maybe related to , cc Noticed by (assuming they use the same handle here and discord, if not, sorry :flushed:)
Relevant PRs (backtrace isn't really to blame here): ,
Maybe this should also skip the impl if there is no 'stability' attribute? ,
This is the default for everything not in the standard library. So it seems like the standard library needs special casing here. Maybe as simple as ?
Doesn't gimli get everything marked as unstable behind the rustc_private feature gate through a rustc flag?
MCVE: It doesn't require any external deps, just dummy crates included. The outermost crate is a fake std, realcore is fake core, gimli is fake gimli.
Change:
let impl_item = Impl { impl_item: item }; if impl_item.trait_did().map_or(true, |d| self.cache.traits.contains_key(&d)) { for did in dids { <del> self.cache.impls.entry(did).or_insert_with(Vec::new).push(impl_item.clone()); </del> <ins> if self.impl_ids.entry(did).or_default().insert(impl_item.def_id()) { self.cache .impls .entry(did) .or_insert_with(Vec::new) .push(impl_item.clone()); } </ins> } } else { let trait_did = impl_item.trait_did().expect("no trait did");

Discussion:
! All pointing to the same impl: ! label +T-rustdoc
Actually, the never type , the trait and are not needed: It occurs with any type and any parameterized trait. Minimal reproducible example: The number of duplicates depends on the number of public types accessible in the target crate.
Taking a look.
code: Gives: !
Change:
<ins> // Check that this can be compiled in a reasonable time. // build-pass fn main() { // 96 nested closures let x = (); || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || [&(), &x]; } </ins>

Discussion:
The following takes approximately one year to compile: (This estimate was derived from observing that compile time scales seemingly exponentially in the depth of the instantiated closure. At level 23 it took about 25 seconds, and at 22 only 13. Extrapolating this doubling-per-depth leads us to about a year at level 43 which is depicted above).
Flamegraph:
Yields: cc
Change:
|          while parsing the type for `_` |          help: use `=` if you meant to assign <del> error: aborting due to 1 previous error </del> <ins> error: aborting due to 2 previous errors </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at ', 'thread 'rustc' panicked at ' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: --
cc
Change:
.or_else(|| self.give_name_if_anonymous_region_appears_in_arguments(fr)) .or_else(|| self.give_name_if_anonymous_region_appears_in_upvars(fr)) .or_else(|| self.give_name_if_anonymous_region_appears_in_output(fr)) <del> .or_else(|| self.give_name_if_anonymous_region_appears_in_yield_ty(fr)); </del> <ins> .or_else(|| self.give_name_if_anonymous_region_appears_in_yield_ty(fr)) .or_else(|| self.give_name_if_anonymous_region_appears_in_impl_signature(fr)); </ins> if let Some(ref value) = value { self.region_names.try_borrow_mut().unwrap().insert(fr, value.clone());

Discussion:
<details<summary<strongBacktrace</strong</summary<p</p</details
Changing Self{field} to MyStruct{field} makes it build btw.
I haven't done a search for the exact commit, but on the playground this regressed between beta and nightly. label +regression-from-stable-to-nightly
This is due to the NLL stabilization PR , since it manifests with on 1.61 (with to allow feature flags). I'll be looking at it in a few hours when I get home!
Change:
<ins> // run-rustfix #![allow(dead_code)] struct A { b: B, } enum B { Fst, Snd, } union Foo { bar: u32, qux: f32, } fn main() { let a = A { b: B::Fst }; if let B::Fst = a {}; //~ ERROR mismatched types [E0308] //~^ HELP you might have meant to use field `b` of type `B` match a { //~^ HELP you might have meant to use field `b` of type `B` //~| HELP you might have meant to use field `b` of type `B` B::Fst => (), //~ ERROR mismatched types [E0308] B::Snd => (), //~ ERROR mismatched types [E0308] } let foo = Foo { bar: 42 }; match foo { //~^ HELP you might have meant to use field `bar` of type `u32` 1u32 => (), //~ ERROR mismatched types [E0308] _ => (), } } </ins>

Discussion:
Just encountered the following output: It would be nice if we could peek at the fields of and provide an appropriate structured suggestion: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim