jiebi/CodeConvo huggingface dataset:
Change:
// test named lifetimes, just in case // @has async_fn/fn.named.html // @has - '//pre[@class="rust item-decl"]' "pub async fn named<'a, 'b>(foo: &'a str) -> &'b str" <del> pub async fn named<'a, 'b>(foo: &'a str) -> &'b str {} </del> <ins> pub async fn named<'a, 'b>(foo: &'a str) -> &'b str { "" } </ins> // @has async_fn/fn.named_trait.html // @has - '//pre[@class="rust item-decl"]' "pub async fn named_trait<'a, 'b>(foo: impl Pattern<'a>) -> impl Pattern<'b>" pub async fn named_trait<'a, 'b>(foo: impl Pattern<'a>) -> impl Pattern<'b> {}

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:
impl bar for u32 { fn dup(&self) -> u32 { *self } fn blah<X>(&self) {} } fn main() { <del> 10.dup::<i32>(); //~ ERROR type annotations needed </del> <ins> 10.dup::<i32>(); </ins> //~^ ERROR this associated function takes 0 generic arguments but 1 <del> 10.blah::<i32, i32>(); //~ ERROR type annotations needed </del> <ins> 10.blah::<i32, i32>(); </ins> //~^ ERROR this associated function takes 1 generic argument but 2 (Box::new(10) as Box<dyn bar>).dup(); //~^ ERROR E0038

Discussion:
When I run this code (via ): I get the output I expected (i.e., a single line of output that says "My number is 42"). However, if I run this code (via the same with no other changes): I get two compiler errors. The first error indicates that is not in scope - this makes sense, I have not defined anywhere. However, the second error indicates (provided below) does not make sense: It appears that, when there are no other compiler issues, the compiler can infer a type for just fine. However, as soon as any other compiler issue appears, it loses the ability to infer type. That doesn't make sense to me - the ability to infer type should be unrelated to any other compiler errors present. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I partially fixed this for and in , but not in general. I am dissatisfied with this error message. I'll look into fixing it. claim
Change:
<ins> pub t(# //~^ ERROR missing `fn` or `struct` for function or struct definition //~ ERROR this file contains an un-closed delimiter </ins>

Discussion:
I see the following error on the and channels, but not on : Found with the help of .
triage: P-high, because errors being swallowed, even in the presence of other errors, scares me a bit.
Perhaps might be a good candidate to investigate?
The error that is not being emitted is ~Looking.~ Found, incoming PR shortly.
Change:
* ``` */ #[lang="index"] <del> pub trait Index<Index, Sized? Result> { </del> <ins> pub trait Index<Index, Sized? Result> for Sized? { </ins> /// The method for the indexing (`Foo[Bar]`) operation fn index<'a>(&'a self, index: &Index) -> &'a Result; }

Discussion:
As titled. Although slices support the operator, it does not implement , so one cannot pass in a slice in the following example:
I'm somewhat inclined to think we could just remove the built-in indexing from entirely and thus remove/reduce the need for the special lang-items, although there's at least three considerations: the failure message for out-of-bounds indexing would be less informative (no file/line information), but debugging any other (e.g. ) already requires a debugger to get this info, so maybe it's not so bad. can't yet implement properly, so this would still need built-in support with (and thus the out-of-bounds failure lang items can't be entirely removed just yet), unless implicit coercions will work. needs to be fixed before will work properly (and I guess DST would make it work more nicely). Users would theoretically not see a change, since this would all happen inside (and ).
It's not possible due to lack of CTFE.
cc me
Should I send a PR implementing / for now, and we can evaluate later removing the built-in indexing? I already tested that PR, and the built-in indexing is preferred in the operation , but one go through the trait using .
Yes, please go ahead and do so. Thanks!
Change:
<del> //@ known-bug: #119830 #![feature(effects)] #![feature(min_specialization)] trait Specialize {} trait Foo {} impl<T> const Foo for T {} impl<T> const Foo for T where T: const Specialize {} </del>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: is not fully resolved', 'error: internal compiler error: is not fully resolved' File: --Another regression of 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: [checkmodimpl_wf] checking that impls are well-formed in top-level module [analysis] running analysis passes on this crate --
This is caused by the fact that  does not check for const effect vars when visiting . It should be relatively simple to match on in the folder.
Working on this one.
Change:
fn main() { let x = None; give_any(|y| x = Some(y)); <del> //~^ ERROR borrowed data cannot be stored outside of its closure </del> <ins> //[ast]~^ ERROR borrowed data cannot be stored outside of its closure //[migrate]~^^ ERROR borrowed data cannot be stored outside of its closure //[nll]~^^^ WARN not reporting region error due to nll //[nll]~| ERROR borrowed data escapes outside of closure //[nll]~| ERROR cannot assign to `x`, as it is not declared as mutable </ins> }

Discussion:
D'oh: while investigating , I found a case where we are downgrading the NLL errors to warnings (due to the migration mode in ), but AST-borrowck issues an error for the test! (This may explain , at least in part...) Namely, . Here is the test: Here is the AST-borrowck output (a hard error): And here is the NLL output (another hard error): But here is the output from : ui/borrowck/issue- is one particular instance of this, but now that I've found one, I'm certain there are more. This is pretty bad. Very high priority to fix.
This code looks suspicious:
Ha I should have just left this to to fix, since we seem to have independently identified the culprit.
I think I've already assigned myself to enough issues.
Change:
doctest = false [dependencies] <del> # Prevent cc from upgrading all the way to 1.0.46, # which fails the build (see e.g. #65445.) cc = "=1.0.37" </del> arena = { path = "../libarena" } bitflags = "1.2.1" fmt_macros = { path = "../libfmt_macros" }

Discussion:
Do we have plan to get rid of this restriction recently? A newer version of cc-rs is needed for VxWorks
can't currently be updated due to a build problem with riscv. More info at I think the issue is that rustbuild uses cc to discover cc toolchains, and gained riscv support, and so now it thinks it should use a gcc toolchain that doesn't exist. The detection is in and Alex mentioned just setting a env var in the riscv container might be enough. It's been on my todo list for a while, but I haven't had a chance to look at it. I can maybe try to look at it this weekend.
Thanks for working on this issue. Enjoy your weekend, it is not that urgent.
Change:
status.success() } <ins> pub fn check_run(cmd: &mut Command, print_cmd_on_fail: bool) -> bool { let status = match cmd.status() { Ok(status) => status, Err(e) => { println!("failed to execute command: {:?}nerror: {}", cmd, e); return false; } }; if !status.success() && print_cmd_on_fail { println!( "nncommand did not execute successfully: {:?}n expected success, got: {}nn", cmd, status ); } status.success() } </ins> pub fn run_suppressed(cmd: &mut Command) { if !try_run_suppressed(cmd) { std::process::exit(1);

Discussion:
I just cloned this rust repo and attemped to build it by calling It initialized submodules, started downloading and failed repeatedly: Waiting longer causes messages above to repeat. It's not connection issue, because it always fails after ~30 seconds of downloading (Messages above repeat in ~2 minutes). I also tried changing to here: What caused download to succeed in a few (1-2) minutes. So I assume it's to blame. version:
I got x.py to test libcore once, but after I updated my local clone of rust, I started getting this repeatedly:
I am nuking my entire rust clone in case changes to the bootstrap are incompatible to previous artifacts produced by previous versions. Why does x.py need to download submodules like and if I am only trying to test ? edit: apparently, this is expected
Nope, I am still getting the DownloadFile exception after refreshing everything, including updating MSYS2 to get curl to 7.65.1, trying the MSYS2 that comes along with git, and messing with
your issue is different and there is no involved (it downloads file through PowerShell). You can see this MSYS2 patch how to make it use instead:
Thank you, it works now
original issue (from comment 0) is not resolved. reported another issue that isn't solved either, there is only workaround available.
We should probably fallback to trying curl if the powershell invocation fails. Reopening. I think a PR would work best here.
For some reason, the powershell download is working again on both my MSYS2 install and from git bash. We still want that fallback though. I couldn't PR a fix though, because I don't know how the exception handling is working in that Python script.
Actually, since I should learn Python anyway, should I PR a fix? Is it as simple as detecting an exception occurred and refactoring the if-else statement in a way that it would also run ?
That's what I would suggest -- we can make it pretty simple and if anything goes wrong with the powershell call then fallback to curl
It might also make sense to try curl before using powershell, as suggested by in label: +E-easy
Change:
self } // Get a mutable borrow of the environment variable map for this `Command`. <del> fn get_env_map<'a>(&'a mut self) -> &'a mut EnvMap { </del> <ins> fn get_env_map<'a>(&'a mut self) -> &'a mut  EnvMap { </ins> match self.env { Some(ref mut map) => map, None => { // if the env is currently just inheriting from the parent's, // materialize the parent's env into a hashtable. self.env = Some(os::env_as_bytes().into_iter() <del> .map(|(k, v)| (k.as_slice().to_c_str(), </del> <ins> .map(|(k, v)| (EnvKey(k.as_slice().to_c_str()), </ins> v.as_slice().to_c_str())) .collect()); self.env.as_mut().unwrap()

Discussion:
The following program demonstrates the problem: When compiled and executed on WIndows, it randomly displays either 'foo' or 'BAR'. This happens because process::Command represents environment block as a HasMap<CString, CString, so it treats "foo" and "FOO" as different variables, whereas Windows considers them to be the same one. When child process is spawned, both get into the environment block, however Windows keeps only the last one.
Change:
let (short, name) = item_ty_to_strs(myty.unwrap()); write!( w, <del> "<h2 id="{id}" class="section-header"> </del> <ins> "<h2 id="{id}" class="small-section-header"> </ins> <a href="#{id}">{name}</a> </h2>n{}", ITEM_TABLE_OPEN,

Discussion:
They used to be blue and are now black. I don't think this change was intentional, although we have been thinking about migrating more headers to be black recently. I think this regressed very recently, since I probably would have noticed it otherwise. !
I wonder if this was caused by or ? Those were both merged recently, though the second one doesn't seem like it could have changed colors. cc
This regressed in , which as one of the rules for an anchor to be styled black. The goal with that change was to make the section headings on module pages black (e.g. ). Those have . However, headings generated from Markdown in a docblock also have . I think the right short-term fix is: Section headings on module pages get , like their peers on other pages. Remove the CSS rule for to be black. It's not really clear to me why Markdown gets , and Rustdoc-generated headings get , particularly given that the Rustdoc headings are almost always bigger. Probably we should rename these to and .
Since you figured out a way to fix this regression, do you want to assign yourself and open a PR with the fix?
Will do.
Change:
let link_obj = |output_path: &Path| { // Running `ld -r` on a single input is kind of pointless. if sess.opts.cg.codegen_units == 1 { <del> fs::copy(&crate_output.with_extension("0.o"), output_path).unwrap(); </del> <ins> copy_gracefully(&crate_output.with_extension("0.o"), output_path); </ins> // Leave the .0.o file around, to mimic the behavior of the normal // code path. return;

Discussion:
I have no idea why this is happening.
Try . And can you provide a copy of ?
You already have a file which belongs to user . Since you’re compiling as a regular user now, can’t overwrite the file and therefore fails. You can circumvent the issue by removing the file manually as root (). I’ll try to get rid of the ICE in the mean time. EDIT: this is backtrace:
Thanks, that worked.
Change:
- [Added the `tiny` value to the `code-model` codegen flag.][72397] - [Added tier 3 support* for the `mipsel-sony-psp` target.][72062] - [Added tier 3 support for the `thumbv7a-uwp-windows-msvc` target.][72133] <ins> - [Upgraded to LLVM 10.][67759] </ins> * Refer to Rust's [platform support page][forge-platform-support] for more information on Rust's tiered platform support.

Discussion:
I'll leave my story here because it shows how important the information can be: We recently upgraded from rustc 1.43 to 1.47 to build Firefox (we got stuck on 1.43 for a large number of complicated reasons, and would still be stuck if we hadn't found workarounds). Anyways, consequently, we've had a bunch of regressions, one of which was performance-related and I was bisecting it. The first thing I did was to compare each rust release, and it turned out the regression started between 1.44 and 1.45. So I went to the 1.45 release notes suspecting LLVM could have been involved and saw nothing there. Now, several hours later bisecting through nightlies (because PGO and LTO being involved, testing one version takes a while), the regression appears to have started between rustc 1.45.0-nightly ( 2020-05-21) and rustc 1.45.0-nightly ( 2020-05-20) So I take my git, type and lo and behold, there it is: I'm still waiting on the results actually confirming LLVM is involved (it likely is), but it would have saved me a lot of time if the LLVM upgrade had been mentioned (which it is for LLVM 11 in 1.47, BTW, but OTOH, now that I look, it appears the last upgrade mentioned is to LLVM 6 in 1.25...)
FWIW, the LLVM 11 upgrade in 1.47 got back a lot of the performance LLVM 10 lost:
Not for the testcase I'm bisecting, but that's OT.
I agree we should be mentioning this; thank you for noting it. I would be happy to accept a PR adding those in to the release notes (just 1.45 and 1.47, or more if you have the time).
Do you have an issue for that regression?
Will have when I have more information to feed into one.
Change:
<ins> #! // check-pass fn main() {} </ins>

Discussion:
We fail to parse this (admittedly questionable) code as of beta: This broke one repository (not crate) in the beta crater run: https://crater-
cc I personally suspect that we may want to ask T-lang if we're good accepting this as expected breakage. Alternatively I guess we can adjust the shebang detection to not require a non-empty shebang.
Assigning .
For reference, here's the code responsible for parsing shebang in Linux kernel - (Fully whitespace (including empty) line isn't considered a shebang.)
I am inclined to close as won't fix; let's cc as the author of that repository as well. I'm going to go ahead and nominate this so that we can get a :+1: (or not) at the T-compiler meeting confirming won't fix status.
I made a fix in , which also has a benefit of simplifying the rules slightly.
Thanks guys, was more of a spelling mistake/leftover from previous version than unclear explanation of how to use shebang with rust as your previous explanation on how to use it worked fine in something else I was playing around with. But thank you very much for letting me know. Sent with Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
Change:
link_resolver.resolve_doc_links_local(&krate.attrs); link_resolver.process_module_children_or_reexports(CRATE_DEF_ID.to_def_id()); visit::walk_crate(&mut link_resolver, krate); <del> link_resolver.process_extern_impls(); </del> // FIXME: somehow rustdoc is still missing crates even though we loaded all // the known necessary crates. Load them all unconditionally until we find a way to fix this.

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
cc
Rustdoc assumes that there is always a module for every primitive type referred to by a doc link, which is not the case in the code example above or any "minimal core" example not containing the primitive documentation modules.
Fixed in
Change:
+ +[dependencies] +rand = "0.7" <del> diff --git a/library/core/tests/ptr.rs b/library/core/tests/ptr.rs index 1a6be3a..42dbd59 100644 --- a/library/core/tests/ptr.rs +++ b/library/core/tests/ptr.rs @@ -250,6 +250,7 @@ fn test_unsized_nonnull() { }; } +/* #[test] #[allow(warnings)] // Have a symbol for the test below. It doesn’t need to be an actual variadic function, match the @@ -277,6 +277,7 @@ pub fn test_variadic_fnptr() { let mut s = SipHasher::new(); assert_eq!(p.hash(&mut s), q.hash(&mut s)); } +*/ #[test] fn write_unaligned_drop() { </del> -- 2.21.0 (Apple Git-122)

Discussion:
This causes a crash when trying to test libcore with cgclif, as Cranelift doesn't allow incompatible definitions of the same function. While this currently works for cgllvm, according to it is likely to become forbidden with cg_llvm too.
modify labels:+A-cranelift
Change:
<del> //@ known-bug: rust-lang/rust#130372 pub fn test_va_copy(_: u64, mut ap: ...) {} pub fn main() { unsafe { test_va_copy(); call(x); } } </del>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at /rust/deps/itertools- 'itertools: .zipeq() reached end of one iterator before the other'', 'thread 'rustc' panicked at /rust/deps/itertools- 'itertools: .zipeq() reached end of one iterator before the other'' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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 -- label +F-cvariadic +F-fndelegation <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
lol
Thanks! I will take a look. (I'm glad we the check!)
another one that does not need delegation I think
claim
Change:
clearInputTimeout(); if (search_input.value.length === 0) { if (browserSupportsHistoryApi()) { <del> history.replaceState("", window.currentCrate + " - Rust", "?search="); </del> <ins> history.replaceState("", window.currentCrate + " - Rust", getNakedUrl() + window.location.hash); </ins> } hideSearchResults(); } else {

Discussion:
mdbook v4.6+ has a feature that pressing ESC removes query components from URLs (for example ). The feature was implemented in rust-lang/mdBook. It would be nice if rustdoc offers the same kind of that feature. This is, for example, an URL that contains query components in rustdoc: When users share URLs to an API, they don't have to remove the query manually.
could you share some thoughts about this feature request? If possible, could you mentor contributors how to implement this ?
I think it's a good idea. Gonna take a look at how to do it.
Can we reopen this issue ? I think only removes the query component when we remove keywords in search bar. This issue is about adding a keyboard shortcut.
Oh I see, my bad. Reopening!
Change:
macro_rules! register_diagnostics { ($($ecode:ident: $message:expr,)* ; $($code:ident,)*) => ( <del> pub static DIAGNOSTICS: &[(&str, &str)] = &[ $( (stringify!($ecode), $message), )* </del> <ins> pub static DIAGNOSTICS: &[(&str, Option<&str>)] = &[ $( (stringify!($ecode), Some($message)), )* $( (stringify!($code), None), )* </ins> ]; ) }

Discussion:
The functionality (does anyone still uses this now that it's ?) gives the same "no extended information" message for real error codes that don't have a "long" explanation written, and nonexistent codes. These messages should be disambiguated (as "no extended information for E0XXX" vs. "E0XXX does not exist" or similar). I thought this would be straightforward to implement: we (which get successfully , although the ), only to when macroexpanding the arrays . So this should, you would think, just be a matter of editing reflect that, and making the care. But when I actually do this (zackmdavis/rust ... my changes to seem to have absolutely no effect (!?!); we still get a even though I thought my code pretty clearly said otherwise, on more than one day that I've looked at this. I hereby give up in despair, bafflement, and tears. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
The diagnostic registration is "just" a macrorules macro now so I suspect this is pretty simple to implement per the suggested path in the issue description; I'm going to mark as E-easy and E-mentor with myself as the mentor. You'll want to edit the array definitions to have the type or so and add in the short diagnostics. Once that's done, if you run you'll likely hit an error in the use site of from . Fixing that'll mostly involve fixing up the diagnostics registry in ; I would store the long diagnostics and short diagnostics separately, adding a field like . Once this is done, there might be a few more type errors to clean up but that should mostly be a matter of making types match up I would hope. Let me know if you have any questions; here on this issue or feel free to open up a PR with some initial work and I can try and provide feedback there.
One additional thing that we should probably add as part of this work is an error if the same diagnostic code is registered twice (cc ).

I imagine this would mostly be a matter of inserting all the codes into an FxHashSet and panicking if there's one inserted twice; an ICE here is fine since it'll definitely be caught in CI.
Hey, If this still needs fixed, I would love to work on this. I will probably be reaching out before to long for some guidance. claim
Shoot not sure if I read what was happening in this thread all the way. are you working on this already?
I'm not; go for it! (Although ... I thought I remembered seeing an issue recently where people were discussing moving away from the numeric error codes, but I can't find it. was that a real thing?)
Maybe you are referring to this conversation on Zulip? https://rust-