jiebi/CodeConvo huggingface dataset:
Code change:
<ins> // Fixed in #66054. // ignore-tidy-trailing-newlines // error-pattern: aborting due to 2 previous errors #[Ѕ </ins>  No newline at end of file

Related discussion:
text: I realize it's kinda nonsensical, but here:
Why didn't WF catch this?
That's because only checks statics/constants.
Still reproducible with .
This ought to be a mostly easy fix. The problem is that the well formedness check, which ought to be rejected this code, is ignoring things in an : They fall through to this `` case: We would need to add support for the HIR item: which in turn has a number of items: which are defined here: presumably we want the to check that the types of are well-formed, roughly analogous to how we current check normal static items: (We probably want similar checks on foreign item fns, though?) One tricky part might be compatibility, we may need to turn this into a compatibility lint in case there is lots of broken code in the wild.
I am trying to fix this bug, and need help moving forward. function is modified to accept a and a , yet it doesn't report any additional errors and the ICE prevails. Test file: Commit: Should I create a pull request or is it too early?
Looks like suggestions are incomplete ( does not require ). Also, I left a comment on your commit about how you can avoid adding . I suspect the only reason regular s are required to be is they have an initializer (and that, not the type, requires ), i.e. for we have these errors:
Oddly, the PR that were previously posted to fix this (PR , following on PR ) was subsequently closed as inactive ... but the bug itself seems like it may have been resolved in the meantime?
I'm going to assume this was fixed. Tagging as E-needstest, but if someone wants to take the time, it'd be even better to bisect to where this was fixed, and see if a regression test for this was at that time.
Compiler no longer panics, tested with
Code change:
#![feature(staged_api)] #![doc(issue_tracker_base_url = "https://issue_url/")] <del> #![unstable(feature="test", issue = "32374")] </del> <ins> #![unstable(feature = "test", issue = "32374")] </ins> // @matches issue_32374/index.html '//*[@class="item-left unstable deprecated module-item"]/span[@class="stab deprecated"]'  //      'Deprecated'

Related discussion:
text: Right now, the docs produced on the stable and beta channels include unstable items. The docs are already fairly complex and contain a lot of information to sort through, and finding documentation for items that are not usable for the majority of developers working on stable Rust does not help with this. In addition, unstable APIs have very attention-grabbing warnings associated with them, making them much more prominent than the APIs that are actually usable. <img width="1031" alt="Screen shot demonstrating eye-catching unstable warning" src="https://user-"This has been broken out of to provide smaller, actionable items that can be independently discussed and worked on. A review of rustdoc for accessibility, especially for dyslexia and attention disorders, finds that there are a number of visually distracting elements in rustdoc which can draw attention away from the main content. This should be considered along with the other issues mentioned in about the overall effect of a number of distracting elements on the page. This has been previously discussed and closed in and . However, when it was first discussed was very shortly after the Rust 1.0 release, when there was a large amount of API surface which had not been stabilized for the 1.0 release, and what could be done with stable Rust was fairly limited (for example, no stable proc macros so Serde was only usable on nightly Rust). At this point, most people can use stable Rust for most tasks. There is a lot less reason for the average Rust developer to need to switch to nightly to use unstable standard library features. There is also the open issue that the stable docs of unstable items may be out of date; because these items are unstable, they can change in nightly releases, so not only are they a distraction, but they may be misleading for people who actually try to use them. Between the extra information that most people don't need, distracting UI, potential for being out of date, and time since this was last discussed, I think that it is worth reconsidering this decision and hiding unstable items in the stable docs by default. This would require either providing an opt-in setting for seeing them, or make finding the nightly docs easier. An alternative discussed in the comments is to just make them less visually prominent; unstable items are already rendered at lower contrast and at the bottom on module index pages, but within struct or trait documentation they have big bright warning boxes calling attention to them.
Code change:
#![feature(staged_api)] #![doc(issue_tracker_base_url = "https://issue_url/")] <del> #![unstable(feature="test", issue = "32374")] </del> <ins> #![unstable(feature = "test", issue = "32374")] </ins> // @matches issue_32374/index.html '//*[@class="item-left unstable deprecated module-item"]/span[@class="stab deprecated"]'  //      'Deprecated'

Related discussion:
text: Making them less visually prominent, such as by reducing their contrast and making the warning just plain unstyled text, perhaps in the same place that stability information goes (though see for discussion on that), would help out a lot.
I would prefer this option. One benefit of showing the unstable APIs is that it invites people to test them, so having an opt-in for the curious would be good.
I would prefer an opt-out to an opt-in, that is, keep what we do today, but provide the ability to hide it if desired.
After spending some more time browsing the docs with an eye out for things that are visually distracting or attention grabbing, another option would be to just use a less attention grabbing way to denote unstable and deprecated items. Right now, they each use an extra, brightly colored box that makes them take up more visual space on the screen than stable items. On module index pages, they are actually made less prominent; they are sorted to the bottom, and made lower contrast with the background. This helps make them less attention catching, rather than more attention catching. But when browsing the methods provided on a struct or trait, they come with the big bright warning boxes that make them stand out more. I think I would still have a slight preference for having them hidden by default and just making the nightly docs easier to discover, such as having a version chooser in the header or sidebar, because of the issue mentioned in about docs of unstable items potentially being out of date. But making them less visually prominent rather than more visually prominent would help a lot.
I agree that the better way to solve this is by (perhaps) reducing the prominence of the "nightly-only" box. I don't think we should hide unstable items in the stable rustdoc generated at If someone is reading code that uses an unstable method, there's a good chance they will go to look it up in the stable docs. It would be a frustrating and confusing experience to not be able to find the method in the docs. It's a much better experience to find the method and be informed it's nightly-only / unstable. We probably don't want to reduce the prominence too much, though. If someone's looking for a method to call, it's pretty important that they notice when it's nightly-only. If they're working on a stable crate, that may mean they're not able to use the method at all.
Candidate PR at
Code change:
<ins> // compile-flags: -Z unstable-options --document-hidden-items // test for trait methods with `doc(hidden)` with `--document-hidden-items` passed. #![crate_name = "foo"] // @has foo/trait.Trait.html // @has - '//*[@id="associatedtype.Foo"]' 'type Foo' // @has - '//*[@id="associatedtype.Bar"]' 'type Bar' // @has - '//*[@id="tymethod.f"]' 'fn f()' // @has - '//*[@id="tymethod.g"]' 'fn g()' pub trait Trait { #[doc(hidden)] type Foo; type Bar; #[doc(hidden)] fn f(); fn g(); } // @has foo/struct.S.html // @has - '//*[@id="associatedtype.Foo"]' 'type Foo' // @has - '//*[@id="associatedtype.Bar"]' 'type Bar' // @has - '//*[@id="method.f"]' 'fn f()' // @has - '//*[@id="method.g"]' 'fn g()' pub struct S; impl Trait for S { type Foo = (); type Bar = (); fn f() {} fn g() {} } </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. --I tried this code: I expected to see this happen: Rustdoc does not show in the documentation for . Instead, this happened: ! Since is properly hidden in the documentation for , the link for is broken. : Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Mentoring instructions: when generating trait impls and is not passed, skip all methods where the method in the original trait was hidden. See for a similar change - the relevant code is in .
claim
Code change:
token::EQ => { // x = foo::bar self.bump(); <ins> let path_lo = self.span.lo; </ins> path = ~[self.parse_ident()]; while self.token == token::MOD_SEP { self.bump();

Related discussion:
text: For 'use' items of the form . [I don't see how to assign this to myself, but I have a patch which I will make into a PR soon]
Code change:
"</div><div id="results">" + ret_others[0] + ret_in_args[0] + ret_returned[0] + "</div>"; <del> var search = getSearchElement(); </del> search.innerHTML = output; showSearchResults(search); var tds = search.getElementsByTagName("td");

Related discussion:
text: Enable "Directly go to item in search if there is only one result" option on Settings ! Search an unique item in search box generated by rustdoc, it will lead you to the doc of that item. Click the go back button in browser, the page will change to previous search result and go forward to the doc of the searched item. How to reproduce the issue: Go to std doc: Search for "PhantomData" Click the go back button in browser. : 1.47.0-nightly ( 2020-08-20) cc
Well, you can but since there is only one result, it puts you back haha. (Ok, we can consider it as bug, but it's a funny one)
The single search result page can be elided using the to disappear it, leaving the back button to take you to before the search. I believe this would be the desired behavior?
What about detecting the key release to check if there's a single item and redirect, instead of redirecting after calculating the results?
Code change:
use std::rc::Rc; use std::{i8, i16, i32, i64}; use syntax::abi::{X86, X86_64, Arm, Mips, Mipsel, Rust, RustCall}; <del> use syntax::abi::{RustIntrinsic, Abi}; </del> <ins> use syntax::abi::{RustIntrinsic, Abi, OsWindows}; </ins> use syntax::ast_util::{local_def, is_local}; use syntax::attr::AttrMetaMethods; use syntax::attr;

Related discussion:
text: This should be as simple as passing to the linker for both libraries and executables. However, the necessary relocations are never generated by MinGW or MinGW-w64 for executables so nothing is actually randomized without also passing . The switch is also broken and results in a messed up entry point, but it may not actually be required.
Hi, I found this issue while looking for an old reference, but I thought you might be interested in a possible fix. We needed for Tor's hardening options and after some back and forth settled on a working binutils patch which is here (works for 2.24 and is being submitted upstream shortly): This patch has not been reviewed at all, since no one at Tor feels sufficiently capable. Hopefully the binutils folks will have something to say, but as language developers you might too. (edit: fix link to patch)
We ended up working around it for the time being by doing a dllexport of main in order to force it to output a relocation section, since the executable counts as a library. I would really like to have this fixed properly though so I'll look into it some more when I have time.
Needs to be disabled again due to .
Note that recent binutils may have support for high entropy ASLR. ( was accepted last year. See ) It would be good to check if mingw-w64 would contain the patch when we re-enable ASLR.
Triage: not sure if anything has changed here, but I don't think so.
Triage: same as in 2016
Code change:
<ins> //! Regression test for <https://github.com/rust-lang/rust/issues/100531> #![feature(no_core)] #![no_core] #![crate_name = "export_extern_crate_as_self"] // ignore-tidy-linelength // @is export_extern_crate_as_self.json "$.index[*][?(@.kind=='module')].name" "export_extern_crate_as_self" pub extern crate self as export_extern_crate_as_self; // Must be the same name as the crate already has </ins>

Related discussion:
text: Found via and seems like a different issue than with rustdoc JSON is built labels +A-rustdoc-json +T-rustdoc +I-ICE +requires-nightly +E-needs-mcve
MCVE: ` modify labels: -E-needs-mcve
Code change:
<ins> An inherent `impl` was written on a dyn auto trait. Erroneous code example: ```compile_fail,E0785 #![feature(auto_traits)] auto trait AutoTrait {} impl dyn AutoTrait {} ``` Dyn objects allow any number of auto traits, plus at most one non-auto trait. The non-auto trait becomes the "principal trait". When checking if an impl on a dyn trait is coherent, the principal trait is normally the only one considered. Since the erroneous code has no principal trait, it cannot be implemented at all. Working example: ``` #![feature(auto_traits)] trait PrincipalTrait {} auto trait AutoTrait {} impl dyn PrincipalTrait + AutoTrait + Send {} ``` </ins>

Related discussion:
text: Given the following code (): The current output is: This is rather confusing. It's not immediately clear what the difference between and this working code is (): Since is accepted, the user might be confused why would be considered a nominal type when isn't. The real reason why is an error is because it is an block for . Ideally the output should look like:
It seems like this only happens with auto traits. Regular traits already emit E0116 in this case (): Note that this still happens with auto traits in the same crate, but in this case wouldn't be applicable (): The diagnostic is still confusing in this case and could be rewritten to explicitly point out that is not allowed. modify labels: +D-confusing +F-auto_traits
Code change:
match context { PlaceContext::MutatingUse(_) => ty::Invariant, <del> PlaceContext::NonUse(StorageDead | StorageLive | PlaceMention | VarDebugInfo) => { ty::Invariant } </del> <ins> PlaceContext::NonUse(StorageDead | StorageLive | VarDebugInfo) => ty::Invariant, </ins> PlaceContext::NonMutatingUse( <del> Inspect | Copy | Move | SharedBorrow | ShallowBorrow | UniqueBorrow | AddressOf | Projection, </del> <ins> Inspect | Copy | Move | PlaceMention | SharedBorrow | ShallowBorrow | UniqueBorrow | AddressOf | Projection, </ins> ) => ty::Covariant, PlaceContext::NonUse(AscribeUserTy) => ty::Covariant, }

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. --I tried this code: You need edition 2015 or 2018 to reproduce this. `
Looks to me like the problem is that doesn't realize that a makes the place not dead.
The bug is . is a nonuse, but should get the same treatment as a . I feel obligated to mention that I have repeatedly warned that these bugs are going to happen. We should really stop using in optimizations. It was written for borrowck. (To be clear: I am as much at fault for this as anyone, I originally wrote this code).
I was wondering why always has strangely unhelpful information for optimizations...
Why is this not just a bug in PlaceContext assignment?
See my comment in the PR - in general, my understanding is that the definition of placecontext is what it is because that's what makes sense in some other part of the compiler. If we start changing placecontext now to have the information that's useful to optimizations, I worry we'll just end up making those parts of the compiler buggy
Code 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. pub struct X([u8]); pub static Y: &'static X = { const Y: &'static [u8] = b""; &X(*Y) //~^ ERROR cannot move out //~^^ ERROR cannot move a //~^^^ ERROR cannot move a }; fn main() {} </ins>

Related discussion:
text: This code: produces a helpful error message: But the analogous code using a : gives an error which doesn't point at the binding :
This is fixed today. I'm going to mark as E-needstest since it feels like the kind of thing that's easy to regress on -- a UI test would be best here.
Code 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. pub struct X([u8]); pub static Y: &'static X = { const Y: &'static [u8] = b""; &X(*Y) //~^ ERROR cannot move out //~^^ ERROR cannot move a //~^^^ ERROR cannot move a }; fn main() {} </ins>

Related discussion:
text: Before , this caused an LLVM error Afterwards, this causes an ICE (the rustc size is the correct one):
I am now getting a segfault in LLVM, but I'm uncertain whether that's actually the case, or just a local build problem.
Looks like called on a NULL pointer? Probably some missing check that something is indeed unsized, with actual metadata to go alongside it.
Appears to be fixed today. E-needstest.
It seems that a better diagnostic output is needed:
Why? I believe it's implemented as a feature now (maybe it should be ?).
it's unrelated to this issue, but rather to 's solution, merits at least a clarifying label pointing at the , as otherwise the compiler output makes you look at the following line exclusively, which isn't the cause for the . I know it definitely confused me_ :) Back to this issue, yes, the test in should be .
Code 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. pub struct X([u8]); pub static Y: &'static X = { const Y: &'static [u8] = b""; &X(*Y) //~^ ERROR cannot move out //~^^ ERROR cannot move a //~^^^ ERROR cannot move a }; fn main() {} </ins>

Related discussion:
text: Triage: this no longer ICEs. <details<summaryMeta</summary: rustc 1.16.0 ( 2017-03-10) binary: rustc commit-hash: commit-date: 2017-03-10 host: x86_64-pc-windows-gnu release: 1.16.0 LLVM version: 3.9 </details
Code change:
// take the "else" branch if self.option_loud_drop(6).is_some() // 2 && self.option_loud_drop(5).is_some() // 1 <del> && let None = self.option_loud_drop(7) { // 3 </del> <ins> && let None = self.option_loud_drop(8) { // 4 </ins> unreachable!(); } else { <del> self.print(8); // 4 </del> <ins> self.print(7); // 3 </ins> } // let exprs interspersed

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. --I tried this code: I expected to see this happen: both compiles successfully Instead, this happened: fails to compile <!-- 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
This may have something to do with , as there is something about let_chain drops here as well, but I don't for sure.
The same behaviour happens with an older compiler version. Here goes an example that compiles with . It is not up to me to decide if this behaviour is a blocker that will revert stabilization but in case of such event, I won't have enough free time to investigate and fix stuff in the near future.
Personally and despite the differences, I think that the version is "correct" and the nested version is surprisingly holding a reference of an owned structure () without an explicit bind.
drops the scrutinee after the statement.
cc who have been dealing with dropping stuff related to
Some things that might be helpful to know: The drop order changes for in also had borrow checker impact and made an example compile (see the PR's thread). I'm not a borrow checker expert, so I might be wrong, but this too might be fixed by drop order changes alone. In I'm studying drop order impacts of conditional statements, motivated by let else, but the test that PR adds also includes let chains. There I observed that let chains generally behave drop order wise like when there is a involved, and when it's a bool. I have only studied them regarding the body contained inside though. This table provides a summary of drop orders (disclaimer: it's outdated for let else):
I've locally amended of to add if let chains: And this is the output: Which actually runs counter to what I wrote above, because it predrops.
Code change:
// take the "else" branch if self.option_loud_drop(6).is_some() // 2 && self.option_loud_drop(5).is_some() // 1 <del> && let None = self.option_loud_drop(7) { // 3 </del> <ins> && let None = self.option_loud_drop(8) { // 4 </ins> unreachable!(); } else { <del> self.print(8); // 4 </del> <ins> self.print(7); // 3 </ins> } // let exprs interspersed

Related discussion:
text: It seems that it depends on whether the in the chain is preceded by a or not: if you change the line with to , removing the , you get this: So that rule that I wrote above is not correct, but the underlying behaviour is more complicated. Hmmm...
Thanks
claim
pointed this out to me. It may be motivation to revert the stablization of let-chains on beta. Lets try to ensure we talk about this at Thursday triage label I-compiler-nominated
False alarm; pointed out to me that let-chains is already been marked unstable (on beta and nightly). label: -I-compiler-nominated