jiebi/CodeConvo huggingface dataset:
Change:
<!-- 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 in nightly-2022-11-18
label regression-from-stable-to-stable
WG-prioritization assigning priority (). label -I-prioritize +P-low

Discussion:
let recovered = self.recover_after_dot(); let token = recovered.as_ref().unwrap_or(&self.token); match token::Lit::from_token(token) { <del> Some(token_lit) => { match MetaItemLit::from_token_lit(token_lit, token.span) { </del> <ins> Some(lit) => { match MetaItemLit::from_token_lit(lit, token.span) { </ins> Ok(lit) => { self.bump(); Some(lit) } Err(err) => { <del> let span = token.span; let token::Literal(lit) = token.kind else { unreachable!(); }; </del> <ins> let span = token.uninterpolated_span(); </ins> self.bump(); report_lit_error(&self.sess, err, lit, span); // Pack possible quotes and prefixes from the original literal into

<ins> macro_rules! f { ($abi:literal) => { extern $abi fn f() {} } } f!("Foo"__); //~^ ERROR suffixes on string literals are invalid fn main() {} </ins>

<ins> error: suffixes on string literals are invalid --> $DIR/lit-err-in-macro.rs:7:4 | LL | f!("Foo"__); |    ^^^^^^^ invalid suffix `__` error: aborting due to previous error </ins>
Change:
<!-- 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

Discussion:
}; // `tcx.normalize_projection_ty` may normalize to a type that still has // unevaluated consts, so keep normalizing here if that's the case. <del> if res != ty && res.has_type_flags(ty::TypeFlags::HAS_CT_PROJECTION) { res.try_super_fold_with(self)? </del> <ins> // Similarly, `tcx.normalize_weak_ty` will only unwrap one layer of type // and we need to continue folding it to reveal the TAIT behind it. if res != ty && (res.has_type_flags(ty::TypeFlags::HAS_CT_PROJECTION) || kind == ty::Weak) { res.try_fold_with(self)? </ins> } else { res }

<ins> // compile-flags: --crate-type=lib -Cdebuginfo=2 // build-pass #![feature(type_alias_impl_trait)] type Debuggable = impl core::fmt::Debug; static mut TEST: Option<Debuggable> = None; fn foo() -> Debuggable { 0u32 } </ins>
Change:
<!-- 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. -- Needs to reproduce, is not enough. <!-- 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
related: This shouldn't compile, but it does:
This is definitely fixed by , I'll add some tests and link this one.
whoops, forgot to add tests. marking as E-needs-test
I wouldn't mind giving this one a try if I'm understanding it correctly. Just add tests for the changes made in , should the original code at the top of this issue compile now and the code in the next comment, shouldn't compile?
correct. Please put some care into which subdirectory in these tests are placed, and make sure they're given at least somewhat descriptive names (i.e. not or anything like that).

Discussion:
<ins> #![feature(ptr_metadata)] // Address issue #112737 -- ICE with dyn Pointee extern crate core; use core::ptr::Pointee; fn unknown_sized_object_ptr_in(_: &(impl Pointee<Metadata = ()> + ?Sized)) {} fn raw_pointer_in(x: &dyn Pointee<Metadata = ()>) { unknown_sized_object_ptr_in(x) //~^ ERROR type mismatch resolving `<dyn Pointee<Metadata = ()> as Pointee>::Metadata == ()` } fn main() { raw_pointer_in(&42) } </ins>

<ins> error[E0271]: type mismatch resolving `<dyn Pointee<Metadata = ()> as Pointee>::Metadata == ()` --> $DIR/ice-with-dyn-pointee-errors.rs:9:33 | LL |     unknown_sized_object_ptr_in(x) |     --------------------------- ^ expected `()`, found `DynMetadata<dyn Pointee<Metadata = ...>>` |     | |     required by a bound introduced by this call | = note: expected unit type `()` found struct `DynMetadata<dyn Pointee<Metadata = ()>>` note: required by a bound in `unknown_sized_object_ptr_in` --> $DIR/ice-with-dyn-pointee-errors.rs:6:50 | LL | fn unknown_sized_object_ptr_in(_: &(impl Pointee<Metadata = ()> + ?Sized)) {} |                                                  ^^^^^^^^^^^^^ required by this bound in `unknown_sized_object_ptr_in` error: aborting due to previous error For more information about this error, try `rustc --explain E0271`. </ins>

<ins> // run-pass #![feature(ptr_metadata)] // Address issue #112737 -- ICE with dyn Pointee extern crate core; use core::ptr::Pointee; fn raw_pointer_in(_: &dyn Pointee<Metadata = ()>) {} fn main() { raw_pointer_in(&42) } </ins>
Change:
<!-- 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. --Minimum example: I have a full project where I was able to consistently cause this error. It seems to be related to the timeout on constant evaluation. For my project which consistently has the error, check . For some reason, annotating with prevents this error. <!-- 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
I just checked - I was able to cause this error to occur in 1.72 nightly but not in 1.70 stable.

Discussion:
/// out an update in your own time. pub LONG_RUNNING_CONST_EVAL, Deny, <del> "detects long const eval operations" </del> <ins> "detects long const eval operations", report_in_external_macro </ins> } declare_lint! {

<ins> //! This test checks that external macros don't hide //! the const eval timeout lint and then subsequently //! ICE. // compile-flags: --crate-type=lib -Ztiny-const-eval-limit // error-pattern: constant evaluation is taking a long time static ROOK_ATTACKS_TABLE: () = { 0_u64.count_ones(); 0_u64.count_ones(); 0_u64.count_ones(); 0_u64.count_ones(); 0_u64.count_ones(); 0_u64.count_ones(); 0_u64.count_ones(); 0_u64.count_ones(); 0_u64.count_ones(); 0_u64.count_ones(); 0_u64.count_ones(); 0_u64.count_ones(); 0_u64.count_ones(); 0_u64.count_ones(); 0_u64.count_ones(); 0_u64.count_ones(); }; </ins>

<ins> error: constant evaluation is taking a long time --> $SRC_DIR/core/src/num/mod.rs:LL:COL | = note: this lint makes sure the compiler doesn't get stuck due to infinite loops in const eval. If your compilation actually takes a long time, you can safely allow the lint. help: the constant being evaluated --> $DIR/timeout.rs:8:1 | LL | static ROOK_ATTACKS_TABLE: () = { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ = note: `#[deny(long_running_const_eval)]` on by default = note: this error originates in the macro `uint_impl` (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to previous error </ins>
Change:
<!-- 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: If you compile this to a WASI library and call the update function from a WASM runtime, then it will query the metadata of the file only during the first call to update. Every other invocation the update function should do nothing. Instead, this happened: The update function seems to refresh the list of preopened directories on every call... and it leaks them. The WASM memory keeps growing, looking like this: ! This likely is because of the way Rust lazily initializes the list of preopened directories through wasi-libc. It probably does it unconditionally, which wasi-libc probably can't handle, so it never frees any memory. The problem also occurs if you have any file system code at all, and it never even gets called: If you compile this code, but never call and instead only , it also keeps leaking the list of preopened directories. The WASM seems to come down to this: with looks too complex. The original C code probably needs to be checked. <!-- 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. --:
cc ?
It seems like this has already been fixed in the upstream wasi-libc: But Rust still uses an old version of wasi-libc:

Discussion:
git clone https://github.com/WebAssembly/wasi-libc cd wasi-libc <del> git reset --hard 4362b1885fd369e042a7c0ecd8df3b6cd47fb4e8 </del> <ins> git reset --hard 7018e24d8fe248596819d2e884761676f3542a04 </ins> make -j$(nproc)  CC="$bin/clang"  NM="$bin/llvm-nm"
Change:
Rust 1.70 build on Solaris sometimes files on some machines: I wonder whether it can do something with: ?!
are you running in parallel? that's not supported on solaris (you made the PR removing the build locking IIRC).
I see it does: . I think I should look once again if it's possible make to use fcntl locking (as it's now in `rustix... You can close the bug. Thank you!
Adding reference to main proble - isn't supported on Solaris due missing syscall).
I'm confused now. I have seen the same error even with (just one ocurance, not two as mentioned above). Also tried to dig closely how locking works and put into some debug prints with process id and lock file name. But later when I was inspecting still running process it didn't have any lock file open. No file descriptor no lock?!
did you clear the cache before running ? if the build directory gets into an inconsistent state we don't recover it automatically. i don't know what's going on with fd-lock, but the file that bootstrap locks is .
Everything is removed before new build...
exactly what command are you running and what is your
If I see it right, lock file is created/opened here: and the file descriptor for the lock file is closed on block exit here: Isn't it mean that locking isn't working even on Linux?
no, it's declared outside the block
Right. Unfortunatelly version 1.70.0 hasn't fix for this (my) regression. And the declaration is still insde the block.
we do not support old versions of rust. the only supported release is the latest stable release.
Isn't version 1.70.0 latest stable version? I'm just curious.
yes, you're right. i'm sorry. i think you should ask someone else for help on this issue. i am having trouble focusing today.
I run: and then: Where on some systems helps to run while on others it breaks it. When I look into the directory where rustc should be present:
i'm not sure why this is looking in . can you verify that exists? i wonder if is a hard-link to and that confuses on solaris.
It does: It's hardling. When I remove the asserion the build passes.
It wasn't true. It just didnt' hit the problem when the code was rebuilt. Now I'm trying following: It must execute sometime deps/bootstrap-[hash] instead of just bootstrap.

Discussion:
.expect("failed to read src/version"); let version = version.trim(); <del> let bootstrap_out = std::env::current_exe() </del> <ins> let mut bootstrap_out = std::env::current_exe() </ins> .expect("could not determine path to running process") .parent() .unwrap() .to_path_buf(); <ins> // Since bootstrap is hardlink to deps/bootstrap-*, Solaris can sometimes give // path with deps/ which is bad and needs to be avoided. if bootstrap_out.ends_with("deps") { bootstrap_out.pop(); } </ins> if !bootstrap_out.join(exe("rustc", config.build)).exists() && !cfg!(test) { // this restriction can be lifted whenever https://github.com/rust-lang/rfcs/pull/3028 is implemented panic!(
Change:
I tried this code: (minimized) I expected to see this happen: It should compile as it does on rust 1.69 and earlier (or at least not ICE). Instead, this happened: The program fails to compile with an ICE (see backtrace). <!-- 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. --: cc gluon issue that reported this (the error is coming from , a fork of ) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
searched nightlies: from nightly-2023-01-01 to nightly-2023-06-19 regressed nightly: nightly-2023-03-29 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
probably or
has a try build and it does reproduce the issue.
The issue still persists on rust 1.72. I have tried to compile example that was provided by author of issue: <details<summaryError log</summary</detailsI have tried to fix compilation issue in gluon_salsa by explicitly specifying lifetimes, but I have ran into ICE.
<a href=""<img src="" /</aI enjoy using gluon and would really like for this to be solved to enable using it with the current compiler. Hopefully this helps

Discussion:
let ty = OpportunisticRegionResolver::new(self).fold_ty(ty); // We do not expect existential variables in implied bounds. <del> // We may however encounter unconstrained lifetime variables in invalid // code. See #110161 for context. </del> <ins> // We may however encounter unconstrained lifetime variables // in very rare cases. // // See `ui/implied-bounds/implied-bounds-unconstrained-2.rs` for // an example. </ins> assert!(!ty.has_non_region_infer()); <del> if ty.has_infer() { self.tcx.sess.delay_span_bug( self.tcx.def_span(body_id), "skipped implied_outlives_bounds due to unconstrained lifetimes", ); return vec![]; } </del> let mut canonical_var_values = OriginalQueryValues::default(); let canonical_ty =

<ins> // check-pass // Regression test for #112832. pub trait QueryDb { type Db; } pub struct QueryTable<Q, DB> { db: DB, storage: Q, } // We normalize `<Q as QueryDb>::Db` to `<Q as AsyncQueryFunction<'d>>::SendDb` // using the where-bound. 'd is an unconstrained region variable which previously // triggered an assert. impl<Q> QueryTable<Q, <Q as QueryDb>::Db> where Q: for<'d> AsyncQueryFunction<'d> {} pub trait AsyncQueryFunction<'d>: QueryDb<Db = <Self as AsyncQueryFunction<'d>>::SendDb> { type SendDb: 'd; } pub trait QueryStorageOpsAsync<Q> where Q: for<'d> AsyncQueryFunction<'d>, { } fn main() {} </ins>

<ins> // check-pass // Another minimized regression test for #112832. trait Trait { type Assoc; } trait Sub<'a>: Trait<Assoc = <Self as Sub<'a>>::SubAssoc> { type SubAssoc; } // By using the where-clause we normalize `<T as Trait>::Assoc` to // `<T as Sub<'a>>::SubAssoc` where `'a` is an unconstrained region // variable. fn foo<T>(x: <T as Trait>::Assoc) where for<'a> T: Sub<'a>, {} fn main() {} </ins>
Change:
see <img width="1728" alt="image" src=""- Arc 0.108.1 () MacOS 13.2.1 (22D68)
this seems like a rustdoc issue, cc ?
( I couldn't quickly reproduce locally yet, need to figure out the arguments first )
Yep, rustdoc issue, I'll transfer it across. This should be improved by just reducing the number of features shown here with , since a lot of them are already active for the module, but that won't help with the compression/decompression modules in the top-level list. !
Actually, rather than this made me realise there's another issue around how we deal with inlined re-exports, opened for that.
It's also kinda related to

Discussion:
display: flex; padding: 3px; margin-bottom: 5px; <ins> align-items: center; vertical-align: text-bottom; </ins> } .item-name .stab { margin-left: 0.3125em;

color: var(--main-color); background-color: var(--stab-background-color); width: fit-content; <del> align-items: center; </del> white-space: pre-wrap; border-radius: 3px; <del> display: inline-flex; vertical-align: text-bottom; </del> <ins> display: inline; </ins> } .stab.portability > code {

("y"), ) // Mobile view set-window-size: (600, 600) // staggered layout with 2em spacing

"//*[@class='desc docblock-short'][text()='a thing with a label']", ("y"), ) <ins> // Ensure it doesn't expand. set-window-size: (800, 800) go-to: "file://" + |DOC_PATH| + "/test_docs/cfgs/index.html" // This part of the tags should not be on the same line as the beginning since the width // is too small for that. compare-elements-position-false: ( "//*[@class='stab portability']/code[text()='appservice-api-c']", "//*[@class='stab portability']/code[text()='server']", ("y"), ) </ins>

}, } } <ins> pub mod cfgs { #[doc(cfg(all( any(not(feature = "appservice-api-c"), not(feature = "appservice-api-s")), any(not(feature = "client"), not(feature = "server")), )))] /// Some docs. pub mod cfgs {} } </ins>
Change:
Related: (i.e. having as an actual would be nice). We use in the kernel to provide the expanded output in outputs/targets. The dependency information is not critical, but the change made our Make target fail (so we need a change on the kernel side), and it would be nice nevertheless to have the dependency information (assuming it is accurate), e.g. we also use it for similar outputs like and .
Bisection seems to lead to commit but I am not sure / cant say if really related. The mentioned issue was opened before that commit was merged :thinking: wdy?
This looks like another symptom of We'll likely keep regressing this by accident without a test. I don't know why was fixed between when it was reported and 1.68
Thanks for fixing this

Discussion:
pretty::print_after_hir_lowering(tcx, *ppm); Ok(()) })?; <ins> // Make sure the `output_filenames` query is run for its side // effects of writing the dep-info and reporting errors. queries.global_ctxt()?.enter(|tcx| tcx.output_filenames(())); </ins> } else { let krate = queries.parse()?.steal(); pretty::print_after_parsing(sess, &krate, *ppm);

<ins> include ../tools.mk all: $(RUSTC) --emit=dep-info -Zunpretty=expanded with-dep.rs $(CGREP) "with-dep.rs" < $(TMPDIR)/with-dep.d -rm $(TMPDIR)/with-dep.d $(RUSTC) --emit=dep-info -Zunpretty=normal with-dep.rs ! test -f $(TMPDIR)/with-dep.d </ins>
Change:
<!-- 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
regressed in
WG-prioritization assigning priority (). label -I-prioritize +P-medium

Discussion:
}; // Check the qualifs of the value of `const` items. <del> // FIXME(valtrees): check whether const qualifs should behave the same // way for type and mir constants. </del> let uneval = match constant.literal { ConstantKind::Ty(ct) <del> if matches!(ct.kind(), ty::ConstKind::Param(_) | ty::ConstKind::Error(_)) => </del> <ins> if matches!( ct.kind(), ty::ConstKind::Param(_) | ty::ConstKind::Error(_) | ty::ConstKind::Value(_) ) => </ins> { None } <del> ConstantKind::Ty(c) => bug!("expected ConstKind::Param here, found {:?}", c), </del> <ins> ConstantKind::Ty(c) => { bug!("expected ConstKind::Param or ConstKind::Value here, found {:?}", c) } </ins> ConstantKind::Unevaluated(uv, _) => Some(uv), ConstantKind::Val(..) => None, };

<ins> // run-pass #![allow(dead_code)] struct Foo(()); const FOO: Foo = Foo(match 0 { 0.. => (), _ => (), }); fn main() { } </ins>
Change:
I tried this code: Compiled fine with , but gives the following error with : My initial attempt at minimizing the case shown that the single-crate equivalent: compiles just fine. : EDIT: Reduced reproduction code. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
(This is a issue that is fixed under and ). cc a nice test case to add.
Why do you think this is a limitation of the current lowering? This should definitely work with the current lowering and ideally shouldn't be dependent on . This is just a plain bug claim
The reason: incorrect eyeballing + complete ignorance of the subject matter, AKA saying stupid things . Even better it it's fixable without requiring the new lowering.
This regressed in , cc I will fix this, but I hope that PR doesn't also regress other things, like the last time the encoding for certain items was reduced without sufficient tests :/

Discussion:
.is_type_alias_impl_trait .set(def_id.index, self.tcx.is_type_alias_impl_trait(def_id)); } <ins> if let DefKind::ImplTraitPlaceholder = def_kind { self.encode_explicit_item_bounds(def_id); } </ins> if tcx.impl_method_has_trait_impl_trait_tys(def_id) && let Ok(table) = self.tcx.collect_return_position_impl_trait_in_trait_tys(def_id) {

fn bar(self) -> Arc<String> { Arc::new(String::new()) } } <ins> fn generic(f: impl Foo) { let x = &*f.bar(); } </ins> fn main() { // Witness an RPITIT from another crate. let &() = Foreign.bar();
Change:
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]

Discussion:
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();

path.push(id); } let path = ast::Path { <del> span: mk_sp(lo, self.span.hi), </del> <ins> span: mk_sp(path_lo, self.span.hi), </ins> global: false, segments: path.move_iter().map(|identifier| { ast::PathSegment {
Change:
The GitHub issue for https://rust- so I can nominate it for the teams. I've noticed that we have many issues inside rust-lang/rust that are completely untriaged with no interactivity. I don't believe that this is due to lack of time, but simply due to lack of organization. I propose that every new issue gets the label. Then, members can see the issues with that label and triage them. That includes labeling the issues and maybe replying to them if there's a specific request, for example answering a question or asking for a reproduction. Ideally triage is done by someone with knowledge in the issue's area but that's of course not a hard requirement. The person can then just remove the label. The label can also be settable via rustbot so anyone can do this. I'm confident that we'd have enough time to triage all issues with that labeling system (I would certainly participate, as I've been doing for a while now). I'm not entirely sure about the best process for deciding this. The reception on Zulip was positive, but I want to make sure that everyone here is on aware and on board. Given the shared team ownership of this repo I'm going to nominate this issue for the three major teams, compiler, libs and rustdoc (rustdoc doesn't have a nomination label apparently, so I'll just here :D) . If they all agree with the change, we can implement it (by using the triagebot feature I : ).
cc
Sounds good. Libs team is on board.
:+1:
Discussed in T-compiler meeting on Zulip (): looks like a really good idea. label -I-compiler-nominated
it's working!
I think we shouldn't add <kbdneeds-triage</kbdif it's a tracking issue. What's your opinion? IIUC, this can be accomplished by
sounds good

Discussion:
"regression-*", "perf-*", "AsyncAwait-OnDeck", <ins> "needs-triage", </ins> ] [glacier]

[autolabel."S-waiting-on-review"] new_pr = true <ins> [autolabel."needs-triage"] new_issue = true </ins> [autolabel."WG-trait-system-refactor"] trigger_files = [ "compiler/rustc_trait_selection/src/solve",