jiebi/CodeConvo huggingface dataset:
Change:
<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![crate_type = "lib"] extern { pub fn transmute(); } </ins>

Discussion:
The transmute intrinsic has some special restrictions. The check that implements these does not actually check that the function is a lang item, just looking at the name 'transmute': For defs in the local crate it appears this only happens with foreign functions called 'transmute'. From looking at the code, it looks like the cross-crate case isn't so restricted and will try to check every function called 'transmute'.
(I guess this would be an easy fix after .)
Change:
<ins> error[E0412]: cannot find type `b` in this scope --> $DIR/issue-69401-trait-fn-no-body-ty-local.rs:4:53 | LL |     fn fn_with_type_named_same_as_local_in_param(b: b); |                                                     ^ not found in this scope error: aborting due to previous error For more information about this error, try `rustc --explain E0412`. </ins>

Discussion:
I'm seeing an internal compiler error on the following input (found by ):
Report from : regressed nightly: nightly-2020-02-07
It looks like caused the regression. (The error happens at but not at .) cc
The specific commit where the error starts happening is .
triage: P-high. Removing nomination. Added regression stable-to-nightly tag.
Fixed by
Change:
pub fn stat(p: &Path) -> io::Result<FileAttr> { let p = cstr(p)?; <ins> cfg_has_statx! { if let Some(ret) = unsafe { try_statx( libc::AT_FDCWD, p.as_ptr(), libc::AT_STATX_SYNC_AS_STAT, libc::STATX_ALL, ) } { return ret; } } </ins> let mut stat: stat64 = unsafe { mem::zeroed() }; cvt(unsafe { stat64(p.as_ptr(), &mut stat) })?; <del> Ok(FileAttr { stat }) </del> <ins> Ok(FileAttr::from_stat64(stat)) </ins> } pub fn lstat(p: &Path) -> io::Result<FileAttr> { let p = cstr(p)?; <ins> cfg_has_statx! { if let Some(ret) = unsafe { try_statx( libc::AT_FDCWD, p.as_ptr(), libc::AT_SYMLINK_NOFOLLOW | libc::AT_STATX_SYNC_AS_STAT, libc::STATX_ALL, ) } { return ret; } } </ins> let mut stat: stat64 = unsafe { mem::zeroed() }; cvt(unsafe { lstat64(p.as_ptr(), &mut stat) })?; <del> Ok(FileAttr { stat }) </del> <ins> Ok(FileAttr::from_stat64(stat)) </ins> } pub fn canonicalize(p: &Path) -> io::Result<PathBuf> {

Discussion:
First of all, it now returns an Err with "not available on this platform currently". But I found that there is a system call  available in Linux kernel 4.11, which can get the birth time. As the , the function uses on Unix platforms. But the just never contains . Shouldn't it try when available?
Change:
An unknown "kind" was specified for a link attribute. Erroneous code example: <del> ```ignore (cannot-test-this-because-rustdoc-stops-compile-fail-before-codegen) </del> <ins> ```compile_fail,E0458 </ins> #[link(kind = "wonderful_unicorn")] extern {} // error: unknown kind: `wonderful_unicorn` ```

Discussion:
The below code (in ) has three doc tests: first succeeds as expected. second test fails as expected: the constant would be and there is an attempt to subtract with overflow. third test should succeed as it has the exact same code as the second test but is marked as . However the test fails with the message “Test compiled successfully, but it's marked .” rust /// let works = cf::S::<u32::default(); /// (); /// rust /// let shouldfail = cf::S::<u64::default(); /// (); /// compilefail /// let shouldfail = cf::S::<u64::default(); /// (); ///
This is a consequence of how works. (and ) does the equivalent of (or the same as ), which does not perform all steps of compilation (like codegen and linking). One of the issues tracking this problem is . I'm not sure why rustdoc does not perform the full compilation steps for and .
Change:
def_id: DefId) -> bool { match tcx.item_type(def_id).sty { <del> ty::TyFnDef(def_id, _, f) => { </del> <ins> ty::TyFnDef(def_id, _, _) => { </ins> // Some constructors also have type TyFnDef but they are // always instantiated inline and don't result in a // translation item. Same for FFI functions. if let Some(hir_map::NodeForeignItem(_)) = tcx.hir.get_if_local(def_id) { return false; } <del> if let Some(adt_def) = f.sig.output().skip_binder().ty_adt_def() { if adt_def.variants.iter().any(|v| def_id == v.did) { return false; } } </del> } ty::TyClosure(..) => {} _ => return false

Discussion:
Not on 1.15. cc
Fun note: another bug fixed on my shimmir branch. Not that I really want to merge it to 1.16/1.17.
Minified: I think we should just have the first commit of shimmir to fix this.
triage: P-high
Change:
format!( "{} {}", if empty_where { " where" } else { "," }, <del> obligations.into_iter().collect::<Vec<_>>().join(", ") </del> <ins> obligations.join(", ") </ins> ), Applicability::MaybeIncorrect, );

Discussion:
version 1.44.1 I will be adding an feature as part of , just wanted to confirm these failures are OK to ignore: ~ ~ CC and who wrote the tests, but I guess you may not be responsible for the underlying behavior.
We have adjusted the const test to be endianess-independent in
For the suggestion in we can presort the restrictions so that the output is always consistent.
Change:
// check-pass #![allow(dead_code)] <ins> #![allow(non_camel_case_types)] </ins> // pretty-expanded FIXME #23616 trait Person {

Discussion:
Associated types are types and thus should be capitalized. I think most code also does this. Recently I accidentally didn't capitalize it and was surprised that it doesn't lint for it: I'd expect it to say something. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
checking happens inside , add for , then inspect the kind of inside this checking.
I'd like to put my hand up for this if that's alright? It looks like a good one to get started on. claim
Change:
<ins> // check-pass pub struct Fixed64(i64); pub fn div(f: Fixed64) { f.0 / 0; } fn main() {} </ins>

Discussion:
UPDATE: MCVE can be found . Nightly compilation error due to rustc bug I tried this code: I expected to see this happen: explanation Successful compilation. Instead, this happened: tells to report a bug, see backtrace. : Reproduce with (1st update) <details<summaryBacktrace</summary<p</p</details
cc
Also occured with
I'm getting this when I try to repro: On a side note, are there any cargo feature flags I can pass to cut down on how much stuff is being compiled? Compiling 900 crates to get a repo is quite a lot
Also occured with just now.
mmh try with commit hash ? (for )
updated script:
Yeah, sorry for that. One of the difficulties of working with a big framework like Substrate. I'll see if I can narrow it down more.
That did it! Thank you
Some with the same issue (a different chain also using Substrate) found out that apparently works.
Seems is the cause, marking as .
Here's a smaller repro (at least in terms of how much code is built: 33 crates instead of a few hundred):
just confirmed that it does not occur with
I have a minimal repro:
Wild guess: erases the local before we are able to emit the diagnostic message.
I seem to be getting a similar error again on a more current nightly (). Should I open a new issue or do we just reopen this one?
This is still broken. I'm pretty confused because running the test you in on the shows that it ICEs. Is the test not actually working for some reason? Edit: Does that test need in order to actually check the body of those functions since they are uncalled from ?
Assigning as and removing I-prioritize.
Hi and have either of you had a chance to upgrade to a recently nightly? I just wanted to confirm this is fixed for you.
I've updated to rust version 1.47.0-nightly ( 2020-07-22), and tried compiling the crate which was triggering this ICE (). I no longer encounter an ICE, the crate compiles successfully.
I can confirm is not throwing ICE :+1:
Great, thank you!
Change:
// FIXME(jynelson): this shouldn't go through stringification, rustdoc should just use the DefId directly let self_name = self_id.and_then(|self_id| { <ins> use ty::TyKind; </ins> if matches!(self.cx.tcx.def_kind(self_id), DefKind::Impl) { <del> // using `ty.to_string()` directly has issues with shortening paths </del> <ins> // using `ty.to_string()` (or any variant) has issues with raw idents </ins> let ty = self.cx.tcx.type_of(self_id); <del> let name = ty::print::with_crate_prefix(|| ty.to_string()); debug!("using type_of(): {}", name); Some(name) </del> <ins> let name = match ty.kind() { TyKind::Adt(def, _) => Some(self.cx.tcx.item_name(def.did).to_string()), other if other.is_primitive() => Some(ty.to_string()), _ => None, }; debug!("using type_of(): {:?}", name); name </ins> } else { let name = self.cx.tcx.opt_item_name(self_id).map(|sym| sym.to_string()); debug!("using item_name(): {:?}", name);

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: The link resolves to . Instead, this happened: rustdoc can't resolve the link <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: and <!-- Provide the version you are using that has the regression. --: <!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --
Maybe I shouldn't have used pretty printing after all ... I'll try reverting and see if it helps.
Assigning and removing as in the prioritization working group.
Change:
CompressionProfile::Fast => flate2::Compression::fast(), CompressionProfile::Balanced => flate2::Compression::new(6), CompressionProfile::Best => flate2::Compression::best(), <ins> CompressionProfile::NoOp => panic!( "compression profile 'no-op' should not call `CompressionFormat::encode`." ), </ins> }, )), CompressionFormat::Xz => { let encoder = match profile { <ins> CompressionProfile::NoOp => panic!( "compression profile 'no-op' should not call `CompressionFormat::encode`." ), </ins> CompressionProfile::Fast => { xz2::stream::MtStreamBuilder::new().threads(6).preset(1).encoder().unwrap() }

Discussion:
Right now when doing a local , we first compress the artifacts with max compression ratio, just to immediately unpack them again when installing them to disk. Making the compression level less aggressive or skipping it altogether can probably save 5-10 minutes on an x.py install. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc You probably want to use the gzip'd artifacts which are less intensely compressed.
tbh it seems strange that we're compressing these at all - why not put them into an uncompressed .tar archive when using ?
or even better, copy them directly from the build directory to the install directory without going through a .tar archive first.
claim
Skipping the compressions and archiving in favor of directly copying the artifacts seems like a reasonable solution for . But it requires significant changes to how we currently handle . I'm planning to do a comprehensive review on bootstrapping from all angles(including T-bootstrap issues) and make a roadmap for future development. To avoid conflicts(e.g, if we have improvement ideas on dist/install modules, implementing this might increase the technical debt which will require more effort from the team), I will postpone this task for now and re-prioritize it once we have organized the plans.
Change:
use tempfile::Builder as TempFileBuilder; use std::error::Error; <del> use std::fs::File; </del> <ins> use std::fs::{self, File}; </ins> use std::io::{self, Write}; use std::path::{Path, PathBuf};

Discussion:
Given this code: I get this output from rustc: The most recent archive no longer has the "read" permission bit set for group/world owners. This ended up breaking because our files are built in a container with a different user and aren't then readable outside of the container. There's no particular reason we do this and we can work around this, but I also suspected that the change in permissions here probably wasn't intentional. I think this is due to (cc specifically . I haven't dug too deeply but my guess is that temp files specifically turn off other permission bits
reverted back to the LLVM archive writer to fix another regression. Still I think this issuw should be kept open as a reminder to fix the new archive writer before it becomes the default again.
cc , which also needs to be fixed before relanding the archive writer change. BTW is there a tracking issue for that somewhere? I see the original PR linked to , but it hasn't been reopened.
I have kept all issues that need to be fixed before it can land again in my github notifications. There is currently no tracking issue, but feel free to open one. It did probably be a good idea to ensure no issue is forgotten about.
Change:
} pub fn get_or_default_sysroot() -> Path { <del> match os::self_exe_path() { option::Some(p) => { let mut p = p; p.pop(); p } </del> <ins> // Follow symlinks.  If the resolved path is relative, make it absolute. fn canonicalize(path: Option<Path>) -> Option<Path> { path.and_then(|mut path| match io::io_error::cond.trap(|_| ()).inside(|| fs::readlink(&path)) { Some(canon) => { if canon.is_absolute() { Some(canon) } else { path.pop(); Some(path.join(canon)) } }, None => Some(path), }) } match canonicalize(os::self_exe_name()) { option::Some(p) => { let mut p = p; p.pop(); p.pop(); p } </ins> option::None => fail!("can't determine value for sysroot") } }

Discussion:
On OS X at least, it will think the link itself is the executable, then calculate sysroot based on that. Thanks to kyle for the report.
nominating to change to production ready
accepted for production-ready milestone
triage bump. still annoying.
or could be used to resolve the symlink. Would this issue warrant the badge "E_easy"?
Seems so! Adding the E-easy label.
Note that the relevant code is and it probably needs a check to see whether is a symlink or not.
seems important to fix for polish reasons. Accepted for P-high.
Change:
<ins> // compile-flags: --document-private-items #![feature(inherent_associated_types)] #![allow(incomplete_features)] #![crate_name = "foo"] // @has 'foo/struct.Foo.html' pub struct Foo; // There are 3 impl blocks with public item and one that should not be displayed // by default because it only contains private items (but not in this case because // we used `--document-private-items`). // @count - '//*[@class="impl has-srclink"]' 'impl Foo' 4 // Impl block only containing private items should not be displayed unless the // `--document-private-items` flag is used. /// Private impl Foo { const BAR: u32 = 0; type FOO = i32; fn hello() {} } // But if any element of the impl block is public, it should be displayed. /// Not private impl Foo { pub const BAR: u32 = 0; type FOO = i32; fn hello() {} } /// Not private impl Foo { const BAR: u32 = 0; pub type FOO = i32; fn hello() {} } /// Not private impl Foo { const BAR: u32 = 0; type FOO = i32; pub fn hello() {} } </ins>

Discussion:
cc label +A-docs +A-rustdoc-ui +C-enhancement +T-rustdoc This is technically a regression, but it doesn't feel appropriate to label it as such.
Here is an example of a block that should be hidden when is not passed:
Change:
<ins> pub mod test { pub struct A; pub struct B; pub struct Foo<T>(T); impl Foo<A> { fn foo() {} } impl Foo<B> { fn foo() {} } } fn main() { test::Foo::<test::B>::foo(); //~ ERROR method `foo` is private } </ins>

Discussion:
I got this pretty weird ICE while in the middle of a refactor. I don't know how to turn this into a minimal example, so here's the offending code that reproduces this error:
What version of the compiler are you using?

I made a struct , and made two blocks for and ( and are unit structs.) Each block has a method with same name but different argument count. I accidentally made those methods private. [Link to the playground][playground] [playground]: I expected to get error about privacy, but with that, the compiler panicked. Backtrace: <details</details
A more minimal repro:
Interesting point: in this code, doesn't have method but the compiler reports that it exists but is private. However, with , the compiler reports error correctly.
CC , .
Change:
<ins> // run-pass pub trait Stage: Sync {} pub enum Enum { A, B, } impl Stage for Enum {} pub static ARRAY: [(&Stage, &str); 1] = [ (&Enum::A, ""), ]; fn main() {} </ins>

Discussion:
When compiling my project on the branch "crashing" (which just has a lot of irrelevant things commented out) commenting out this array (and the same similar arrays from the other files in that directory) causes it to not crash. : rustc 1.30.0-nightly ( 2018-09-17) binary: rustc commit-hash: commit-date: 2018-09-17 host: x86_64-pc-windows-msvc release: 1.30.0-nightly LLVM version: 8.0 Backtrace:
Could you create and copy here a minimized example of the problem?
I was able to get this to throw have the same panic If you remove the type from , it will not panic. The length of does not seem to effect it. Should note this is on a slightly newer compiler (just performed rustup update on my current computer before performing this) Backtrace:
No longer reproduces in current stable.
Can confirm, no longer having issues with same implementation.
Change:
use std::os; use std::task::TaskBuilder; <del> // FIXME(#15149) libgreen still needs to be update. There is an open PR for it //               but it is not yet merged. // green_start!(main) </del> <ins> green_start!(main) </ins> fn main() { // If we're the child, make sure we were invoked correctly

Discussion:
For example, this program prints on unix, and on windows:
The appears to be different on windows for both libgreen and libnative.
I believe this happens because the arguments end up being quoted for Windows. Simplest fix would be to drop empty arguments. Thoughts?
(Alternatively, we could quote empty arguments on Unix.)
I would expect the empty arguments to be passed through as significant argument position. I ran into this in cargo because passed on unix but on windows it would try to consume the next argument for the test args. It looks like to fix this we just need to alter to see if the argument is 0-length, and if so we quote it. Libuv already does . I'm investigating a fix for libgreen, it looks like it should be working...
Change:
<ins> #![feature(doc_alias)] #[doc(alias = "true")] pub struct Foo; </ins>

Discussion:
I loaded the std doc at Firefox 77.0.1, then I typed fast for the word "true" (or click this link: ). I expected to see this happen: The search result appears and includes the "true" keyword link. Instead, this happened: No search result was shown. Also in the Firefox console, this was printed after typing the word "true": Version of std docs: 1.46.0-nightly ( 2020-06-21) cc in case you interest.
The type error happened along this line:
It looks like it fails when you have a crate filter selected. Almost certainly caused by (cc
yeah, that's right. I forgot about that detail.
should fix this.
Change:
// (Issue #49588) continue; } <del> if let PatKind::Binding(_, _, ident, None) = fieldpat.pat.kind { </del> <ins> if let PatKind::Binding(binding_annot, _, ident, None) = fieldpat.pat.kind { </ins> if cx.tcx.find_field_index(ident, &variant) == Some(cx.tcx.field_index(fieldpat.hir_id, cx.tables)) { let mut err = cx.struct_span_lint(NON_SHORTHAND_FIELD_PATTERNS, fieldpat.span, &format!("the `{}:` in this pattern is redundant", ident)); <del> let subspan = cx.tcx.sess.source_map().span_through_char(fieldpat.span, ':'); err.span_suggestion_short( subspan, "remove this", ident.to_string(), </del> <ins> let binding = match binding_annot { hir::BindingAnnotation::Unannotated => None, hir::BindingAnnotation::Mutable => Some("mut"), hir::BindingAnnotation::Ref => Some("ref"), hir::BindingAnnotation::RefMut => Some("ref mut"), }; let ident = if let Some(binding) = binding { format!("{} {}", binding, ident) } else { ident.to_string() }; err.span_suggestion( fieldpat.span, "use shorthand field pattern", ident, </ins> Applicability::MachineApplicable ); err.emit();

Discussion:
Code: output: Note that in the attempted fix is incorrect syntax (it ate a colon). Edit: it probably actually isn't. Version info:
thanks for feedback :) it seems a rustfix bug, could you please file a issue there? cc
Will do. Is it intentional that suggests filing a bug in this repo (see the error message), or should that be changed?
This is the correct place to file the issue, it is a bug in . The issue is that the lint is providing a bad suggestion. Either the span needs to encompass the entire binding, or the suggested text needs to be the empty string.
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. fn main() { let a = |r: f64| if r != 0.0(r != 0.0) { 1.0 } else { 0.0 }; //~^ ERROR expected function, found `{float}` } </ins>

Discussion:
My code is about 500 lines long. I'm running up against an assignment deadline, so I don't have time right now to make a minimal demonstration. But if needed I can do so after Thursday, if someone hasn't gotten to it already. Sorry to dump and run. I normally try to be better about bug reports. :/ I expect this to be related to my copy paste error with repeated if clause: EDIT: Removed code, as there is a minimal example below.
Minimal example: Gives output:
I like to check back in on my issues from time to time to ensure that they haven't become invalid. I found that this issue still exists in the 2017/12/11 nightly ().

The following code ICEs on x8664 linux Suspect that it's this line (expecting that a struct with size 8 has 1 field) ICE message: cc
This isn't fixed, example should have had a or a attribute to make sure that the function is exported.
. CC
These "components" are not exactly struct fields, but rather hardware registers. The alignment padding probably triggers an edge case, I'll have to look deeper.

I found out that doesn't work, so I got a bit creative and tried this (reduced example): Which lead to this: It just prints an error on stable (1.17.0): And of course:
I ran into this with declarative macros on
Panics with the same error on 1.18.0 stable now:
Now this works, but it breaks proc-macro derives on the same item (parsing fails). Should I report that bug to a different location? It sort of feels like it's rustc's fault, as it's passing the proc-macro invalid syntax. I think it's odd that a macro can legally expand to invalid syntax...
That sounds a rust-lang/rust problem, yes. Have you filed an issue? I'd love to see a short example of the failure.
I've opened another issue for it:

$ RUST_BACKTRACE=1 rustc $ cat $ rustc --version --verbose
Looks like this was fixed. Output with current nightly as per playground:
Yeah, this was fixed. Marking as E-needstest.