jiebi/CodeConvo huggingface dataset:
Change:
<ins> //@ aux-build:block-on.rs //@ edition:2021 //@ check-pass #![feature(async_closure)] extern crate block_on; fn consume(_: String) {} fn main() { block_on::block_on(async { let x = 1i32; let s = String::new(); // `consume(s)` pulls the closure's kind down to `FnOnce`, // which means that we don't treat the borrow of `x` as a // self-borrow (with `'env` lifetime). This leads to a lifetime // error which is solved by forcing the inner coroutine to // be `move` as well, so that it moves `x`. let c = async move || { println!("{x}"); // This makes the closure FnOnce... consume(s); }; c().await; }); } </ins>

Discussion:
Rustc panicked when I attempted to use async in poll. I wanted to compose an async task inside my custom future :
I believe this is a duplicate of , which I have a local branch to fix but which needs a bit of cleanup first.

<!-- 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 (minimized): I expected to see this happen: Compiles Instead, this happened (): Instead, this happened (latest nightly): ICE Related: Mentioning :wink: Best guess: <details<summaryBacktrace</summary<p</p</details<!-- 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-nightly-to-nightly -regression-untriaged Thanks for investigating! -
Nightly-only features aren't typically regression triaged. I'll look into it soon.
Change:
g } <ins> fn check_and_apply_linkage<'tcx>( cx: &CodegenCx<'_, 'tcx>, attrs: &CodegenFnAttrs, ty: Ty<'tcx>, sym: LocalInternedString, span: Option<Span> ) -> ValueRef { let llty = cx.layout_of(ty).llvm_type(cx); if let Some(linkage) = attrs.linkage { debug!("get_static: sym={} linkage={:?}", sym, linkage); // If this is a static with a linkage specified, then we need to handle // it a little specially. The typesystem prevents things like &T and // extern "C" fn() from being non-null, so we can't just declare a // static and call it a day. Some linkages (like weak) will make it such // that the static actually has a null value. let llty2 = match ty.sty { ty::TyRawPtr(ref mt) => cx.layout_of(mt.ty).llvm_type(cx), _ => { if span.is_some() { cx.sess().span_fatal(span.unwrap(), "must have type `*const T` or `*mut T`") } else { bug!("must have type `*const T` or `*mut T`") } } }; unsafe { // Declare a symbol `foo` with the desired linkage. let g1 = declare::declare_global(cx, &sym, llty2); llvm::LLVMRustSetLinkage(g1, base::linkage_to_llvm(linkage)); // Declare an internal global `extern_with_linkage_foo` which // is initialized with the address of `foo`.  If `foo` is // discarded during linking (for example, if `foo` has weak // linkage and there are no definitions), then // `extern_with_linkage_foo` will instead be initialized to // zero. let mut real_name = "_rust_extern_with_linkage_".to_string(); real_name.push_str(&sym); let g2 = declare::define_global(cx, &real_name, llty).unwrap_or_else(||{ if span.is_some() { cx.sess().span_fatal( span.unwrap(), &format!("symbol `{}` is already defined", &sym) ) } else { bug!("symbol `{}` is already defined", &sym) } }); llvm::LLVMRustSetLinkage(g2, llvm::Linkage::InternalLinkage); llvm::LLVMSetInitializer(g2, g1); g2 } } else { // Generate an external declaration. // FIXME(nagisa): investigate whether it can be changed into define_global declare::declare_global(cx, &sym, llty) } } </ins> pub fn codegen_static<'a, 'tcx>( cx: &CodegenCx<'a, 'tcx>, def_id: DefId,

Discussion:
For example: This can be a little more clearly seen with the IR generated for main: Note the lack of anywhere on .
Triage: this is still true today, though needs to be updated to , and there's now a warning about not being a valid foreign type, which is irrelevant to this particular issue.
claims it repros still.
Updated test code: Still fails to compile with the same errors mentioned in the top post along with the irrelevant invalid foreign type warning mentioned by
Change:
<del> #![allow(nonstandard_style, unused_variables)] </del> <ins> // run-rustfix #![allow(nonstandard_style, unused_variables, unused_mut)] </ins> #![deny(non_shorthand_field_patterns)] struct Foo {

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:
$(foreach target,$(CFG_TARGET),  $(eval $(call ADD_INSTALLED_OBJECTS,$(target)))) <ins> define DEFINE_LINKER ifndef LINK_$(1) LINK_$(1) := $$(CC_$(1)) endif endef $(foreach target,$(CFG_TARGET),  $(eval $(call DEFINE_LINKER,$(target)))) </ins> # The -Qunused-arguments sidesteps spurious warnings from clang define FILTER_FLAGS ifeq ($$(CFG_USING_CLANG),1)

Discussion:
Appears like: Essentially, 'LINK_foo' is empty. Heres a list:
I think this is your issue. (I ran into it myself while doing a build)
Dup of , apparently.
I believe this will be fixed by
Closing as a duplicate.
Change:
CompressionProfile::Fast => f.write_str("fast"), CompressionProfile::Balanced => f.write_str("balanced"), CompressionProfile::Best => f.write_str("best"), <ins> CompressionProfile::NoOp => f.write_str("no-op"), </ins> } } }

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:
PatStruct(..) => match cx.tcx.def_map.borrow().find(&pat.id) { Some(&DefConst(..)) => <del> cx.tcx.sess.span_bug(pat.span, "static pattern should've  </del> <ins> cx.tcx.sess.span_bug(pat.span, "const pattern should've  </ins> been rewritten"), Some(&DefVariant(_, id, _)) => vec!(Variant(id)), _ => vec!(Single)

Discussion:
Minimal test case: If 1024 doesn’t do it for you, try bumping it upwards. ought to do it. Just don’t try numbers like a million or you’ll be waiting a while before it crashes. And if you have anything like systemd-coredump start automatically, it’ll be busy for a while as well… I guess there are a few areas where [T, ..N] is not handled well for large N. (Additional keywords: sized array.)
Running it under GDB shows that it’s flipping back and forth between two functions recursively: Whatever this recursive algorithm is needs to be made non-recursive.
There is a slight difference between this minimal test case, and the original issue . If I reduce the size of the array to 10 bytes in , compilation never completes (no error is raised). If I reduce the size of the array in this test case to 10 bytes, it compiles.
could you try to narrow down the test from , in the manner that chris-morgan has done here, but preserving the behavioral difference you are observing?
I will try my best (this lunchtime), but I only have three hours experience with Rust so far. Every few lines of code written or modified requires 15 minutes of Googling the docs. (This learning curve is still much less steep than Haskell's was.)
feel free to drop by , you’ll get any help you need there quickly.
I was mistaken. I had a subsequent, chained, command on the command line which produced no output and hung. I mistook this for the compiler hanging.
okay, great, thanks for the update! (I now feel better about asking you to do the narrowing rather than attempting to do it myself.) ;)
Change:
} } <ins> #[stable] impl<I> ExactSizeIterator for Fuse<I> where I: ExactSizeIterator {} </ins> impl<I> Fuse<I> { /// Resets the fuse such that the next call to .next() or .next_back() will /// call the underlying iterator again even if it previously returned None.

Discussion:
This should be in : This would require either implementing for (where ), or decoupling and (like in )
Change:
impl Foo for Bar { #[doc(alias = "assoc")] //~ ERROR type X = i32; <del> fn foo() -> Self::X { </del> <ins> fn foo(#[doc(alias = "qux")] _x: u32) -> Self::X { //~^ ERROR </ins> 0 } }

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
ICE only appears since 1.52. label regression-from-stable-to-stable
Better-looking code example Bisection points to
Reading the descriptions, I’d guess most likely , cc
This is indeed caused by since we're now checking parameters unlike before. The issue is in when . The call to panics because there is no name for a param. The question I have is whether we should support params for doc aliases. I didn't find anything in the tracking issue to indicate that it was supposed to be supported, and I personally don't think it makes sense. If we decide to not support doc aliases for params, then it should be an easy change to to error when is a . cc
Doc aliases are only supported for items showing up in doc search, function parameters don't, so in this case, it should error on the doc alias attribute.
Do you want to send a fix or should I?
I'll submit a fix.
Thanks! Please ping me on it (and don't forget to add a test for it too ;) ).
Change:
use sys; use unstable::intrinsics; use util::swap; <ins> use ops::{Add,Sub}; use num::Int; </ins> #[cfg(not(test))] use cmp::{Eq, Ord}; use uint;

Discussion:
This seems like an obvious use case for operator overloading. Probably export them from core by default.
What operators did you have in mind? Things like for ?
yes, and
Not going to work right now, because operators can't be unsafe. Not sure how to change that either. Going to close for now.
At least for , the operator could be "safe" with an unsafe block inside of it. You aren't going to have problems if you do pointer arithmetic until you dereference it, which would be unsafe anyway. In other words, if is safe (which is is), then it seems like pointer arithmetic is also safe.
Yeah, that's true. We consider arithmetic safe, but indexing and dereferencing unsafe. Just having would be convenient.
I'm going to try on work on this. I'll add overloaded and . I'll use as dbaupp suggested on IRC so that it will work with any primitive integer type.
Looks like and for unsafe pointers, can this be closed?
Change:
let bytes = &bytes[prefix_len..]; let mut component_start = 0; <del> let mut bytes_hashed = 0; </del> <ins> // track some extra state to avoid prefix collisions. // ["foo", "bar"] and ["foobar"], will have the same payload bytes // but result in different chunk_bits let mut chunk_bits: usize = 0; </ins> for i in 0..bytes.len() { let is_sep = if verbatim { is_verbatim_sep(bytes[i]) } else { is_sep_byte(bytes[i]) }; if is_sep { if i > component_start { let to_hash = &bytes[component_start..i]; <ins> chunk_bits = chunk_bits.wrapping_add(to_hash.len()); chunk_bits = chunk_bits.rotate_right(2); </ins> h.write(to_hash); <del> bytes_hashed += to_hash.len(); </del> } // skip over separator and optionally a following CurDir item

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 : I expected to see this happen: Different hashes since these represent different paths. Instead, this happened: The hashes are equal. This makes sense for redundant path separators (e.g. ), but not for all path separators. I a test case to the standard library — which fails. The relevant code is probably around which last changed in If I revert that commit, the error persists. It looks like the relevant change is , if I revert that commit the test passes. This was the solution I opted for downstream (in ) before performing this investigation. I tested this on stable (1.79.0), nightly (1.81.0), and on (). Discovered via
is not a cryptographic hash, so it does not promise a collision probability so low that practically all inputs map to distinct outputs. So if the correctness of your program relies on the absence of collisions then it's your program that's wrong, not . There may be some quality-of-implementation argument about avoiding collisions for data patterns that are likely to coexist. I'm not sure if it is the case here, I'll have to think about it. And even if it is then there also is the matter of making such a avoidance fast. The current code is optimized for speed.
I think that's a fair point, but the current implementation already goes out if its way to create equal hashes for paths like and — why is and different? It seems like a very surprising collision for a user to encounter. Thanks for taking a look!
The difference is that is a companion for . If things compare equal then they must hash the same because that's what hashmaps rely on. and do compare equally because normalizes the dot away. Therefore they must hash equally, which is why Hash must spend effort on that. Things comparing inequal does not require the Hash to be different. Instead it's only a matter of quality-of-implementation whether they produce distinct hashes, not a matter of correctness.
That's a great point, thanks for clarifying. I agree this is not a "correctness" problem, but more of a practical consideration for the hashing algorithm.
Change:
/* Unsupported interfaces */ <del> // The runtime interface used by the compiler #[cfg(notest)] pub mod rt; </del> // Private APIs pub mod unstable; // NOTE: Remove after snapshot

Discussion:
This is a public module of things that are exported by core but should not be considered part of the stable library interface. Some don't like the name, and indeed it's name is the opposite of it's form. What should it be renamed to?
Internal, implspecific, dontusethis, unstable, changeable, corehacks?
back?
I like "unstable"; can imagine the future bug report about it changing unexpectedly...
'unstable' sounds good to me to.
Change:
cargo.env("RUSTC_NO_PREFER_DYNAMIC", "1"); // clippy tests need to know about the stage sysroot cargo.env("SYSROOT", builder.sysroot(compiler)); <ins> cargo.env("RUSTC_TEST_SUITE", builder.rustc(compiler)); cargo.env("RUSTC_LIB_PATH", builder.rustc_libdir(compiler)); let host_libs = builder.stage_out(compiler, Mode::Tool).join(builder.cargo_dir()); cargo.env("HOST_LIBS", host_libs); </ins> // clippy tests need to find the driver cargo.env("CLIPPY_DRIVER_PATH", clippy);

Discussion:
branch: master Compiling cargometadata v0.2.3 Compiling clippylints v0.0.166 (file:///home/ryan/git/rust/src/tools/clippy/clippylints) error: :vis fragment specifier is experimental and subject to change (see issue ) --<declarelint macros:1:3 | 1 | ( NAME : ident , desc : expr ) =( | ^^^^^^^^^^^ | = help: add #![feature(macrovismatcher)] to the crate attributes to enable error: :vis fragment specifier is experimental and subject to change (see issue ) --<declarelint macros:1:3 | 1 | ( NAME : ident , desc : expr ) =( | ^^^^^^^^^^^ | = help: add #![feature(macrovismatcher)] to the crate attributes to enable error: aborting due to previous error error: aborting due to previous error error: Could not compile . warning: build failed, waiting for other jobs to finish... error: Could not compile . warning: build failed, waiting for other jobs to finish... error: build failed This failure is expected (see ) Build completed successfully in 1:46:49
Everything is actually fine, as you can see by the last two lines of the log. I hope to remove the error log if the failure is expected in the future, but not sure yet how best to do that.
Is it related to rust-lang-nursery/rust-clippy?