jiebi/CodeConvo huggingface dataset:
Change:
let my_out = match mode { // This is the intended out directory for compiler documentation. Mode::Rustc | Mode::ToolRustc => self.compiler_doc_out(target), <del> Mode::Std => out_dir.join(target.triple).join("doc"), </del> <ins> Mode::Std => { if self.config.cmd.json() { out_dir.join(target.triple).join("json-doc") } else { out_dir.join(target.triple).join("doc") } } </ins> _ => panic!("doc mode {:?} not expected", mode), }; let rustdoc = self.rustdoc(compiler);

Discussion:
I tried this: I expected to see this happen: The second invocation takes essentially no time. Instead, this happened: The docs were completely rebuilt. The problem is that we remove the docs between each invocation: this is a regression from - do you think you'll have time to follow up? I think we can either add a stamp file to avoid rebuilding, or find some other way to avoid removing the whole directory - maybe we can only remove/copy the files, rather than everything? <!-- 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. --HEAD is branched from . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Ok, I confirmed that rustdoc only creates JSON files with --output-format json: So it should be enough to only copy .json files when passed --json, and only non-json files when it's not passed. We should also add a test that produces the same output in json-doc as , to avoid a regression if rustdoc starts emitting JSON files in the default HTML format.
I can't jump on it immediately, but I should be able to follow up in a couple of weeks
claim
We can do this validation for dir, but I am not sure if this is possible for dir since each time json output changes. The layout of json context is getting change even if you don't change anyhing on the source code. I print sha2 sums below to demonstrate the situation. 1st attempt: 2nd attempt right after the first attempt The demonstration is from
thanks for investigating; sounds like we should report that as a separate bug in rustdoc. But for now it's ok if the files don't match exactly as long as the file names are the same between runs.
Change:
<del> // 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. // Test what happens when a HR obligation is applied to an impl with // "outlives" bounds. Currently we're pretty conservative here; this // will probably improve in time. trait Foo<X> { fn foo(&self, x: X) { } } fn want_foo<T>() where T : for<'a> Foo<&'a isize> { } /////////////////////////////////////////////////////////////////////////// // Expressed as a where clause struct SomeStruct<X> { x: X } impl<'a,X> Foo<&'a isize> for SomeStruct<X> where X : 'a { } fn one() { // In fact there is no good reason for this to be an error, but // whatever, I'm mostly concerned it doesn't ICE right now: want_foo::<SomeStruct<usize>>(); //~^ ERROR requirement `for<'a> usize : 'a` is not satisfied } /////////////////////////////////////////////////////////////////////////// // Expressed as shorthand struct AnotherStruct<X> { x: X } impl<'a,X:'a> Foo<&'a isize> for AnotherStruct<X> { } fn two() { want_foo::<AnotherStruct<usize>>(); //~^ ERROR requirement `for<'a> usize : 'a` is not satisfied } fn main() { } </del>

Discussion:
The following code fails to compile despite : The exact error is: Per comment , it seems that could imply .
contains the following comment:
I'd be interested in digging into this if you can give me some advice on how to get started.
hmm, probably best would be to privmsg me on IRC, if that's possible (). It should be fairly easy to write a targeted patch covering cases like , where the bound region only appears on the RHS; doing a more general fix (e.g., one that handles ) would be somewhat harder, though some of the recent refactoring I've been doing would help there.
Change:
error[E0532]: expected tuple struct or tuple variant, found unit variant `E::A` --> $DIR/issue-pr29383.rs:9:14 | <ins> LL |     A, |     - `E::A` defined here ... </ins> LL |         Some(E::A(..)) => {} <del> |              ^^^^ not a tuple struct or tuple variant </del> <ins> |              ^^^^^^^^ help: use this syntax instead: `E::A` </ins> error[E0532]: expected tuple struct or tuple variant, found unit variant `E::B` --> $DIR/issue-pr29383.rs:11:14 | <ins> LL |     B, |     - `E::B` defined here ... </ins> LL |         Some(E::B(..)) => {} <del> |              ^^^^ not a tuple struct or tuple variant </del> <ins> |              ^^^^^^^^ help: use this syntax instead: `E::B` </ins> error: aborting due to 2 previous errors

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. -- The current output is: Ideally the output should look like: I'd like it to say "try to use a unit variant like "FarmAnimal::Cow" instead". For example, here's what happens if you use Tuple syntax instead of Struct syntax: So I'd like the new diagnostic to look something like: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is an example Ferrous Systems uses in our trainings, and some of our participants have tripped over this lack of suggestion here. The compiler DOES provide diagnostics when you use a struct syntax instead of a tuple syntax.
Alternatively the help could suggest a more direct: "Remove the parenthesis here".
claim
I just wanted to mention , and I wanted to thank you personally for implementing this diagnostics improvement so quickly! Let me know if you have a blog or twitter you'd like us to link to (rather than your GH profile).
Hello, linking to my GH profile is fine. I did not know I would contribute to such an interesting learning experience. Anyway thank you for mentioning me in your blog post .
Change:
} let expected_string = fs::read_to_string(&expected_file).unwrap(); if dumped_string != expected_string { <del> print_diff(&expected_string, &dumped_string, 3); </del> <ins> print!("{}", write_diff(&expected_string, &dumped_string, 3)); </ins> panic!( "Actual MIR output differs from expected MIR output {}", expected_file.display()

Discussion:
Note: missing newline after is essential. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I've not been able to reproduce this on the latest nightly, I've bisected it to have been fixed in 2020-07-15 (report used 2020-07-11), probably by ; I've filed with a regression test.
Me neither.
Change:
features: "+m,+a,+f,+d,+c".into(), llvm_abiname: "ilp32d".into(), max_atomic_width: Some(32), <ins> supported_split_debuginfo: Cow::Borrowed(&[SplitDebuginfo::Off]), </ins> ..base::linux_musl::opts() }, }

Discussion:
On riscv64gc linux, split-debuginfo ="unpacked" caused error: A dwo section may not contain relocations. For rust 1.64, this error occurs. For rust <=1.64, cargo didn't pass flag to rustc. For rust 1.64, a segmentation fault happens in rustc. For rust < 1.64, it builds fine I think the behavior of rust < 1.64 is correct. The following steps: caused the following failure: No response Related:
Transferred to rust-lang/rust, since this looks to be a compiler issue.
says that LLVM doesn't support this combination of flags. It's unclear to me whether it's impossible or just not implemented yet, but in the meantime, cargo should probably stop passing -C split-debuginfo to proc-macros? there's some mention of in the upstream issue, I'm not sure how that's related.
The report above doesn't mention proc-macros. It seems to happen for normal binaries. The following seems to fail for me: If split-debuginfo isn't supported on this target, then rustc should report that it isn't supported (Cargo already tests for this). I believe that is defined by the field in the target definition.
I'm getting the same issue with when cross compiling for , it seems to be all values except that causes issues.
Change:
<ins> fn bug<'a>() where [(); { //~ ERROR mismatched types let _: &'a (); //~ ERROR a non-static lifetime is not allowed in a `const` }]: {} 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. --: New backtrace: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailsThis probably is the same as found in , except this hits on stable :)
17 - now ICE's 9 - 1.16 just error normally 6 - 1.8 also produce an ICE (unreachable code in ) 0 - 1.5 just error normally
This is has a similar cause to .
Assigning as and removing .
Since minconstgenerics stabilisation this now requires
Seems it has been fixed (finally) in the latest nightly, marking as
Triage: This still triggers ICE with a debug assertion, see for details.
Is there a known workaround to this ? I'm getting this error with the following:
I think I have found a duplicate. <!-- 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 what I can tell this now works even with debug assertions? marking as needs-test.
Change:
} } <del> fn visit_var_debug_info(&mut self, var_debug_info: &VarDebugInfo<'tcx>) { // Debuginfo can contain field projections, which count as a use of the base local. Skip // debuginfo so that we avoid the storage liveness assertion in that case. self.visit_source_info(&var_debug_info.source_info); } </del> fn visit_operand(&mut self, operand: &Operand<'tcx>, location: Location) { // This check is somewhat expensive, so only run it when -Zvalidate-mir is passed. if self.tcx.sess.opts.debugging_opts.validate_mir {

Discussion:
MIR may contain debuginfo like this after inlining: Here, the field access is treated like a use of the local in MIR visitors (using ), even though it is not an actual use of . Instead, it should be using .
Can you describe where the change needs to be made? The visit method for debuginfo seems to be correct: It shells out to with , and then shells out through some other methods to . isn't getting the PlaceContext that was called with (I guess because the context of a projection is potentially different than that of the local it's projecting), but it seems to do nothing for field accesses: So what part should I change? Thanks!
Looks like the problem is here:
Okay, thank you!
Change:
<ins> // edition:2018 struct Foo(*const u8); unsafe impl Send for Foo {} async fn bar(_: Foo) {} fn assert_send<T: Send>(_: T) {} fn main() { assert_send(async { //~^ ERROR future cannot be sent between threads safely bar(Foo(std::ptr::null())).await; }) } </ins>

Discussion:
The following code was working in nightly-2019-09-05, but no longer works in nightly-2019-10-15. The workaround is not quite intuitive. () Errors: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'm also running into this error using Tide and a DB Pool from Diesel I've managed to get a slightly simpler/different version of the above code - I'd expect this to work because I'd expect the to be finished before the starts (I guess it's similar to how pre-NLL we'd expect function calls in arguments to work but sometimes they wouldn't because existing borrows?) I've managed to track it down to happening somewhere between these - but I'm not sure how to go about figuring this out any further (I've never built the compiler, let alone actually debugged it) This successfully buildsThis fails
This was an intentional change to match the drop order in synchronous code:
This was an intentional change but these errors also look like they are caused by "overapproximation" of the set of captured values. We are working to improve that; separately, we are also working on improving the diagnostics here.
Assigning to myself as this is a case I'd hope to tackle in . It isn't currently handled by that PR, as the current diagnostic improvements only work when the error originates from an , not . claim
I found a similar problem: Is this the same bug?
Unassigning myself since has landed.
adds a compiler message to suggest a workaround for this problem. Is it not possible to make the compiler smarter and not borrow unnecessary variables across ?
rustc is not that smarter yet, we already have an issue tracking this , along with were trying to lint users with "shorten" workaround(might be lifted once the analysis is improved) in these two "common" cases.
It's a matter of having consistent language semantics for async and non-async code. The lang team discussed this and decided the drop order should be consistent (i.e. we shouldn't drop temporaries until the end of the statement, even if the statement contains ).
Change:
} } <ins> fn reject_shadowing_type_parameters<'tcx>(tcx: &ty::ctxt<'tcx>, span: Span, generics: &ty::Generics<'tcx>) { let impl_params = generics.types.get_slice(subst::TypeSpace).iter() .map(|tp| tp.name).collect::<HashSet<_>>(); for method_param in generics.types.get_slice(subst::FnSpace).iter() { if impl_params.contains(&method_param.name) { tcx.sess.span_err( span, &*format!("type parameter `{}` shadows another type parameter of the same name", token::get_name(method_param.name))); } } } </ins> impl<'ccx, 'tcx, 'v> Visitor<'v> for CheckTypeWellFormedVisitor<'ccx, 'tcx> { fn visit_item(&mut self, i: &ast::Item) { self.check_item_well_formed(i); visit::walk_item(self, i); } <ins> fn visit_fn(&mut self, fk: visit::FnKind<'v>, fd: &'v ast::FnDecl, b: &'v ast::Block, span: Span, id: ast::NodeId) { match fk { visit::FkFnBlock | visit::FkItemFn(..) => {} visit::FkMethod(..) => { match ty::impl_or_trait_item(self.ccx.tcx, local_def(id)) { ty::ImplOrTraitItem::MethodTraitItem(ty_method) => { reject_shadowing_type_parameters(self.ccx.tcx, span, &ty_method.generics) } _ => {} } } } visit::walk_fn(self, fk, fd, b, span) } fn visit_trait_item(&mut self, t: &'v ast::TraitItem) { match t { &ast::TraitItem::ProvidedMethod(_) | &ast::TraitItem::TypeTraitItem(_) => {}, &ast::TraitItem::RequiredMethod(ref method) => { match ty::impl_or_trait_item(self.ccx.tcx, local_def(method.id)) { ty::ImplOrTraitItem::MethodTraitItem(ty_method) => { reject_shadowing_type_parameters( self.ccx.tcx, method.span, &ty_method.generics) } _ => {} } } } visit::walk_trait_item(self, t) } </ins> } pub struct BoundsChecker<'cx,'tcx:'cx> {

Discussion:
cc
It seems like the second part of this (type parameter shadowing) is backwards incompatible, but AFAICT, isn't implemented yet.
I suggest we leave it and go straight for the lint (as we plan to do eventually with the lifetime version). Then no backwards compatibility issues. Also, since type shadowing is allowed in every other language it is going to really surprise people if it is forbidden in Rust. And, it is the shadowed lifetimes which were causing the motivating confusion.
just for future visitors, type parameter shadowing (like the example in the RFC) does, in fact, produce a clear compiler error. The comments above and lack of linked "type parameter shadowing" PRs might otherwise suggest that type parameter shadowing was left as a lint rather than a compiler error.
Change:
} } <del> pub fn parse_nt(p: &mut Parser, name: &str) -> Nonterminal { </del> <ins> pub fn parse_nt(p: &mut Parser, sp: Span, name: &str) -> Nonterminal { </ins> match name { "tt" => { p.quote_depth += 1us; //but in theory, non-quoted tts might be useful

Discussion:
I work on Windows 8.1 64-bit, rustc version: BTW, the same ICE occurred for my but it did not print backtrace with and I don't know why.
Change:
#![feature(in_band_lifetimes)] #![feature(nll)] #![feature(or_patterns)] <del> #![feature(peekable_next_if)] </del> #![feature(test)] #![feature(crate_visibility_modifier)] #![feature(never_type)]

Discussion:
<!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilisation. Make sure to include the relevant RFC for the feature if it has one. Otherwise provide a short summary of the feature and link any relevant PRs or issues, and remove any sections that are not relevant to the feature. Remember to add team labels to the tracking issue. For a language team feature, this would e.g., be . Such a feature should also be labeled with e.g., . This label is used to associate issues (e.g., bugs and design questions) to the feature. --This is a tracking issue for the feature (). The feature gate for the issue is . Tracking issues are used to record the overall progress of implementation. They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label. <!-- Include each step required to complete the feature. Typically this is a PR implementing a feature, followed by a PR that stabilises the feature. However for larger features an implementation could be broken up into multiple PRs. --- [x] Implement the RFC [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide]) [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide]) [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev- <!-- Include any open questions that need to be answered before the feature can be stabilised. --- Should be named or ? Should be named or ?
modify labels: T-libs
I don't think the methods should be renamed to something else, becuase also has a method, and should use the same name but with the component. Also, if these questions are resolved and there are no other blockers, I would like to go ahead and stabilize this feature.
Change:
} pub fn node_is_reachable(&self, id: ast::NodeId) -> bool { <del> self.graph.depth_traverse(self.entry).any(|node| node.id() == id) </del> <ins> self.graph.depth_traverse(self.entry) .any(|idx| self.graph.node_data(idx).id() == id) </ins> } }

Discussion:
Notably, this does not occur with a trait like: This smells like a bug to me, unless a language change introduced special treatment of with regard to lifetimes.
An interesting quirk is that if you replace with just , it compiles fine with the impl.
cc
are you saying this used to work? Just curious what the original was.
(Also it seems difficult if not impossible to satisfy the combination of and ..... well I guess of static would, but I don't know if we can deduce that.
Yes, this used to work. This bug is affecting
It looks like this may have been introduced in . Prior to this, checking for bounds in was done via , which creates a throw-away inference context before calling into trait selection. It now goes through the ; the impl of for uses its own inference context. This causes region constraints introduced during trait selection for to stick around, resulting in a seemingly inappropriate transitive constraint between the free region within the closure body and at the call site of .
hmm good catch, sorry I let this slip through last week :( I'll try to pay it some attention now. The current code does not seem entirely wrong to me, though. I have to think this through a bit.
Change:
pub backtrace_on_ice: bool, // llvm codegen options <ins> pub llvm_skip_rebuild: bool, </ins> pub llvm_assertions: bool, pub llvm_optimize: bool, pub llvm_thin_lto: bool,

Discussion:
The compiler LLVM is rebuilt whenever the built version of LLVM doesn't have the right hash. (Previously it was rebuilt based on a special marker file, which was easier to work around.) However, most of the time, having the latest LLVM version is not necessary, but makes rebuilding rustc after rebasing take significantly longer, which is a pain. It would be good to be able to disable this as an option in for convenience. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
To fix this, you'll want to add another option: you should be able to look at the logic for something like .
It would be good if this could be changed in the config file so you don't have to pass in the option all the time.
if it's a config file option, then there should be an option to rebuild it if necessary. I.e. it shouldn't be necessarily to temporarily change the to rebuild.
sure that seems good, although they can be implemented separately.
The line you would need to change is near this one: (line 735 of ) It would probably be much easier to add a check against a key in the config, than to add a new flag.
claim
Error: Parsing assign command in failed: claim ... Please let know if you're having trouble with this bot.
, my bad! claim EDIT: oh dear, I'm making it worse
are you still working on this? I wouldn't mind picking it up if not. (Sorry - not really sure what the etiquette is re: dormant tickets!)
Just saw that PR () lapsed. I'm gonna claim this, if that's okay. Will work on something based on the existing comments there. claim
Thank you for picking this up! Getting things fixed is the important thing, and I'm sure I'll find something else to fix in the near future when I have more time