jiebi/CodeConvo huggingface dataset:
Change:
dependencies = [ "cargo_metadata 0.9.0", "if_chain", <del> "itertools 0.8.0", </del> <ins> "itertools 0.9.0", </ins> "lazy_static 1.4.0", "matches", "pulldown-cmark 0.7.0",

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver 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! And nominating for compiler team prioritization.
Change:
- name: install MSYS2 run: src/ci/scripts/install-msys2.sh if: success() && !env.SKIP_JOB <del> - name: install MSYS2 packages run: src/ci/scripts/install-msys2-packages.sh if: success() && !env.SKIP_JOB </del> - name: install MinGW run: src/ci/scripts/install-mingw.sh if: success() && !env.SKIP_JOB

Discussion:
On 2019-10-24 we had a CI outage due to the ca-certificates msys2 package being broken. The hack implemented (:heart:) is to download an older, known good package beforehand and install it after msys2 updated its packages. Once is fixed we should revert the hack, but I think at this point it's worth investing in vendoring msys2 as a whole.
msys2 is using and other tools from archlinux distro. Arch Linux provides per-day official repositories snapshots. User can "pin" to a specific date. I think it is possible to reuse that mechanism to vendoring msys2 as a whole, by providing a mirror of a specific date's version. See here for more descriptions .
that would be nice but msys doesn't remove old packages from their repo so the mirror would be enormous. Search for in , only those packages take dozens of GiB. Also extracting it from archive would make CI a bit faster because you won't be modifying thousands of small files over and over. On Linux that is not a problem but working through cygwin emulation a bit struggles on this part.
No update on this, planning to discuss what to vendor at the all hands.
At the last infra meeting we decided a good step is to move towards using the pre-installed msys2 packages. In theory this is as simple as removing the msys2 installation step and pointing things at the right location on the images in CI.
Change:
<ins> // Regression test for issue #116212. #![feature(never_type)] use std::mem::MaybeUninit; struct Foo { x: u8, y: !, } fn main() { let foo = unsafe { MaybeUninit::<Foo>::uninit().assume_init() }; } </ins>

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
reduced further:
reduced further:
Change:
<ins> error: overly complex generic constant --> $DIR/issue-67945-3.rs:10:13 | LL |       A: [(); { |  _____________^ LL | |         let x: Option<S> = None; LL | | LL | |         0 LL | |     }], | |_____^ blocks are not supported in generic constant | = help: consider moving this anonymous constant into a `const` function = note: this operation may be supported in the future error: aborting due to previous error </ins>

Discussion:
The following ICE's on nightly and beta: <details<summaryBacktrace:</summary</details
Reduced: ICE most likely occurs in: I cannot seem to reproduce this without an , so cc
Reduced even more: (Please include all 3 variants thus far in a regression test.)
I looked into this briefly and found that on this line: has the value: Digging a bit deeper, the generics appear to be empty because of the following lines: I can confirm that adding makes this code compile, so I suspect that this is blocked on .
What would be the consequences of always returning the DefId?
It causes query cycle errors at the moment.
Discussed at T-compiler meeting. Due to all the known examples being compile-time errors, the ICE here does not seem so strong a hazard as to warrant weekly visits during triage. (Certainly failing more gracefully would be great. But its not something we're going to e.g. block a release on.) Downgrading priority to P-medium.
Some relevant examples. This gives an (incorrect) error on stable that does not hold: This ICEs on stable:
Is there a reason why we can't just disallow type parameters from appearing within constants during resolve, like we do for type parameters from outer functions? Obviously const generics/lazy normization willl loosen this rule.
good point, I imagine that might work.
Another variant on this bug:
Triage: The two examples that Centril posted ( and ) are no longer ICEs in the latest nightly. Possibly related to ?
Maybe we should just add tests then?
Sounds good! I'll do later.
Another variant (though likely the same): This gives a different to the original, despite being essentially the same code.
Triage: All the snippets including the original are no longer ICE with the latest nightly:
Change:
} // We need cmake, but only if we're actually building LLVM or sanitizers. <del> let building_llvm = build .hosts .iter() .map(|host| { build.config.llvm_enabled(*host) && build .config .target_config .get(host) .map(|config| config.llvm_config.is_none()) .unwrap_or(true) }) .any(|build_llvm_ourselves| build_llvm_ourselves); </del> <ins> let building_llvm = !build.config.llvm_from_ci && build .hosts .iter() .map(|host| { build.config.llvm_enabled(*host) && build .config .target_config .get(host) .map(|config| config.llvm_config.is_none()) .unwrap_or(true) }) .any(|build_llvm_ourselves| build_llvm_ourselves); </ins> let need_cmake = building_llvm || build.config.any_sanitizers_to_build(); if need_cmake && cmd_finder.maybe_have("cmake").is_none() {

Discussion:
It mentions using download-ci-llvm, but that doesn't help, it requires cmake. The message should probably mention that if possible.
Change:
} } <ins> fn evaluate_array_len(&mut self, bcx: &Builder<'a, 'tcx>, lvalue: &mir::Lvalue<'tcx>) -> ValueRef { // ZST are passed as operands and require special handling // because trans_lvalue() panics if Local is operand. if let mir::Lvalue::Local(index) = *lvalue { if let LocalRef::Operand(Some(op)) = self.locals[index] { if common::type_is_zero_size(bcx.ccx, op.ty) { if let ty::TyArray(_, n) = op.ty.sty { return common::C_uint(bcx.ccx, n); } } } } // use common size calculation for non zero-sized types let tr_value = self.trans_lvalue(&bcx, lvalue); return tr_value.len(bcx.ccx); } </ins> pub fn trans_scalar_binop(&mut self, bcx: &Builder<'a, 'tcx>, op: mir::BinOp,

Discussion:
This code: gives this ICE: Doesn't happen if you use e.g. instead of , or use instead of .
Minimized to:
Fixed in .
Change:
for single_import in &resolution.single_imports { let Some(import_vis) = single_import.vis.get() else { // This branch handles a cycle in single imports, which occurs <del> // when we've previously captured the `vis` value during an import </del> <ins> // when we've previously **steal** the `vis` value during an import </ins> // process. // // For example:

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: inconsistent resolution for an import', 'error: internal compiler error: inconsistent resolution for an import' File: --auto-reduced (treereduce-rust): original: 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: [resolverforlowering_raw] getting the resolver for lowering --
Isn't this example identical to EDIT: oh I see, the PR that closes doesn't actually have this test, so it's possible this is a different ICE.
This one has an additional which indeed causes the ICE to trigger again :laughing:
Regression in nightly-2020-11-09 commit[0] 2020-11-07: Auto merge of - Mark-Simulacrum:debug-asserts, r=pietroalbini commit[1] 2020-11-07: Auto merge of - Mark-Simulacrum:revert-, r=petrochenkov commit[2] 2020-11-08: Auto merge of - petrochenkov:mergetarg, r=Mark-Simulacrum commit[3] 2020-11-08: Auto merge of - lcnr:revert75443, r=nikomatsakis commit[4] 2020-11-08: Auto merge of - m-ou-se:rollup-3jp1ijj, r=m-ou-se commit[5] 2020-11-08: Auto merge of - petrochenkov:visitok, r=Aaron1011

<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: ().isnone()'', 'thread 'rustc' panicked at 'assertion failed: ().isnone()'' File: --auto-reduced (treereduce-rust): original: 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: [resolverforloweringraw] getting the resolver for lowering --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc as this looks 99% like and you fixed that one recently ^^
claim. I will investigate it in my spare time.
Change:
}); let span = DUMMY_SP.apply_mark(mark); <ins> let hidden = cx.meta_list_item_word(span, Symbol::intern("hidden")); let doc = cx.meta_list(span, Symbol::intern("doc"), vec![hidden]); let doc_hidden = cx.attribute(span, doc); </ins> let proc_macro = Ident::from_str("proc_macro"); let krate = cx.item(span, proc_macro,

Discussion:
crates, when compiled with , generate invalid warnings about missing documentation. The following simple crate demonstrates the error. : : I expect this to compile cleanly since there is a crate-level doc comment and a doc comment for the public function. Instead, compiling gives: which makes no sense since line 1 is a comment. Compiler version - latest stable, but fails on yesterday's nightly (2017-05-14) too: :
cc (tracking issue)
I am hitting the same problem. This issue is preventing for proc-macro crates (I haven't found a work around). That's pretty annoying :-/ Rust 1.24.1.
Same here. Is there a fix for this?
Seems to still be happening.
Fails on stable, beta, and nightly still.
On a proc-macro crate in , I'm getting two warnings: and with no line numbers.
shows that the compiler is inserting a with a . I didn't find the code that does the insertion in a very brief search.
So I guess the low-effort fix here is slapping on that ? EDIT: Looks like the code that generates that is ?
Thanks Turns out my working copy wasn't updated like I thought so searching through it didn't work. PR just submitted.
Change:
} }; <ins> // The obligations returned by confirmation are recursively evaluated // so we need to make sure they have the correct depth. for subobligation in impl_src.borrow_nested_obligations_mut() { subobligation.set_depth_from_parent(obligation.recursion_depth); } </ins> if !obligation.predicate.is_const_if_const() { // normalize nested predicates according to parent predicate's constness. impl_src = impl_src.map(|mut o| {

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: This is modification of with the difference being ` Rust OOM'd here after eating at least 20 gb of memory :sweat_smile: I expected to see this happen: explanation NO OOM, maybe an error Instead, this happened: explanation OOM <!-- 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. --:
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
|                  ^ recursive `async fn` | = note: a recursive `async fn` must be rewritten to return a boxed `dyn Future` <ins> = note: consider using the `async_recursion` crate: https://crates.io/crates/async_recursion </ins> error: aborting due to 2 previous errors

Discussion:
We should suggest the use of when writing :
Is there any precedent for the compiler suggesting an external crate?
Yes, for async traits the compiler suggests to use :
As pointed out, we do for . We normally wouldn't recommend one crate over another ("don't play favorites"), but for small, single use, specialized crates that fill a common language "hole" that we might be working towards "plugging", I think it is a much better experience to immediately unblock newcomers than send them to a user forum to ask how to get around the limitation. The current error gives some idea of how to fix this, but not nearly enough for an even moderately knowledgeable Rust user to fix the problem without some searching. That being said, thanks for double checking and mildly pushing back on a potentially controversial and "uncommon" request. That is important for the health of the project.
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. // Check that coercions are propagated through match and if expressions. // pretty-expanded FIXME #23616 #![allow(unknown_features)] #![feature(box_syntax)] pub fn main() { let _: Box<[isize]> = if true { let b: Box<_> = box [1, 2, 3]; b } else { let b: Box<_> = box [1]; b }; let _: Box<[isize]> = match true { true => { let b: Box<_> = box [1, 2, 3]; b } false => { let b: Box<_> = box [1]; b } }; // Check we don't get over-keen at propagating coercions in the case of casts. let x = if true { 42 } else { 42u8 } as u16; let x = match true { true => 42, false => 42u8 } as u16; } </ins>

Discussion:
Put (copies of?) coercematch{,calls} and related tests into run-pass-valgrind. Because our current testing infrastructure is not aggressive enough in checking that tests like this are actually behaving in a sound manner. spawned off of: (I did not attempt this in PR because I wanted to expedite landing the fix for the trans bug.)
clarified the situation to me: even if is not available on a host, the tests in will be run (just without checking them). So resolving this is probably just a matter of moving the tests over. (having said that, I am wary of the risk of injecting usage of will cause a PR to be inadvertently blocked, and thus I still want to wait to fix this until after PR lands.)
Triage: it looks like these two tests are not yet in . This should be easy to do, though which tests exactly are "related" isn't quite clear to me.
Triage: no news.
Change:
<ins> // check-pass use std::marker::PhantomData; pub struct ConcreteError {} pub trait IoBase {} struct X {} impl IoBase for X {} pub struct ClusterIterator<B, E, S = B> { pub fat: B, phantom_s: PhantomData<S>, phantom_e: PhantomData<E>, } pub struct FileSystem<IO: IoBase> { pub disk: IO, } impl<IO: IoBase> FileSystem<IO> { pub fn cluster_iter(&self) -> ClusterIterator<impl IoBase + '_, ConcreteError> { ClusterIterator { fat: X {}, phantom_s: PhantomData::default(), phantom_e: PhantomData::default(), } } } fn main() {} </ins>

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. --I ran into this error when compiling the crate with nightly. I reduced the example down to this, no external deps needed: <!-- 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. --: Compiles without errors on current stable/beta. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Bisected: searched nightlies: from nightly-2022-03-29 to nightly-2022-03-31 regressed nightly: nightly-2022-03-31 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
cc and
Huh how did we miss this on crater? Either way, I know how to fix this. Maybe i'll even get it in before the beta cutoff. But even if not, the fix will be small and easily backported
I ran into the compilation error testing against the branch of fatfs, the latest version released on doesn't trigger the issue.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Still in beta, leaving open until we backport the PR
Backported in
Change:
fn take_send_sync_type<T: Send + Sync>(_: T) {} take_send_sync_type(Command::new("")) } <ins> // Ensure that starting a process with no environment variables works on Windows. // This will fail if the environment block is ill-formed. #[test] #[cfg(windows)] fn env_empty() { let p = Command::new("cmd").args(&["/C", "exit 0"]).env_clear().spawn(); assert!(p.is_ok()); } </ins>

Discussion:
Running with will reproducibly result in Error with OS code 87. if is omitted, it works:
This is expected behavior because it appears that there are basically some required environment variables on Windows to get subprocesses to work. For example and which seems to match as well
Should we ensure that on windows we pass these variables through regardless of being specified? Otherwise, we should at least document this behaviour.
Perhaps yeah. In the past our spawning tended to mirror libuv closely (where it all originated from), but we've since backpedaled a bit from that original design. From a systems-y perspective I would prefer that actually clear the environment, but from a "let's make this ergonomic to use" perspective it'd make more sense to only clear non-required environment variables. I'd probably personally be fine either way
is used to create a new environment block. If is passed for then the returned block will "start from a clean state". If we're going to preserve a few required environment variables, might as well get them straight from the system rather than inheriting them.
Sounds reasonable to me!
I feel like this isn't a change we can make backwards compatibly. What are the considerations that are involved in making this change? Can we make it? We at least need documentation for this inconsistency, but I'm not sure what tag to use for those issues: ?
I think we've got leeway to change the implementation on Windows to preserve some environment variables. If a process can just literally not be spawned without an environment variable then we're basically guaranteed to not break anyone if we start preserving it by default on . Existing working code would override it anyway (as it'd specify a value for the variable)
See the discussion in PowerShell/PowerShell.
The issue is closed, but with the fix related to running process on windows with empty environment that seems not quite exactly as described Using on windows is still unusable in most cases and leads to the cryptic errors like
Can you open a new issue?
Change:
//! take full responsibility for ensuring that safe Rust code cannot evoke //! undefined behavior through it. //! <del> //! Like boxes, `OwnedFd` values conceptually own the resource they point to, //! and free (close) it when they are dropped. </del> <ins> //! Like `Arc`, `OwnedFd` values conceptually own one reference to the resource they point to, //! and decrement the reference count when they are dropped (by calling `close`). //! When the reference count reaches 0, the underlying open file description will be freed //! by the kernel. </ins> //! //! See the [`io` module docs][io-safety] for a general explanation of I/O safety. //!

Discussion:
In std::io, : Note that exclusive ownership of a file descriptor does not imply exclusive ownership of the underlying kernel object that the file descriptor references (also called “file description” on some operating systems). File descriptors basically work like : when you receive an owned file descriptor, you cannot know whether there are any other file descriptors that reference the same kernel object. However, when you create a new kernel object, you know that you are holding the only reference to it. Just be careful not to lend it to anyone, since they can obtain a clone and then you can no longer know what the reference count is! In that sense, is like Arc and is like &'a Arc However the table in std::io::unix::io has the table saying: =Box<This is incorrect and potentially very misleading, because the result of ping a file descriptor creates a new fd which shares the same underlying file structure in the kernel. In particular, for seekable fds they share the current file offset (ie, used by and ) and in some cases, file locking state. (In addition to inode state and underlying file/pipe/etc contents.) The language here should reflect the language in std::io.
cc - I think this is something that should have addressed.
Yeah the model described in doesn't take into account and the indirection layer of "file descriptors" vs "file descriptions". (That was already the case before though, it just became a lot more apparent with that PR.)
Change:
<ins> struct ErrorKind; struct Error(ErrorKind); impl From<nope::Thing> for Error { //~ ERROR failed to resolve fn from(_: nope::Thing) -> Self { //~ ERROR failed to resolve unimplemented!() } } impl From<ErrorKind> for Error { fn from(_: ErrorKind) -> Self { unimplemented!() } } fn main() {} </ins>

Discussion:
(edit: see below) The first error is sensical: But the knock-on errors are not:
Minimized:
Change:
<ins> struct ArpIPv4<'a> { s: &'a u8 } impl<'a> ArpIPv4<'a> { const LENGTH: usize = 20; pub fn to_buffer() -> [u8; Self::LENGTH] { //~^ ERROR: generic `Self` types are currently not permitted in anonymous constants unimplemented!() } } fn main() {} </ins>

Discussion:
EDITED: MCVE is here: I tried to compile the following, which caused the rust compiler to panic. The following compiles just fine: The error message: And running again with verbosity and backtrace: Running nixos 17.09 using rust nightly installed using the mozilla nixpkgs overlay. It's about a month out of date, so I'll check the updates.
This still crashes as of the most recent nightly. Self-contained repro: Mentioning who this assertion in .
That was confusing at first, heh - the multi-line message which doesn't split custom messages on their own line doesn't help at all (can we split it off?). So what's happening is the length expression is using a generic parameter in its outer scope. This hasn't ever been supported, but it's extremely obnoxious to prevent - we could ban in but that already works in some specific situations, so it'd be backwards-incompatible. This problem would get properly fixed once we actually start supporting generics-in-scope for array expressions, and that can't happen without lazy normalization (cc
I'm having the same problem still. succeeds in making the compiler cry about the function call in the array size, but with the compiler panics. Here's my :
exampe ICEs at , cc
Issue is still present on current stable and nightly. Just wanted to add that it only occurs when using a lifetime parameter. example ICEs whereas the following with removed lifetime parameter works fine.
Triage: This is no longer ICE with the latest nightly: