jiebi/CodeConvo huggingface dataset:
Change:
//~^ERROR can't compare `str` with `&String` [E0277] } <ins> fn qux() { // Issue #119352 const FOO: i32 = 42; let _ = FOO & (*"Sized".to_string().into_boxed_str()); //~^ ERROR the size for values of type `str` cannot be known at compilation time //~| ERROR no implementation for `i32 & str` [E0277] } </ins> fn main() {}

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'range start index 2 out of range for slice of length 1'', 'thread 'rustc' panicked at 'range start index 2 out of range for slice of length 1'' File: --snippet: 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: [typeck] type-checking [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Regression in cc sjwang05
claim
just to jump start, I just checked the contents of in the case presented: I'm checking what breaks in the test suite if we change the slicing to (which intuitively makes more sense but am still trying to piece things together). Edit: Ah, yeah, that won't work.
Thanks for the help, turns out I could've just used instead of slicing all along . I'll submit the PR once the test suite finishes running locally. As a side note, do you know why some binops seem to have 3 args? Intuitively it'd make sense to only have 2 args for the lhs and rhs tys--my guess is that the "extra" arg is something effects-related, but I'm not familiar at all with that part of the code.
Change:
if ty.is_copy_modulo_regions(cx.tcx, param_env) { return; } <ins> if type_implements_negative_copy_modulo_regions(cx.tcx, ty, param_env) { return; } </ins> // We shouldn't recommend implementing `Copy` on stateful things, // such as iterators.

Discussion:
I would expect the following code to compile successfully since we explicitly opt out of implementing : However, the code fails to compile with the following error message: label C-bug A-lint F-negativeimpls <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
The compiler only checks if the type implements already to return early and not emit the lint diagnostic but it doesn't check if the type implements :
I think this makes the trick, you are right! the last think is to explore what is the code of the method The code of the method looks not so trivial :) If you did not find already I can play with your on it by mentoring you, I had some experience in "git archeology" :) label +E-mentor
claim
Change:
e.innerHTML = labelForToggleButton(false); }); toggle.title = "collapse all docs"; <del> onEach(document.getElementsByClassName("docblock"), function(e) { e.style.display = 'block'; }); onEach(document.getElementsByClassName("toggle-label"), function(e) { e.style.display = 'none'; }); onEach(document.getElementsByClassName("toggle-wrapper"), function(e) { removeClass(e, "collapsed"); }); </del> onEach(document.getElementsByClassName("collapse-toggle"), function(e) { <del> onEveryMatchingChild(e, "inner", function(i_e) { i_e.innerHTML = labelForToggleButton(false); }); </del> <ins> collapseDocs(e, "show"); </ins> }); } else { addClass(toggle, "will-expand");

Discussion:
When pressing the hotkey on type's documentation such as on the , the methods of the are still shown. This is however mostly useless information that gets in the way of scrolling to see what traits a type implements. It would be more ergonomic if would hide every method of every trait but still show all associated items (types and consts) for each (since they carry useful information). In addition, a / link should be on all the s (including non-trait impls) either besides or to the left of the (as done with s this expands and collapses the impls but keeps associated items shown.
I can rewrite this as an RFC if required, but I was unsure about the protocol wrt. rustdoc.
Similar request:
Closing as resolved.

For example, looking at the docs for , some important trait implementations are hard to find in between all the implementations for each size of fixed-size arrays: Hopefully these impls will eventually become generic, but in the meantime we should consider some way of hiding or collapsing them in the docs.
cc
Dupe of
Change:
// can be reborrowed without needing to spill to a temporary. // If this were not the case, then we could conceivably have // to create intermediate temporaries.) <del> let ty = self.fcx.tables.borrow().expr_ty(expr); self.record(ty, scope, Some(expr), expr.span); </del> <ins> // // The type table might not have information for this expression // if it is in a malformed scope. (#66387) if let Some(ty) = self.fcx.tables.borrow().expr_ty_opt(expr) { self.record(ty, scope, Some(expr), expr.span); } else { self.fcx.tcx.sess.delay_span_bug(expr.span, "no type for node"); } </ins> } }

Discussion:
() Triggers on playground on beta and nightly channels, not on stable. Stacktrace:
Even smaller sample (from
triage: P-high. Removing nomination.
triage: P-high, removing nomination label.
Change:
} else if reg == InlineAsmReg::AArch64(AArch64InlineAsmReg::x30) { // LLVM doesn't recognize x30 "{lr}".to_string() <ins> } else if reg == InlineAsmReg::Arm(ArmInlineAsmReg::r14) { // LLVM doesn't recognize r14 "{lr}".to_string() </ins> } else { format!("{{{}}}", reg.name()) }

Discussion:
I attempted to compile a crate containing the following expression: I expected it to compile successfully. Instead, I received this error: : omitted, it did not produce anything else. diagnosed the cause and offered a solution .
While I try to spin up a rustc development environment, can someone point me to the tests for this code? I don't see any tests in the crate.
I think I have a working development environment now. I'll try to fix this -- thank you for making this easy for me!
Change:
<ins> // Copyright 2017 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. #![allow(unused)] struct PersonalityInventory { expressivity: f32, instrumentality: f32 } impl PersonalityInventory { fn expressivity(&self) -> f32 { match *self { PersonalityInventory { expressivity: exp, ... } => exp //~^ ERROR expected field pattern, found `...` } } } fn main() {} </ins>

Discussion:
Consider the following code: If you try to compile this, you get the following errors: See the bug? Its because I used when I should have used It would be nice if the compiler, in its ever friendly manner, suggested the latter to me.
I volunteer.
Change:
name = "cargo-miri" version = "0.1.0" dependencies = [ <del> "cargo_metadata 0.9.1", </del> <ins> "cargo_metadata 0.11.1", </ins> "directories", "rustc-workspace-hack", "rustc_version",

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! And nominating for compiler team prioritization.
The bot is wrong; it's not that broke Miri, it's
Change:
if let Some(did) = typaram.def_id(self.cache) && !self.should_keep_impl(&i, did) { <del> debug!("ImplStripper: stripped item in trait's generics; removing impl"); </del> <ins> debug!("ImplStripper: stripped item in trait's generics; removing {imp:?}"); </ins> return None; } }

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. --I tried this code: I expected the documentation for the type alias to show the method and the implementation of . Instead, the type alias does not show the method . It does however show the implementation of . ! By publicly exposing through , the documentation of on the alias is documented as I expected, but then is publicly reachable, which in my case is unwanted due to being an internal implementation detail. This also works when making the statement , which gets the docs to look like I expected them to. ! <!-- 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. --: Thanks for helping me figure out why what I was expecting wasn't happening though it looked like it should.
I think it's ok to document an impl on a reexported if the reexported item is not doc hidden. I'll send a fix in the next weeks.
Change:
match *lvalue { mir::Lvalue::Temp(index) => { <ins> self.mark_assigned(index as usize); </ins> if !rvalue::rvalue_creates_operand(rvalue) { self.mark_as_lvalue(index as usize); }

Discussion:
In MIR we want values to be SSA, however ensuring that constraint in trans (i.e. in TempRef) is wrong, I think. Namely, for code like this: we will generate following MIR (graphviz version, because easier to visualise): ! which will result in Note how we assign twice, but the two branches are fully disjoint, and thus, for the purposes of data-flow is still SSA, but for the purposes of translator is assigned multiple times. If we want s to stay across translation of the whole function, we will need something like a in the MIR. cc
Another option would be to convert these temporaries into lvalues (i.e. variables). Could it be that the unfinished is supposed to do just that?
I am confused. We do not require temps to be SSA, either in Mir or trans... But in trans we optimize in those cases where we can (I.e., where temps are SSA). Right?
suggests they are SSA with borrowing and mutation possible. Might be me misinterpreting what SSA means, but what I mean is that these are not supposed to be assigned more than once, for some definitions of once.
I see. Yes, ok, I agree that comment was in error. I think though that you probably ought to update it in :) I would still expect temps to be "DSA" -- which afaik I just made up -- that is, no two writes can reach one another without exiting the "live scope" of the temporary, but I don't know that it's an important property. FWIW I think SSA usually implies that values are "pure values", i.e., you can't take their address and mutate them. But I know what you mean in any case.
er, ought to have updated it
I’ll keep updating the comment in mind in whatever PR that comes next.
Change:
/// In other words, if two keys are equal, their hashes should also be equal. /// `HashMap` and `HashSet` both rely on this behavior. /// <del> /// This trait can be used with `#[derive]`. </del> <ins> /// ## Derivable /// /// This trait can be used with `#[derive]` if all fields implement `Hash`. /// When `derive`d, the resulting hash will be the combination of the values /// from calling `.hash()` on each field. /// /// ## How can I implement `Hash`? /// /// If you need more control over how a value is hashed, you need to implement /// the trait `Hash`: /// /// ``` /// use std::hash::{Hash, Hasher}; /// /// struct Person { ///     id: u32, ///     name: String, ///     phone: u64, /// } /// /// impl Hash for Person { ///     fn hash<H: Hasher>(&self, state: &mut H) { ///         self.id.hash(state); ///         self.phone.hash(state); ///     } /// } /// ``` </ins> #[stable(feature = "rust1", since = "1.0.0")] pub trait Hash { /// Feeds this value into the state given, updating the hasher as necessary.

Discussion:
I'm using s as keys in a BtreeMap. I have to look up the map ~15 million times per second (10G ethernet line rate). Ipv4Addr cmp() compiles to this on my system (linux x86-64, rustc 1.10.0-nightly ( 2016-05-21)) Which seems kinda inefficient for a thing which is basically u32. I guess part of the reason is the which converts it to an array(!) first. I copied the definition and implemented Ord like this: It's about 10 times faster on my .
Nice find! Want to send a PR for this? Looks like something that'd be more than welcome :)
Change:
pretty::print_after_hir_lowering(tcx, *ppm); Ok(()) })?; <ins> // Make sure the `output_filenames` query is run for its side // effects of writing the dep-info and reporting errors. queries.global_ctxt()?.enter(|tcx| tcx.output_filenames(())); </ins> } else { let krate = queries.parse()?.steal(); pretty::print_after_parsing(sess, &krate, *ppm);

Discussion:
Related: (i.e. having as an actual would be nice). We use in the kernel to provide the expanded output in outputs/targets. The dependency information is not critical, but the change made our Make target fail (so we need a change on the kernel side), and it would be nice nevertheless to have the dependency information (assuming it is accurate), e.g. we also use it for similar outputs like and .
Bisection seems to lead to commit but I am not sure / cant say if really related. The mentioned issue was opened before that commit was merged :thinking: wdy?
This looks like another symptom of We'll likely keep regressing this by accident without a test. I don't know why was fixed between when it was reported and 1.68
Thanks for fixing this
Change:
#![feature(slice_flatten)] #![feature(error_generic_member_access)] #![feature(error_in_core)] <del> #![cfg_attr(not(bootstrap), feature(trait_upcasting))] </del> <ins> #![feature(trait_upcasting)] </ins> #![feature(utf8_chunks)] #![feature(is_ascii_octdigit)] #![feature(get_many_mut)]

Discussion:
hello everyone, I got this error when I bootstrap the current rust-beta branch: There was a lot of pushing and reverting changesets relevant to the c literals stabilization, I tried to get an overview of what backport might be missing here, but I failed and am at a loss. I am on linux x86_64, with musl as my libc, I doubt the later is causing the issues.
What are you using as your bootstrap compiler? We only support using the previous release.
I think I understand what is going on. If you try to bootstrap 1.77 from 1.76, it will fail. We were intending to have c-string literals stabilized in 1.76, but that got reverted. However, the revert did not include the appropriate parts of I can probably put something together to fix it.
Posted with a fix.
Change:
``` You'll notice that you don't need a `fn main()` or anything here. `rustdoc` will <del> automatically add a `main()` wrapper around your code, and in the right place. For example: </del> <ins> automatically add a `main()` wrapper around your code, using heuristics to attempt to put it in the right place. For example: </ins> ```rust /// ```

Discussion:
When a doctest like this is written: /// /// running the tests will produce an error like: since the test code is wrapped inside a for execution. This is imho not clear in this algorithm description
This seems like a bug somewhere in rustc/cargo, rather than a problem with the docs, because rust /// works fine, but (as was mentioned here) rust /// does not. This seems like wrong behaviour. Also, the suggested rust /// does not work either, I don't know if there is an RFC or issue open about attempting to resolve the names suggested under ... and only showing them if they exist. EDIT: as mentioned below, this is not a bug with rustc or cargo, it's just that there is no way to refer to the current function scope in a use statement if you import a crate into it.
it's not wrong but it is very misleading. The key is that if does not appear in the doc test, then rustdoc encloses the entire test in a main function. This, coupled with the fact that does not really work inside a function, produces the bad situation in which we find ourselves.
Right, it's the 'entire' part that's confusing. I myself find it to be so and I wrote the sentence!
It would be nice if rustdoc used similar heuristics to playbot, where stuff like extern crates and crate attributes get hoisted out of the generated main function.
Why is extern crate even allowed inside of functions? That seems like a horrible misfeature.
It's similar to anything else that brings a name into scope, you can do it in whatever scope you'd like.
I guess the "real" problem is that has no way to refer to a function/expression scope. doesn't work, making the "did you mean" note less than helpful.
Change:
"//*[@class='desc docblock-short'][text()='a thing with a label']", ("y"), ) <ins> // Ensure it doesn't expand. set-window-size: (800, 800) go-to: "file://" + |DOC_PATH| + "/test_docs/cfgs/index.html" // This part of the tags should not be on the same line as the beginning since the width // is too small for that. compare-elements-position-false: ( "//*[@class='stab portability']/code[text()='appservice-api-c']", "//*[@class='stab portability']/code[text()='server']", ("y"), ) </ins>

Discussion:
see <img width="1728" alt="image" src=""- Arc 0.108.1 () MacOS 13.2.1 (22D68)
this seems like a rustdoc issue, cc ?
( I couldn't quickly reproduce locally yet, need to figure out the arguments first )
Yep, rustdoc issue, I'll transfer it across. This should be improved by just reducing the number of features shown here with , since a lot of them are already active for the module, but that won't help with the compression/decompression modules in the top-level list. !
Actually, rather than this made me realise there's another issue around how we deal with inlined re-exports, opened for that.
It's also kinda related to

I think long cfg expressions should be broken across multiple lines. I saw this cause issues : !
Do you have an idea on how to improve this maybe
What if we inserted zero width spaces after the keywords? So after each we insert a zero width space (see the ). Maybe we would have to wrap each name in a too but I would have to experiment a bit. Then each expression would try to stay as an inline-block and then break the line on the keywords (like , , , ...)
If we start having "groups", not sure if it'll work well. But definitely worth a try!
I started a test case with a long and complicated expression that results in this image: ! Currently combining a lot of short features is very unreadable and not's are hard to spot. With just it gets a lot more readable, but since the braces get lost in translation it is not clear which flags are binding with , or respectively. ! What if we display a little tree diagram? For most cases that would probably result in a short list with an or an in the beginning. Another idea could be to not draw the tree but to have visible boxes encasing the respective flags. What do you think?
I need to see things to be able to make my own opinion on which approach is better. :smile: But maybe has an idea?
Maybe it could show "any of"/"all of" on longer chains (say 3+)? I don't think there's a ton that can realistically be done here — a long cfg is going to result in a long doc cfg.
There are a lot of things that can be done. For example, for more than 3 items, we could show only the 3 first and show the rest on click. It's mostly about how to display things.
The original case has gotten a lot better, the actual doc string now gets ~60% of the horizontal space rather than ~30%: !
Rendering has degraded again (even though the documented cfg expressions themselves have become shorter): !
Change:
Changes that do not affect contributors to the compiler or users building rustc from source don't need an update to `VERSION`. <del> If you have any questions, feel free to reach out on the `#t-infra` channel in the [Rust Zulip server][rust-zulip] or ask on internals.rust-lang.org. When you encounter bugs, please file issues on the rust-lang/rust issue tracker. </del> <ins> If you have any questions, feel free to reach out on the `#t-infra/bootstrap` channel at [Rust Bootstrap Zulip server][rust-bootstrap-zulip]. When you encounter bugs, please file issues on the [Rust issue tracker][rust-issue-tracker]. </ins> <del> [rust-zulip]: https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra </del> <ins> [rust-bootstrap-zulip]: https://rust-lang.zulipchat.com/#narrow/stream/t-infra.2Fbootstrap [rust-issue-tracker]: https://github.com/rust-lang/rust/issues </ins>

Discussion:
Right now, there are docs for x.py in a bunch of different places: https://rustc-dev- https://rustc-dev- It would be nice to consolidate these some; e.g. can probably just point to the README, and lots of the information in the readme is duplicated in the dev-guide and can be deleted and replaced with a link. cc - do you have strong opinions on this? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
No, seems good to consolidate. I personally think we might get something out of ending up with two guides, one of which discusses the content from an internal perspective (e.g., Step, how to add new targets) and another from an external perspective, focusing on what users need to know. I think most of the existing documentation is sort of in the second of those, but also (potentially correctly, hard for me to say) treats things as a very leaky abstraction and documents a lot of the internals too. I think some of this is our audience, but I do wonder if a much simpler message is possible with just a few standard commands depending on what they want to build, and documenting specific outputs rather than the whole layout. I think right now we're trying to explain things by teaching everything, but perhaps we can get away with not teaching the internals of the abstraction. Anyway, mostly musing, no strong opinions here.
We should also document that we support suffixes instead of full paths (e.g. instead of ):
Hello, Should I start working on adding doc-comments in bootstrap ?
more doc-comments are always welcome :) but when I wrote the issue I was imagining coming up for a plan for how to organize the standalone documentation. maybe we can put the internal documentation in src/bootstrap/README and the user facing documentation in the guide?
claim
I like the idea and I think this standard should be applied in general since this seperation reduces cost of the maintaince and makes dev-guide more understandable and simple for users. I will follow that idea in the refactoring.
Change:
<ins> error: the order of `move` and `async` is incorrect --> $DIR/incorrect-move-async-order-issue-79694.rs:7:13 | LL |     let _ = move async { }; |             ^^^^^^^^^^ | help: try switching the order | LL |     let _ = async move { }; |             ^^^^^^^^^^ error: aborting due to previous error </ins>

Discussion:
I tried this code: This should give a suggestion to reorder the keywords to , something like: Right now it gives this error, which is not very helpful: Tested on 1.48.0 and 1.50.0-nightly (2020-12-03 ) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Releasing assignment as I'm not really sure how to fix this at the moment. release-assignment
This could be handled directly in the parser code which generates the above diagnostic.
claim
Change:
<ins> struct S {} impl S { fn foo(&mur Self) {} //~^ ERROR expected identifier, found keyword `Self` //~| ERROR expected one of `:`, `@` //~| ERROR the `Self` constructor can only be used with fn bar(&'static mur Self) {} //~^ ERROR unexpected lifetime //~| ERROR expected identifier, found keyword `Self` //~| ERROR expected one of `:`, `@` //~| ERROR the `Self` constructor can only be used with fn baz(&mur Self @ _) {} //~^ ERROR expected one of `:`, `@` } fn main() {} </ins>

Discussion:
I'm seeing an internal compiler error on the following input (found by ): The error happens on nightly but not on beta or stable.
Report from : searched nightlies: from nightly-2020-03-09 to nightly-2020-03-30 regressed nightly: nightly-2020-03-16 searched commits: from to regressed commit:
looks like the probable culprit. cc
Will fix.
Was already looking at this hehe, I have a fix for you in