jiebi/CodeConvo huggingface dataset:
Change:
} pub fn cargo_clippy_cmd(&self, run_compiler: Compiler) -> Command { <del> let initial_sysroot_bin = self.initial_rustc.parent().unwrap(); // Set PATH to include the sysroot bin dir so clippy can find cargo. // FIXME: once rust-clippy#11944 lands on beta, set `CARGO` directly instead. let path = t!(env::join_paths( // The sysroot comes first in PATH to avoid using rustup's cargo. std::iter::once(PathBuf::from(initial_sysroot_bin)) .chain(env::split_paths(&t!(env::var("PATH")))) )); </del> if run_compiler.stage == 0 { // `ensure(Clippy { stage: 0 })` *builds* clippy with stage0, it doesn't use the beta clippy. let cargo_clippy = self.build.config.download_clippy(); let mut cmd = Command::new(cargo_clippy); <del> cmd.env("PATH", &path); </del> <ins> cmd.env("CARGO", &self.initial_cargo); </ins> return cmd; }

Discussion:
Previously, clippy was using from , but since , it now prioritizes checking first. We can now set path into and avoid appending it to the chain. In the bootstrap, we have this piece of code which adds into . As indicated by the FIXME note, wasn't merged at the time. Now that we can do so, set instead of and remove the FIXME note. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
There's more weird stuff going on here... On Windows, is PATH, so this sets the PATH and then immediately overwrites it again with a different value...?!? This almost looks like it may want to call or . It's not quite equivalent though. Unfortunately there are no comments explaining why it does what it does... Cc who wrote that code, but it's been two years so not sure if they remember.^^
Yep, sorry, absolutely no clue what that code is meant to do. It's very likely that I copied that from somewhere else during the initial stages of "try everything and see if any of it works", or copied some part of that, and eventually modified to set . I have also unfortunately forgotten all of the context of the bootstrap code here, how it's meant to flow, and what it's meant to set for other programs, so I will not be of any help here :c I will try to check my messages with jyn, who i was talking to a lot about this at the time, and trying many things at their suggestion, to see if I can find any useful history.
Change:
} #[cfg(test)] <del> mod tests { </del> <ins> mod test { </ins> use super::*; #[test]

Discussion:
The code example at should be corrected changing into .
nice catch!
Should this instance be , or should everything else be instead? Judging from , it looks like is more common. Granted, half of it is alexcrichton, but still ;-) Incoming PR to that effect.
Oh, really now?
I actually vote for everything else to be .
Aw, shoot. From some more grepping, the style guide and the language reference both refer to . Going with that.
Ok but... to me it doesn't make sense that we use and then we name the folder , as they both can contain multiple tests...
/me considers giving Steve a choose-your-own-adventure pair of pull requests.
Change:
} match def { <del> Def::Mod(_) | Def::ForeignMod(_) | Def::Enum(..) | Def::TyAlias(..) => { </del> <ins> Def::Mod(_) | Def::ForeignMod(_) | Def::Enum(..) => { </ins> debug!("(building reduced graph for external crate) building module {} {}", final_ident, is_public);

Discussion:
Code that compiles fine with rustc is causing an internal compiler error: unexpected panic with rustdoc. I tried this code (): The second line is essentially a typo, which can happen if used to be an Enum for instance. Again, the following works fine (although I'm not sure why, can you even add anything to the namespace?): However, if I run: I get the error: This actually happened on a version of a package already pushed to (hdf5-sys 0.3.0), so anything that depends on the erroneous version and runs will see this error. Run on . Backtrace:
This is easy to fix in rustdoc, but should this even compile?
Whoa kinda crazy... cc (resolve weridness, longstanding though!)
Change:
/// assert!(handle.join().is_err()); /// assert_eq!(INIT.is_completed(), false); /// ``` <del> #[unstable(feature = "once_is_completed", issue = "54890")] </del> <ins> #[stable(feature = "once_is_completed", since = "1.44.0")] </ins> #[inline] pub fn is_completed(&self) -> bool { // An `Acquire` load is enough because that makes all the initialization

Discussion:
Implemented in
The documentation needs to be made slightly more strict. For example: Should be replaced with The distinction is important, because at the exact moment this function returns might already be executed/resolved, without it necessarily happening “immediately after”. To avoid people shotgunning their feet off, I would suggest to add some guidance on how this should be used. For example, doing something useful based on this function returning a is somewhat likely to be a bug. And yet, examples do not really result in such an impression.
CC for nagisa’s comment above.
It's been 9 months since this was implemented. Can this be stabilized now?
Is there anything preventing this method from being stabilized? It looks like there was some bikesheding in but it's now been just past a year since initial adoption.
Note that I am personally no longer directly interested in having this method: in , I ended-up copy-pasting the whole of anyway. That said, this does look like straightforward addition, which allows to do more with the thing, without actually expanding it's surface area greatly.
Change:
debug_assert!(is_aligned_and_not_null(src), "attempt to copy from unaligned or null pointer"); debug_assert!(is_aligned_and_not_null(dst), "attempt to copy to unaligned or null pointer"); <del> #[cfg(not(miri))] </del> debug_assert!(!overlaps(src, dst, count), "attempt to copy to overlapping memory"); copy_nonoverlapping(src, dst, count) }

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. 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! cc the PR reviewer, and -- nominating for prioritization.
Change:
cargo } else { config.download_beta_toolchain(); <del> config.out.join(config.build.triple).join("stage0/bin/cargo") </del> <ins> config .out .join(config.build.triple) .join("stage0") .join("bin") .join(exe("cargo", config.build)) </ins> }; // NOTE: it's important this comes *after* we set `initial_rustc` just above.

Discussion:
I tried this with Rust 1.66.0, simplified from my build for Fedora: I expected to see this happen: passing tests Instead, this happened: 20 failures, all of this sort: My stage0 should be using . It most recently worked on: Rust 1.65.0 : I bisected this to , commit , which stopped using and environment variables when building a . <details<summaryBacktrace</summary<p</p</details modify labels: +regression-from-stable-to-stable -regression-untriaged +A-bootstrap <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
FYI we had the same problem on Debian, worked around with a custom patch:
Change:
assert_eq!(socket_path.try_exists().unwrap(), true); assert_eq!(socket_path.metadata().is_ok(), true); } <ins> #[cfg(windows)] #[test] fn test_hidden_file_truncation() { // Make sure that File::create works on an existing hidden file. See #115745. let tmpdir = tmpdir(); let path = tmpdir.join("hidden_file.txt"); // Create a hidden file. const FILE_ATTRIBUTE_HIDDEN: u32 = 2; let mut file = OpenOptions::new() .write(true) .create_new(true) .attributes(FILE_ATTRIBUTE_HIDDEN) .open(&path) .unwrap(); file.write("hidden world!".as_bytes()).unwrap(); file.flush().unwrap(); drop(file); // Create a new file by truncating the existing one. let file = File::create(&path).unwrap(); let metadata = file.metadata().unwrap(); assert_eq!(metadata.len(), 0); } </ins>

Discussion:
Reported on discord, using will fail on Windows if the file is hidden. This also affects methods like or that open the file the same way. The reason for this is that we use , which has : So to make it work the caller needs to match the requested attributes to the existing attributes at the time of opening. It was suggested we could instead use and then manually truncate the file using to zero.
Manually truncating would require also clearing the alternate data streams too, right? And it would presumably stop erroring if another process still has the file open and instead corrupt the file fron the view of the other process.
No? The proposed solution would work the same was as in the case where the file already exists. Which we use for .
Right, got confused with .
Change:
] [[package]] <ins> name = "object" version = "0.29.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "21158b2c33aa6d4561f1c0a6ea283ca92bc54802a93b263e910746d679a7eb53" dependencies = [ "crc32fast", "hashbrown 0.12.0", "indexmap", "memchr", ] [[package]] </ins> name = "odht" version = "0.3.1" source = "registry+https://github.com/rust-lang/crates.io-index"

Discussion:
When compiling for , the resulting binaries should have the OS/ABI () field in the ELF header set to Standalone () as per the LLVM target, which it did before . Now, it is set to "UNIX - System V", which I only tested on Linux. identified the introduction of synthetic object files for exported symbols from to have changed this: I did not have a deep dive into the code yet, but I assume the synthetic object file has the host's OS/ABI, which is prevalent over the other OS/ABI. do you have any insight? Related:
Hmm, the crate sets to , which seems to be an alias of . Unfortunately currently crate provide no ways to set this field, so to fix this I suppose some postprocessing of the generated ELF file would be needed. I am surprised that this doesn't show up earlier, given that exactly the same routine is used to create rmeta files. Does hermit not support dylibs?
Ah, yes, sets the OS/ABI here: . I think there are three possibilities: proper support for setting OS/ABI in . This would probably take a lot of effort. before passing it to in This can be done quite easily. the synthetic object file after (?) the real ones. I think lld infers the OS/ABI from the first proper input object file, if I am reading this correctly:  For 1 and 2 we would need to know the proper OS/ABI from the real object files though. I am not sure how easy that would be to come by. What do you think? Hermit is a unikernel, which is linked statically to the application. There is no support for dynamic libraries. A similar problem occurs when using though (). This issue was closed, because we did not need anyways.
Here's how LLVM determines what OSABI to use: We could look at and use the same logic to determine the OSABI. The synthetic object can be placed after real object files (it only needs to be linked before any libraries), but assuming the linker only looks at the first object file sounds a bit hacky. cc what's your take on this issue?
object-rs has only recently been taught to set expected by some MIPS targets (). In think we can teach object-rs to set too, and then just set it, if some linker expects it.
All right.

Thanks for the quick feedback. I'll cook something up in the coming days.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
I opened , but first the necessary changes in have to be released.
Change:
# Next, download the NetBSD libc and relevant header files mkdir netbsd <del> curl https://ftp.netbsd.org/pub/NetBSD/NetBSD-7.0/amd64/binary/sets/base.tgz |  </del> <ins> # originally from: # https://ftp.netbsd.org/pub/NetBSD/NetBSD-7.0/amd64/binary/sets/base.tgz curl https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror/2017-01-16-netbsd-base.tgz |  </ins> tar xzf - -C netbsd ./usr/include ./usr/lib ./lib <del> curl https://ftp.netbsd.org/pub/NetBSD/NetBSD-7.0/amd64/binary/sets/comp.tgz |  </del> <ins> # originally from: # https://ftp.netbsd.org/pub/NetBSD/NetBSD-7.0/amd64/binary/sets/comp.tgz curl https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror/2017-01-16-netbsd-comp.tgz |  </ins> tar xzf - -C netbsd ./usr/include ./usr/lib dst=/usr/local/x86_64-unknown-netbsd

Discussion:
failure: Needs some retries here as well cc https://travis-
I'm also seeing problems when resolving with what I assume is my ISP's DNS server, but little to no problems resolving with Google's 8.8.8.8 DNS. Maybe we could configure Travis to use that? This could be (and I assume it is) a temporary malfunction.
We also should NOT be hitting the netbsd’s poor ftp server with every single build for 50MB of data.
Change:
<ins> #! // check-pass // ignore-tidy-end-whitespace 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:
_a = 0; //~ ERROR unnecessary parentheses around assigned value _a += 1; //~ ERROR unnecessary parentheses around assigned value <ins> let mut _a = 3; //~ ERROR unnecessary parentheses around pattern let mut _a = 3; //~ ERROR unnecessary parentheses around pattern let mut _a = 3; //~ ERROR unnecessary parentheses around pattern let _a = 3; //~ ERROR unnecessary parentheses around pattern let _a = 3; //~ ERROR unnecessary parentheses around pattern let _a = 3; //~ ERROR unnecessary parentheses around pattern </ins> let _a = baz!(3, 4); let _b = baz!(3); }

Discussion:
Rustc suggests incorrect fixes for #[warn(unusedparens)] for these patterns. No response Rustc version: (the same issue with the stable 1.73.0 rustc). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Change:
<ins> // Check that `unused_lifetimes` lint doesn't duplicate a "parameter is never used" error. // Fixed in <https://github.com/rust-lang/rust/pull/96833>. // Issue: <https://github.com/rust-lang/rust/issues/72587>. #![warn(unused_lifetimes)] struct Foo<'a>; //~^ ERROR parameter `'a` is never used fn main() {} </ins>

Discussion:
The following code: gives the following output: The "unused lifetimes" warning is redundant - not using a lifetime parameter is a hard error, so the warning gives no additional information.
Note that this lint still makes sense for functions: But then running clippy on the following looks dumb (the lints are redundant): I don't really know the compiler internals, but should this lint just skip structs ? (is that even possible ?)
label +E-needs-test This was fixed in but no test was for nonduplication.
Change:
}); } <del> let path = if trees.is_empty() && !prefix.segments.is_empty() { </del> <ins> // Condition should match `build_reduced_graph_for_use_tree`. let path = if trees.is_empty() && !(prefix.segments.is_empty() || prefix.segments.len() == 1 && prefix.segments[0].ident.name == kw::PathRoot) { </ins> // For empty lists we need to lower the prefix so it is checked for things // like stability later. let res = self.lower_import_res(id, span);

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
Regression from
Fixed in
Change:
LL | /// ```text |        ++++ <del> warning: 12 warnings emitted </del> <ins> warning: could not parse code block as Rust code --> $DIR/invalid-syntax.rs:103:5 | LL |   /// ``` |  _____^ LL | | /// fn wook_at_my_beautifuw_bwaces_plz() {); LL | | /// ``` | |_______^ | = note: error from rustc: mismatched closing delimiter: `)` help: mark blocks that do not contain Rust code as text | LL | /// ```text |        ++++ warning: 13 warnings emitted </ins>

Discussion:
I have created which reliably reproduces the internal compiler error on my system. The readme in that crate includes version as well as from inside and outside the repo which has a . This is recreated with: with the dependencies from my original crate into : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Note, changing to enables to succeed with version: -and:
claim
I'm also getting a similar error but mine doesn't resolve by changing in . More info:
This issue here is caused by nom as well. The fix is pretty simple, I should be able to open up the PR today.
Change:
<ins> error[E0038]: the trait `Bar` cannot be made into an object --> $DIR/issue-48027.rs:6:6 | LL |     const X: usize; |           - the trait cannot contain associated consts like `X` ... LL | impl dyn Bar {} |      ^^^^^^^ the trait `Bar` cannot be made into an object error[E0283]: type annotations needed: cannot resolve `_: Bar` --> $DIR/issue-48027.rs:3:32 | LL |     const X: usize; |     --------------- required by `Bar::X` LL |     fn return_n(&self) -> [u8; Bar::X]; |                                ^^^^^^ error: aborting due to 2 previous errors Some errors have detailed explanations: E0038, E0283. For more information about an error, try `rustc --explain E0038`. </ins>

Discussion:
Minimal example:
can you reproduce?
I can try, this is from Mar 2nd so not related to my recent changes right?
yes it fails for me with both stable rust 1.25 and the latest nightly rustc 1.27.0-nightly ( 2018-04-11). It's not failing in a part of typeck that I'm familiar with but I'll have a look sometime and see if it makes any sense to me.
Yes this is unrelated to that PR (I think there isn't a nightly including it yet). But since this is related to I thought you might want to take a look.
I started expanding the minimal example so that it didn't depend on nalgebra, it has expanded into quite a lot of code This example is enough to break the compiler but doesn't compile if the ICE is fixed (e.g. if the is commented out). For it to compile it still needs some external dependencies. It appears to be the associated type that is hitting the ICE.
Yeah 's example is huge. Maybe he doesn't know that minimal examples should have no dependencies. if you don't provide minimal examples in bug reports (that is: no dependencies; they should compile in the play ground) they'll take much longer than necessary to fix.
I understand. I'm a relative beginner to rust, so it would take quite a lot of time for me to figure out how to make a more minimal example. I am able to work around this issue in my own code, so it's not that important to me, but I figured it might be easy for someone more experienced to spot what was going wrong. If you don't think it's worth the effort to investigate further, I have no problem with you closing this until a more simple manifestation is discovered.
I've reduced it to the following ():
It's no longer reproduced an ICE on the latest nightly, it seems from 1.38.0. marked as E-needstest
Change:
- env: IMAGE=x86_64-gnu-make - env: IMAGE=x86_64-gnu-llvm-3.7 ALLOW_PR=1 RUST_BACKTRACE=1 - env: IMAGE=x86_64-musl <ins> - env: IMAGE=x86_64-gnu-distcheck </ins> # OSX builders - env: >

Discussion:
The process of creating the tarballs doesn't include .gitignore files from src/vendor. This results in a missmatched hash failure when building with vendoring enabled. Hoping to switch to rustbuild with the next rust release! FYI: I'd be happy with the vendoring happening during the create tarball process, having enormous vendoring commits in the git history is ugly... !
Needs to be fixed for 1.15.
cc
Seems like the vendoring process should include a sanity check that the vendored sources hash correctly.
Fixed in
Things move fast around here. Awesome thanks!
Change:
use cc::windows_registry; use rustc_hir::def_id::{CrateNum, LOCAL_CRATE}; <del> use rustc_metadata::{find_native_static_library, try_find_native_static_library}; </del> <ins> use rustc_metadata::{ find_native_static_library, try_find_native_dynamic_library, try_find_native_static_library, }; </ins> use rustc_middle::bug; use rustc_middle::middle::dependency_format::Linkage; use rustc_middle::middle::exported_symbols;

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. --Hi all, I'm coming from to report an inconsistency in how Rust passes library names to Visual Studio's . In the project, which is driven through Meson, I expected all libraries to be found correctly. Instead, I get an error of library not found at linking time. This is caused by the following snippet of code. The above snippet hardcodes the convention when passing import or static libraries' names. However, this is not consistent with , which is already handled correctly in a separate portion of the Rust compiler: The result of the above is that Rust, under MSVC, will happily put together and , but will fail utterly when a is demanded under the present set of circumstances. This is the other half required to completely address the issue in -- I tried working around this by inserting plus setting the correct file name, as shown in , but it returns an error: This is already known and was never addressed: <!-- 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<summaryBacktrace of the big linker error</summary<p</p</details
Any update on this issue?
I see you have done quite a bit of work here, thank you! Is there anything I can do to help move this forward? I can try to build this custom branch and test if it works?
Apologies, I now see the relevant issue is already being worked on!