jiebi/CodeConvo huggingface dataset:
Code change:
}).is_some(); render_deref_methods(w, cx, impl_, containing_item, has_deref_mut)?; } <del> write!(w, "<h2 id='implementations'>Trait  Implementations</h2>")?; </del> <ins> write!(w, " <h2 id='implementations' class='section-header'> <a href='#implementations'>Trait Implementations</a> </h2> ")?; </ins> for i in &traits { let did = i.trait_did().unwrap(); let assoc_link = AssocItemLink::GotoSource(did, &i.inner_impl().provided_trait_methods);

Related discussion:
text: A page like has many things that could be useful to link to. These should be possible to link to by clicking on: [x] The header [x] 's on a page. [x] at the top On it's hit or miss: [x] Examples [x] Associated Types [x] Required Methods [x] Implementors On [x] Provided Methods I don't have any big use cases but when I want to link to these for something like this bug I can't link to any specific line. I gotta say go to vec page, scroll 75% to bottom. Squint hard to see it.
Just ran into this today; I'd really like to have links from the impls in the Implementors section to the source containing the impl.
Triage: we always need more links....
Update: Headers written in docs and (most) auto-generated headers are either fully hyperlinked or have a "section marker" symbol that shows up on hover. Major auto-generated page headers have links in the top of the sidebar of the page. Impl blocks do not have hyperlinks (yet); that's
Since got merged and closed out , that was the last major request on this issue, so i'll close this out. If you think of something else that needs a hyperlinked header, feel free to open a new issue or reopen this one.
Code change:
let externs = options.externs.clone(); let render_options = options.render_options.clone(); let scrape_examples_options = options.scrape_examples_options.clone(); <ins> let document_private = options.render_options.document_private; </ins> let config = core::create_config(options); interface::create_compiler_and_run(config, |compiler| {

Related discussion:
text: The ICE appears with and , but not . Beta: <details<summary<strongBacktrace</strong</summary<p</p</details
this is a regression affecting the release that is being prepared today.
I'll take a look.
Code change:
<ins> PRINT-ATTR INPUT (DISPLAY): fn foo < T > () where T : Copy + { } PRINT-ATTR INPUT (DEBUG): TokenStream [ Ident { ident: "fn", span: $DIR/trailing-plus.rs:11:1: 11:3 (#0), }, Ident { ident: "foo", span: $DIR/trailing-plus.rs:11:4: 11:7 (#0), }, Punct { ch: '<', spacing: Alone, span: $DIR/trailing-plus.rs:11:7: 11:8 (#0), }, Ident { ident: "T", span: $DIR/trailing-plus.rs:11:8: 11:9 (#0), }, Punct { ch: '>', spacing: Alone, span: $DIR/trailing-plus.rs:11:9: 11:10 (#0), }, Group { delimiter: Parenthesis, stream: TokenStream [], span: $DIR/trailing-plus.rs:11:10: 11:12 (#0), }, Ident { ident: "where", span: $DIR/trailing-plus.rs:11:13: 11:18 (#0), }, Ident { ident: "T", span: $DIR/trailing-plus.rs:11:19: 11:20 (#0), }, Punct { ch: ':', spacing: Alone, span: $DIR/trailing-plus.rs:11:20: 11:21 (#0), }, Ident { ident: "Copy", span: $DIR/trailing-plus.rs:11:22: 11:26 (#0), }, Punct { ch: '+', spacing: Alone, span: $DIR/trailing-plus.rs:11:27: 11:28 (#0), }, Group { delimiter: Brace, stream: TokenStream [], span: $DIR/trailing-plus.rs:11:29: 12:2 (#0), }, ] </ins>

Related discussion:
text: The following code: is currently pretty-printed as: If this occurs in a macro invocation, it leads to an instance of
Extra info (but it boils down to what said): Using I get the following log: Rendered diff:
This applies to all trailing separators in theory (except that the separator is leading rather than trailing in this case), but in other cases the difference is fixed up by fuzzy comparison in .
Code change:
} #[test] <del> #[cfg_attr(any(target_os = "vxworks", target_os = "android"), ignore)] </del> <ins> #[cfg_attr(any(target_os = "vxworks"), ignore)] </ins> fn exit_reported_right() { let p = if cfg!(target_os = "windows") { Command::new("cmd").args(&["/C", "exit 1"]).spawn() } else { <del> Command::new("false").spawn() </del> <ins> shell_cmd().arg("-c").arg("false").spawn() </ins> }; assert!(p.is_ok()); let mut p = p.unwrap();

Related discussion:
text: To enable test on android bot and test/run-pass/rtio- It looks to me RtioProcess does not work properly on android.
logs are
Hm this may be an FFI issue with libuv. I realized during my uv rewrite that libuv is giving us an int64t exit status and we think it's a cint. Once lands this may be fixed.
Hmm, this issue number has propagated to several more tests that are cfg-disabled on android. (Some of which are now failing when I mixed in a Boehm/BDW conservative GC into the runtime, in particular .)
Also, has landed, so it would be good to determine if these tests now work on Android.
Triage: I have no idea how to test this, but a lot has changed in a year (especially the removal of green & libuv), so these may be magically fixed; if someone can check.
Triage: is gone, but all these tests in are still ignored for android.
I tried to run these tests with but they all failed with , which seems suspect (at least for the tests that invoke , , , etc.). Is there a better way to test? I have an android device available.
Code change:
is_valid = false; } <del> sym::hidden if !self.check_doc_hidden(attr, meta_index, meta, hir_id, target, ) => { is_valid = false; } </del> // no_default_passes: deprecated // passes: deprecated // plugins: removed, but rustdoc warns about it itself

Related discussion:
text: The warning by claims that on an impl item is ignored by rustdoc, but it isn't necessarily. The warning says: which is not true in the following repro: This warning is a false positive. Rustdoc does pay attention to this attribute. For the code above, the rendered documentation of and looks like: <table<tr<td<img src="https://user-" height="185"</td<td<img src="https://user-" height="300"</td</tr</tableAfter removing the supposedly unused attribute and rendering again, the "nasty uninteresting type" that we wanted not shown is going to get rendered on both pages: <table<tr<td<img src="https://user-" height="185"</td<td<img src="https://user-" height="300"</td</tr</table( : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
My bad, I did not notice that at all . I can adjust the lint once it's decided how we are going to proceed with my changes in general (see / blocked on ). claim
In summary, on methods in trait impl blocks does not lead to any visual changes in the documentation whereas on associated types and constants, it hides the implementation (or “the thing to the right of the ”). This weirdly deviates from my (former) personal mental model of how is supposed to work and be used. As far as I know, in all other cases, it leads to items, impl blocks, fields (“names” or “declarations”) not being shown. Here, however, the “name” keeps being shown, only the “value” is hidden. Hiding an inherent assoc item for example, hides the item completely. “Hiding” a trait impl item is, in my opinion, currently handled inconsistently by rustdoc and shouldn't lead to any visual changes (or rather “shouldn't be allowed”). Out of curiosity, @ dtolnay, how / why do you use this feature? Do you use it to reduce visual clutter? Edit: Ah, well, I overlooked the top right picture. So in some cases the item is indeed entirely hidden, not just the value.
Should I remove the lint entirely or should I adjust ?
Code change:
is_valid = false; } <del> sym::hidden if !self.check_doc_hidden(attr, meta_index, meta, hir_id, target, ) => { is_valid = false; } </del> // no_default_passes: deprecated // passes: deprecated // plugins: removed, but rustdoc warns about it itself

Related discussion:
text: Just wanted to add that this is also affecting , but in a different way: <img width="500" src="https://user-"The isn't there at all without the : <img width="500" src="https://user-"Based on the above, this isn't correct: it actually hides the entire thing, at least for associated constants.
In your case, it's inherent associated items being accidentally flagged which is which was meaning the most recent nightly should not have your issue anymore. Sorry for the inconvenience. The longer I look this lint, the less I like it.
Code change:
if let Ok(snippet) = self.infcx.tcx.sess.source_map().span_to_snippet(span) { let is_option = move_ty.starts_with("std::option::Option"); let is_result = move_ty.starts_with("std::result::Result"); <del> if is_option || is_result { </del> <ins> if (is_option || is_result) && use_spans.map_or(true, |v| !v.for_closure()) { </ins> err.span_suggestion( span, &format!("consider borrowing the `{}`'s content", if is_option {

Related discussion:
text: gives the error: Error0507 gives a wrong suggestion here:
Error: Label D-invalid-suggestion can only be set by Rust team members Please let know if you're having trouble with this bot.
modify labels: A-suggestion-diagnostics C-bug T-compiler
Code change:
<ins> // test for `doc(hidden)` with impl parameters in the same crate. #![crate_name = "foo"] #[doc(hidden)] pub enum HiddenType {} #[doc(hidden)] pub trait HiddenTrait {} pub enum MyLibType {} // @!has foo/enum.MyLibType.html '//*[@id="impl-From%3CHiddenType%3E"]' 'impl From<HiddenType> for MyLibType' impl From<HiddenType> for MyLibType { fn from(it: HiddenType) -> MyLibType { match it {} } } pub struct T<T>(T); // @!has foo/enum.MyLibType.html '//*[@id="impl-From%3CT%3CT%3CT%3CT%3CHiddenType%3E%3E%3E%3E%3E"]' 'impl From<T<T<T<T<HiddenType>>>>> for MyLibType' impl From<T<T<T<T<HiddenType>>>>> for MyLibType { fn from(it: T<T<T<T<HiddenType>>>>) -> MyLibType { todo!() } } // @!has foo/enum.MyLibType.html '//*[@id="impl-HiddenTrait"]' 'impl HiddenTrait for MyLibType' impl HiddenTrait for MyLibType {} // @!has foo/struct.T.html '//*[@id="impl-From%3CMyLibType%3E"]' 'impl From<MyLibType> for T<T<T<T<HiddenType>>>>' impl From<MyLibType> for T<T<T<T<HiddenType>>>> { fn from(it: MyLibType) -> T<T<T<T<HiddenType>>>> { match it {} } } </ins>

Related discussion:
text: Last line yields several occurrences of in the generated file. ## Expected behavior No occurrences of anywhere since it was label C-bug T-rustdoc cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I expect the fix is to check for just after
claim
cc I checked for doc(hidden) like this: But it doesn't seem to work, as my test would fail. I also tried using the same way to check for but it also failed. I noticed that the issue involves so I might need to iterate over generic parameters, I cannot find any function that does that in , so can someone point me in the right direction? Thanks :)
You can look at how the pass works:
am I right in understanding this only happens for cross-crate traits, and impls for hidden traits in the same crate are still hidden? In other words, just makes the cross-crate case consistent?
I believe so, yes: the pass was already taking care of such cases for local types. FWIW, the thing that motivated this discussion was noticing a leaking on the docs for , but not on the ones for
Code change:
return; } <ins> if !ensure_stage1_toolchain_placeholder_exists(stage_path) { println!( "Failed to create a template for stage 1 toolchain or confirm that it already exists" ); return; } </ins> if try_link_toolchain(&stage_path[..]) { println!( "Added `stage1` rustup toolchain; try `cargo +stage1 build` on a separate rust project to run a newly-built toolchain"

Related discussion:
text: I tried this code on a fresh git clone of rust-lang/rust: I expected to see this happen: setup works without errors. Instead, this happened: x.py gives an error: This feature was introduced in and worked at that time. do you have time to look into this? The original bug report was from Nazar Mokrynskyi , not sure their github username. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Yes, I'll take a look over the next few days.
Hello. Is there a workaround for this issue for now? I got But when I ran , I got .
OK. After reading the zulip thread, I figured out how to work around it. After running , succeeded.
claim
Code change:
legacy_imports: LegacyMacroImports, allow_shadowing: bool) { let import_macro = |this: &mut Self, name, ext: Rc<_>, span| { <ins> this.used_crates.insert(module.def_id().unwrap().krate); </ins> if let SyntaxExtension::NormalTT(..) = *ext { this.macro_names.insert(name); }

Related discussion:
text: When on latest rust nightly , you get an ICE when compiling .
Its a pretty recent regression, it can't be reproduced with .
Okay, managed to minimize it: Looks like a regression of . cc any ideas on this?
Yeah, this was caused by an oversight in -- fixed in .
Code change:
use crate::mir::*; use crate::ty::subst::SubstsRef; <del> use crate::ty::{CanonicalUserTypeAnnotation, Ty}; </del> <ins> use crate::ty::{self, CanonicalUserTypeAnnotation, Ty}; </ins> use rustc_span::Span; macro_rules! make_mir_visitor {

Related discussion:
text: Originally posted by in , see that PR discussion for more detail <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
are you still looking into this? If so, please reassign yourself
claim
Code change:
self.lookup_and_handle_method(expr.hir_id); } hir::ExprKind::Assign(ref left, ref right, ..) => { <del> // Ignore write to field self.visit_expr(base_expr(left)); </del> <ins> self.handle_assign(left); </ins> self.visit_expr(right); return; }

Related discussion:
text: <!-- 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. --Here's a reduced test-case from Firefox source code: Compiling that program warns with: Which is obviously not true. <!-- 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. --:
Seems like this is a regression from .
cc
Oops, sorry! Technically, field is, in fact, never read. What went wrong is is written and read through other ways. I think restricting the lint to non-reference fields should work, and will submit a PR to do so quickly. Please double check whether my thinking is correct.
Ah, yeah, I somehow thought that the macro was needed to trigger the bug but it is not. That sounds good. Writes to mutable references have side effects so doing that seems ok.
Would that also cover this case here, in the idna crate? (The field is a reference to an type, which is in fact returned to the caller of .)
Yeah, I think it's the same.
Ah, this was closed, but the bug leaked into beta (as mentioned in ) while the fix is only in nightly. Reopening and tagging as stable-to-beta regression
Assigning and removing .
As noted on , we're going to resolve the beta issue by reverting PR on beta (which I have assigned myself to take care of).
This was a regression affecting beta 1.51, closing this.
Code change:
if let Some(ref dir) = build.lldb_python_dir { cmd.arg("--lldb-python-dir").arg(dir); } <ins> let llvm_config = build.llvm_config(target); let llvm_version = output(Command::new(&llvm_config).arg("--version")); cmd.arg("--llvm-version").arg(llvm_version); </ins> cmd.args(&build.flags.args);

Related discussion:
text: I believe this is due to travis using system llvm which misses the fix backported in . cc
Can we do anything about this?
Our best bet is to add a for tests, I think (alternative is to drop support for LLVM pre 3.9, which would be a shame, even if its buggy in certain cases). Implementation of such directive could be implemented by injecting an environment variable or some such (done ) and checking for that in
There's no need to set an extra environment variable, just check if is set (or if you're boring :wink: )
but… but… what if people have on their own systems too?
cc
no we do not have existing infrastructure for this. I'd prefer to avoid as that's not the relevant piece here, but rather something like or . Distros or anyone else building with an older LLVM are likely to hit this and we'd need a solution for them as well. That being said I think it's fine to temporarily disable the test until we get that. There's basically a 0% chance of us regressing that test as it's just an LLVM bug, and they already have a regression test upstream as well.
Another option would be to create a base Docker image (publishing it to Docker Hub) that is just and the appropriate steps to build whatever version of LLVM we want.
We currently advertise ourselves as supporting LLVM 3.7+, and Travis is kinda our test for that, so I'd prefer to not pull that forward just yet (but instead just fix this)
For the record, I downgraded our LLVM version in a botched rebase and only this test stopped it at bors. Hopefully, someone would have noticed the absence of a fix, but you can't count of that.
touche!
Code change:
} } <ins> fn collect_predicates_for_types(&mut self, obligation: &TraitObligation<'tcx>, trait_def_id: ast::DefId, types: Vec<Ty<'tcx>>) -> Vec<PredicateObligation<'tcx>> { let derived_cause = match self.tcx().lang_items.to_builtin_kind(trait_def_id) { Some(_) => { self.derived_cause(obligation, BuiltinDerivedObligation) }, None => { self.derived_cause(obligation, ImplDerivedObligation) } }; let normalized = project::normalize_with_depth(self, obligation.cause.clone(), obligation.recursion_depth + 1, &types); let obligations = normalized.value.iter().map(|&nested_ty| { // the obligation might be higher-ranked, e.g. for<'a> &'a // int : Copy. In that case, we will wind up with // late-bound regions in the `nested` vector. So for each // one we instantiate to a skolemized region, do our work // to produce something like `&'0 int : Copy`, and then // re-bind it. This is a bit of busy-work but preserves // the invariant that we only manipulate free regions, not // bound ones. self.infcx.try(|snapshot| { let (skol_ty, skol_map) = self.infcx().skolemize_late_bound_regions(&ty::Binder(nested_ty), snapshot); let skol_predicate = util::predicate_for_trait_def( self.tcx(), derived_cause.clone(), trait_def_id, obligation.recursion_depth + 1, skol_ty); match skol_predicate { Ok(skol_predicate) => Ok(self.infcx().plug_leaks(skol_map, snapshot, &skol_predicate)), Err(ErrorReported) => Err(ErrorReported) } }) }).collect::<Result<Vec<PredicateObligation<'tcx>>, _>>(); match obligations { Ok(mut obls) => { obls.push_all(normalized.obligations.as_slice()); obls }, Err(ErrorReported) => Vec::new() } } </ins> /////////////////////////////////////////////////////////////////////////// // CONFIRMATION //

Related discussion:
text: For example, this code does not compile: cc
I think this may be another instance of
Trusting analysis, closing in favor of but adding test case there as well.
(it of course would be good to confirm that this actually is an instance of -- my initial reaction when I saw it was "they might be related ... but wait, wasn't part of the opt-in-builtin-bounds work to be able to move the special case handling of / out into library code...?"; I've only done some rough skimming that makes me think the hypothesis remains plausible.)
Ah either way is fine by me, I personally like fewer issues :). We can reopen once is addressed one way or another if necessary (or if you'd like to reopen now that's also fine by me!)
oh that was really just a note to myself as much as anything else, not a comment on your choice to close this ticket. :)
I don't think this code uses type-contents. If it does, that is itself a bug! Either way, we should keep this open for the time being.
cc
Code change:
} } <ins> fn collect_predicates_for_types(&mut self, obligation: &TraitObligation<'tcx>, trait_def_id: ast::DefId, types: Vec<Ty<'tcx>>) -> Vec<PredicateObligation<'tcx>> { let derived_cause = match self.tcx().lang_items.to_builtin_kind(trait_def_id) { Some(_) => { self.derived_cause(obligation, BuiltinDerivedObligation) }, None => { self.derived_cause(obligation, ImplDerivedObligation) } }; let normalized = project::normalize_with_depth(self, obligation.cause.clone(), obligation.recursion_depth + 1, &types); let obligations = normalized.value.iter().map(|&nested_ty| { // the obligation might be higher-ranked, e.g. for<'a> &'a // int : Copy. In that case, we will wind up with // late-bound regions in the `nested` vector. So for each // one we instantiate to a skolemized region, do our work // to produce something like `&'0 int : Copy`, and then // re-bind it. This is a bit of busy-work but preserves // the invariant that we only manipulate free regions, not // bound ones. self.infcx.try(|snapshot| { let (skol_ty, skol_map) = self.infcx().skolemize_late_bound_regions(&ty::Binder(nested_ty), snapshot); let skol_predicate = util::predicate_for_trait_def( self.tcx(), derived_cause.clone(), trait_def_id, obligation.recursion_depth + 1, skol_ty); match skol_predicate { Ok(skol_predicate) => Ok(self.infcx().plug_leaks(skol_map, snapshot, &skol_predicate)), Err(ErrorReported) => Err(ErrorReported) } }) }).collect::<Result<Vec<PredicateObligation<'tcx>>, _>>(); match obligations { Ok(mut obls) => { obls.push_all(normalized.obligations.as_slice()); obls }, Err(ErrorReported) => Vec::new() } } </ins> /////////////////////////////////////////////////////////////////////////// // CONFIRMATION //

Related discussion:
text: The following doesn't compile, but I believe it should: Error: Even though , and . In fact, this compiles:
should be , because the old definition that didn't use assoc types was . Probably the code that detects builtin bounds wasn't updated to handle associated types. cc
This breaks us in hyper. For now, I'll have to manually , knowing that it's safe.,,
Code change:
#[primary_span] pub span: Span, } <ins> #[derive(Diagnostic)] #[diag(hir_analysis::missing_parentheses_in_range, code = "E0689")] pub struct MissingParentheseInRange { #[primary_span] #[label(hir_analysis::missing_parentheses_in_range)] pub span: Span, pub ty_str: String, pub method_name: String, #[subdiagnostic] pub add_missing_parentheses: Option<AddMissingParenthesesInRange>, } #[derive(Subdiagnostic)] #[multipart_suggestion_verbose( hir_analysis::add_missing_parentheses_in_range, applicability = "maybe-incorrect" )] pub struct AddMissingParenthesesInRange { pub func_name: String, #[suggestion_part(code = "(")] pub left: Span, #[suggestion_part(code = ")")] pub right: Span, } </ins>

Related discussion:
text: <!-- 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. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should something like this: label +D-confusing +D-invalid-suggestion <!-- 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 --
claim