jiebi/CodeConvo huggingface dataset:
Change:
|      first use of `T` error[E0207]: the type parameter `T` is not constrained by the impl trait, self type, or predicates <del> --> $DIR/duplicate-type-parameter.rs:24:6 </del> <ins> --> $DIR/duplicate-type-parameter.rs:24:8 </ins> | LL | impl<T,T> Qux<T,T> for Option<T> {} <del> |      ^ unconstrained type parameter </del> <ins> |        ^ unconstrained type parameter </ins> error: aborting due to 8 previous errors

Discussion:
Found with a <details<summaryFull output including backtrace</summary</detailsRegression in nightly-2021-04-26, possibly from ( label +A-const-generics
Here's a simpler case that ICEs in a similar way. It ICEd at least as far back as nightly-2018-01-01 (with the keyword removed for older versions). Output: <details<summaryFull output</summary</details
A similar thing was fixed a week ago in but maybe a more general fix is needed.
This fix probably needs to go into the resolver -- Using to distinguish the identifers in the example: I think the issue is that is resolving to , instead of , so when we do the partial substitution of default const params, we end up trying to look for while is being created.
Similar ICE with struct instead of impl trait:
This would be inconsistent with how lifetimes work. You can have . I suggest a check in astconv, replacing the self-referential type/const by error type/const.
Change:
"if_chain", "itertools 0.9.0", "lazy_static 1.4.0", <del> "pulldown-cmark 0.7.0", </del> <ins> "pulldown-cmark 0.7.1", </ins> "quine-mc_cluskey", "regex-syntax", "semver",

Discussion:
If I run cargo doc on the below code, it never finishes. I expected to see it finish. Problem does not exist on stable
cc
Fixed upstream in , but not released yet.
Let's hope next version will be released soon then! :)
Unfortunately this also affects 1.43 beta.
Hm so this will hit stable in less than a week then. Do we consider it high priority enough to try to push through a release ourselves? (e.g. we can temporarily fork or whatever, perhaps only on the beta branch). I personally lean towards no but wouldn't be opposed to doing so if t-rustdoc wanted to.
This issue halted development at our company for a day until we bisected the issue down to the particular line of code (a comment) that was causing to hang indefinitely. Thank you for all of your hard work on Rust. It is my most favourite language. I've been waiting for a suitable replacement for C++, and it has arrived!
Looks like there's movement on a point release, I would be in favor of backporting this to beta, since it's a really painful bug to hit...
0.7.1 has been released.
Yea, PR to update is up at .
Change:
<ins> // aux-build:issue-73112.rs extern crate issue_73112; fn main() { use issue_73112::PageTable; #[repr(C, packed)] struct SomeStruct { //~^ ERROR packed type cannot transitively contain a `#[repr(align)]` type [E0588] page_table: PageTable, } } </ins>

Discussion:
I was writing some code that does some x86 page table configuration, but then I noticed that Rust compiler started to panic with this code: And I did realize that I cannot use in since has attribute. If I rewrite the above code without crate: (Note that this is basically same thing as 's struct) This compiler error is displayed, which is normal: And here's output from (In this case, I'm trying to compile the first code): Looking at the backtrace, there's function and : While there's no line number(since the compiler is installed using ), thankfully there are only two calls to inside . And it seems like the first one is panicking since normal output has nothing more than , but I might be wrong. I ran about five minutes ago before submitting this issue, but result was the same. BTW: I initially found this bug in Clippy, but then I noticed that Rustc was doing the same thing.
Assigning [as discussed as part of the Prioritization WG procedure][link]. [link]: https://rust-(in.20some.20cases).20when.20repr(al
Would you please try this again for us?
The second one is one that does not panic rustc(The code that panics rustc is the first one). It is very similar to the first one except that it does not use external crate, and compiling it shows the error I was expecting. Also, the second code was one of my attempts to reproduce the same panic without external crate, but for some reason, it didn't panic the compiler. Only the first code does.
Change:
/// /// Deliberately don't inline the main sorting routine entrypoint to ensure the /// inlined insertion sort i-cache footprint remains minimal. <del> #[cfg(not(feature = "optimize_for_size"))] </del> <ins> #[cfg(not(any(feature = "optimize_for_size", target_pointer_width = "16")))] </ins> #[inline(never)] fn driftsort_main<T, F: FnMut(&T, &T) -> bool, BufT: BufGuard<T>>(v: &mut [T], is_less: &mut F) { // By allocating n elements of memory we can ensure the entire input can

Discussion:
Run Or And you'll get this diagnostic (cargo miri setup makes it a warning, lol): I don't know what effect this has at runtime but it can't be good.
It's worse than one might think, because many AVR microarchitectures, including the atmega328 we nominally support, have only 2KiB of SRAM, which means that this line is literally impossible:
these targets should probably use some of the code in with perhaps a few more tweaks.
Good to know, 16-bit wasn't something we had in mind during development, in terms of less standard targets, we did test big endian with miri. I agree with the code in would be a better fit for such targets. What kind of tweaks did you have in mind?
There are other places in driftsort and ipnsort that use stack arrays, e.g: They are all size bound to <= 4KiB through various means, but still a poor fit for tiny chips.
I think that's necessary, I don't believe driftsort could ever meaningfully run on machines this small.
You already figured it out: dropping all the stack arrays to the absolute minimum. Note that you are not obligated to fix these targets, as usual.
I think it should be a single additional in the impl, so I don't mind doing it.
Yeah, we'd get CI failures way too often if we errored on warnings for tier 3 targets.
Related:
Who is using Tier 3 targets in CI?
Miri is, by running a test with . We should probably change that.
Thinking a bit more about it, is there any scenario where you'd compile Rust for 16-bit targets and don't want to use ? Independent of sort. I'd think that such targets are always binary-size limited and welcome any reduction of it.
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() { enum Foo { FooB { x: i32, y: i32 } } let f = FooB { x: 3, y: 4 }; match f { FooB(a, b) => println!("{} {}", a, b), //~^ ERROR `FooB` does not name a non-struct variant or a tuple struct } } </ins>

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:
} &Ok(None) => {} &Err(SelectionError::Unimplemented) => { <del> if self.is_of_param(pred.skip_binder().trait_ref.substs) { </del> <ins> if self.is_param_no_infer(pred.skip_binder().trait_ref.substs) { </ins> already_visited.remove(&pred); self.add_user_pred( &mut user_computed_preds,

Discussion:
When I tried to build docs for , I got a panic. Here is the reduced test case: With the above code, when I run I get this panic: rustc 1.27.0-nightly ( 2018-04-18) binary: rustc commit-hash: commit-date: 2018-04-18 host: x86_64-pc-windows-msvc release: 1.27.0-nightly LLVM version: 6.0
Strange... Will take a look as soon as possible.
So the call is performed . I'll need help from (or anyone in the team who knows about the type) in order to fix this issue.
Reduced further:
I'd like to work on this.
Thank you so much! I verified that with the latest Rust Nightly I no longer get any errors.
Change:
resolve_module_only = visibility must resolve to a module <ins> resolve_macro_expected_found = expected {$expected}, found {$found} `{$macro_path}` resolve_remove_surrounding_derive = remove from the surrounding `derive()` resolve_add_as_non_derive = add as non-Derive macro `#[{$macro_path}]` </ins>

Discussion:
(The actual desired output should have colours and minuses on the removed derive, but to give the idea) Many users are not familiar with the terminology being used by the compiler error (i.e. the different flavours of procedural macro, derive vs attribute) and might be confused as to what they need to do in order to fix the error. Since the fix is straight-forward (i.e. remove the ), the compiler should show a code snippet that fixes the issue. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I have a partially functional implementation of this, though I've run into a bit of trouble, some guidance would be appreciated. Currently I'm implementing this next to the existing error in in . My trouble comes with knowing what the macro is invoked on, (function, struct), and sending the help message selectively based on that. Is there a way to get this information in , or is my approach wrong and the error should be elsewhere? As far as I can tell I am trying to implement this in a place before the AST is fully parsed, so this may be unviable
Change:
{ self.base.retain(f) } <ins> /// Creates a consuming iterator visiting all the keys in arbitrary order. /// The map cannot be used after calling this. /// The iterator element type is `K`. /// /// # Examples /// /// ``` /// #![feature(map_into_keys_values)] /// use std::collections::HashMap; /// /// let mut map = HashMap::new(); /// map.insert("a", 1); /// map.insert("b", 2); /// map.insert("c", 3); /// /// let vec: Vec<&str> = map.into_keys().collect(); /// ``` #[inline] #[unstable(feature = "map_into_keys_values", issue = "75294")] pub fn into_keys(self) -> IntoKeys<K, V> { IntoKeys { inner: self.into_iter() } } /// Creates a consuming iterator visiting all the values in arbitrary order. /// The map cannot be used after calling this. /// The iterator element type is `V`. /// /// # Examples /// /// ``` /// #![feature(map_into_keys_values)] /// use std::collections::HashMap; /// /// let mut map = HashMap::new(); /// map.insert("a", 1); /// map.insert("b", 2); /// map.insert("c", 3); /// /// let vec: Vec<i32> = map.into_values().collect(); /// ``` #[inline] #[unstable(feature = "map_into_keys_values", issue = "75294")] pub fn into_values(self) -> IntoValues<K, V> { IntoValues { inner: self.into_iter() } } </ins> } impl<K, V, S> HashMap<K, V, S>

Discussion:
Associative maps ( and ) in Rust are currently missing two methods to get owning iterators to their keys or values. We have to get key-value reference pairs, to get key-value mutable reference pairs and to get owned key-value pairs. I'd expect and to offer a similar trio of methods (with an exception for of course). is there, but the variants are missing for seemingly no good reason. As an example implementation (but perhaps we can do better):
I would accept a PR to introduce unstable intokeys() and intovalues().
Hi, I’m interested in working on this but I have a question regarding the implementation. I guess we can implement this in two ways. First one is implementing like the example in the first comment, like returning . And the second option is to return a struct of its own (like a mixture of and / structs) instead of returning . We can name them IntoKeys and IntoValues and they can be responsible of implementing the trait. I feel like performance wise they are same, since map and custom struct both will be evaluated lazily when we iterate over. But there might be a rule to always return a proper type in the rust std code that I don't know. So I think I’m okay implementing either way but wanted to ask just in case. What do you think?
For the public API I would prefer this implemented using dedicated IntoKeys and IntoValues iterator types. They can be implemented internally as wrappers around Map<IntoIter<K, Vif that simplifies things.
Thanks for the answer Created a PR for this and you as a reviewer. Would you mind taking a look at it when you have time?
Change:
-> ConstEvalResult<'tcx> { desc { |tcx| "const-evaluating + checking `{}`", <del> tcx.def_path_str(key.value.instance.def.def_id()) </del> <ins> key.value.display(tcx) </ins> } cache_on_disk_if(_, opt_result) { // Only store results without errors

Discussion:
Evaluating of promoteds currently looks very confusing in the query stack: is not a const, so "const-evaluating " is just nonsense. I presume that this is easy to fix but only would know how. ;) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Also see
Let's give a try :wink:
claim
awesome. :) Let us know if you need any help. I am not very familiar with that specific code, but can still help with more general questions, and I hope can help with the specifics. :D
Change:
//   |  __________ //   | |    | //   | | <del> // 3 | </del> <ins> // 3 | | </ins> // 4 | | } //   | |_ for &(pos, annotation) in &annotations_position {

Discussion:
In we account for the visible char width when calculating the label and span positions, but we do not do so for the vertical bar tying them together, causing the following output: where it should be (Found during )
I would like to solve this as a first time issue. Best with some pointers where to start :)
the code that draws the vertical lines is at and the one that draws the span labels is right below I think the error might be using instead of , but I'm not entirely certain. If this is your first time compiling , you probably want to read the , but the TL;DR: is "run to build the compiler up to the first stage and update the test output files". You might also want to wait until the linked PR is merged so you have a test case, unless you wish to come up with a new one (look for a test that has multiple labels in the same span and pad the source to the left with unicode chars on non-1 width).
Thank you! I did read the rustc guide, and even compiled it on my own once. But thanks for the direction, and the note to the PR. I'll do my best :wink:
Change:
logfile: config.logfile.clone(), run_tests: true, bench_benchmarks: true, <del> nocapture: match env::var("RUST_TEST_NOCAPTURE") { Ok(val) => &val != "0", Err(_) => false, }, </del> <ins> nocapture: config.nocapture, </ins> color: config.color, shuffle: false, shuffle_seed: None,

Discussion:
passes fails On recent master (commit ), with to avoid building LLVM: Extra spin/Side note: Contrary to the above, with , both and pass well: and . All the same when invoking with instead of . Also discussed at https://rust- <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think is not actually passing through to libtest, it's just acting as a filter on the tests (like would). looks like today the only way to configure this is through an env variable: changing that to accept seems useful
claim
Wow. Thank you.
Change:
<ins> // This test checks that we don't lint values defined by a custom target (target json) // // check-pass // needs-llvm-components: x86 // compile-flags: --crate-type=lib --check-cfg=values() --target={{src-base}}/check-cfg/my-awesome-platform.json -Z unstable-options #![feature(lang_items, no_core, auto_traits)] #![no_core] #[lang = "sized"] trait Sized {} #[cfg(target_os = "linuz")] //~^ WARNING unexpected `cfg` condition value fn target_os_linux_misspell() {} #[cfg(target_os = "linux")] fn target_os_linux() {} #[cfg(target_os = "ericos")] fn target_os_ericos() {} </ins>

Discussion:
doesn't seem to know that custom targets can extend the set of values. The following creates a custom spec with a . No warning Got the warning: cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Change:
LL | fn f2<'a>(x: u8, y: Vec<&'a ...>) {} |                             ^^^ <ins> error[E0743]: C-variadic type `...` may not be nested inside another type --> $DIR/variadic-ffi-nested-syntactic-fail.rs:8:21 | LL | fn f3() where for<> ...: {} |                     ^^^ </ins> error[E0308]: mismatched types <del> --> $DIR/variadic-ffi-nested-syntactic-fail.rs:8:33 </del> <ins> --> $DIR/variadic-ffi-nested-syntactic-fail.rs:12:33 </ins> | LL |     let _recovery_witness: () = 0; |                            --   ^ expected `()`, found integer |                            | |                            expected due to this <del> error: aborting due to 3 previous errors </del> <ins> error: aborting due to 4 previous errors </ins> Some errors have detailed explanations: E0308, E0743. For more information about an error, try `rustc --explain E0308`.

Discussion:
<!-- [31mICE[0m: Rustc '-Zunstable-options --edition=2024 -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: should have been handled elsewhere', 'error: internal compiler error: should have been handled elsewhere' 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: --
also repros with or with 2015 if you remove the :)
Regression in nightly-2020-12-20 fetching (via remote github) commits from max(, 2020-12-17) to ending github query because we found starting sha: getcommitsbetween returning commits, len: 9 commit[0] 2020-12-18: Auto merge of - ehuss:update-cargo, r=Mark-Simulacrum commit[1] 2020-12-18: Auto merge of - GuillaumeGomez:str-to-symbol, r=jyn514 commit[2] 2020-12-19: Auto merge of - mibac138:fn-fat-arrow-return, r=davidtwco commit[3] 2020-12-19: Auto merge of - davidtwco:issue--const-param-attrs, r=lcnr commit[4] 2020-12-19: Auto merge of - JohnTitor:rollup-a31s996, r=JohnTitor commit[5] 2020-12-19: Auto merge of - jackh726:binder-refactor-part-2, r=lcnr commit[6] 2020-12-19: Auto merge of - CDirkx:ipaddr-const, r=oli-obk commit[7] 2020-12-19: Auto merge of - matthewjasper:revert-eval-order, r=nikomatsakis commit[8] 2020-12-19: Auto merge of - Nadrieril:usefulness-merging, r=varkor
This is also kinda bad because rustc does not tell you what you did wrong (theres no error shown) mvce:
very likely
Change:
<ins> // https://github.com/rust-lang/rust/issues/84434 // check-pass use std::path::Path; struct A { pub func: fn(check: bool, a: &Path, b: Option<&Path>), } const MY_A: A = A { func: |check, a, b| { if check { let _ = (); } else if let Some(parent) = b.and_then(|p| p.parent()) { let _ = (); } }, }; fn main() {} </ins>

Discussion:
I got this error on my code even though it did not have any in it. Also, it seems to only happen on crates. Just a is enough to reproduce it. rust playground: The bug also happens on and versions of the compiler. : <!-- 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 --
Oh, I think it's worth noting that if the code is refatored as: The bug ceases to happen.
I think duplicated of ?
this one doesn't need nightly to trigger
The code in works for me
right, because it's a different problem and only triggers with .
The issue seems to be that the gets desugared to a , which is currently unexpected in an branch. claim
Change:
drop(obligations); debug!( <del> "invoking predicate_may_hold: {:?}", trait_ref, </del> <ins> "invoking predicate_may_hold: param_env={:?}, trait_ref={:?}, ty={:?}", param_env, trait_ref, ty </ins> ); let may_apply = match infcx.evaluate_obligation( &traits::Obligation::new(

Discussion:
When using the nightly with the bugfix for the problems with , this error happens when trying to document the crate: note: rustc 1.31.0-nightly ( 2018-10-01) running on x86_64-apple-darwin
cc: FYI
it seemed to document fine for me on the most recent nightly build
This is fixed as of
Closing then! Thanks! :D
Will this need backporting at all?
Change:
); if tcx.dep_graph.try_mark_green(tcx, &dep_node).is_some() { <del> // We can re-use either the pre- or the post-thinlto state if tcx.sess.lto() != Lto::No { CguReuse::PreLto } else { CguReuse::PostLto } </del> <ins> // We can re-use either the pre- or the post-thinlto state. If no LTO is // being performed then we can use post-LTO artifacts, otherwise we must // reuse pre-LTO artifacts match compute_per_cgu_lto_type( &tcx.sess.lto(), &tcx.sess.opts, &tcx.sess.crate_types.borrow(), ModuleKind::Regular, ) { ComputedLtoType::No => CguReuse::PostLto, _ => CguReuse::PreLto, } </ins> } else { CguReuse::No }

Discussion:
First compile is ok, after I modify some contents. It failed. I've to . Then works.
I don't know how to setup a minimal env to reproduce this. But I'd love to provide any info you needed.
cc Is this maybe related to ? (Although this sounds like the opposite of that, where it is missing the bit code.)
Some digging shows that this is a preexisting bug in rustc: I believe that this is only showing up now because Cargo is only just now passing
I've posted a fix for this at
Change:
SubItem(ast::NodeId), Expr(&'a ast::Expr), Pat(&'a ast::Pat), <ins> Crate(&'a ast::Crate), </ins> } pub trait PpAnn {

Discussion:
E.g. becomes Specifically, the syntax contexts of and are linked (the s refer to the same identifier, even with hygiene) but this is not represented in the output at all, so one might interpret them as being distinct identifiers.
There is no more pretty=hygene, was it replaced with something?
Closing. is apparently no longer a thing, and the output looks sufficiently different with that I don't think it's the same.
There is a FIXME related to this issue, Now that the issue is closed can the FIXME be fix, or made more specific?
Looks like is a thing though so reopening... output today is below. I'm not completely sure whether this is fixed or not --- the output looks the same for the two s, I guess? Not sure which are being referred to either...
Change:
// In the table-ish view on the module index, the name should not be wrapped more than necessary. go-to: "file://" + |DOC_PATH| + "/lib2/too_long/index.html" <del> assert-property: (".item-table .struct", {"offsetWidth": "684"}) </del> <ins> // We'll ensure that items with short documentation have the same width. store-property: ("//*[@class='item-table']//*[@class='struct']/..", {"offsetWidth": offset_width}) assert: |offset_width| == "277" assert-property: ("//*[@class='item-table']//*[@class='constant']/..", {"offsetWidth": |offset_width|}) </ins> // We now make the same check on type declaration... go-to: "file://" + |DOC_PATH| + "/lib2/too_long/type.ReallyLongTypeNameLongLongLong.html"

Discussion:
Crates with long type names result in a strange-looking error, see ! I've tested this on Chrome and Firefox, and by building the docs locally from I believe the text is rendering vertically due to long type names like which are auto-generated from OpenAPI. Link to original issue <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The issue is related to the rule which prevents breaking anywhere in the type name. Unfortunately using breaks . We even have a comment about the weird behaviour in the code, not sure how to fix this.
claim