jiebi/CodeConvo huggingface dataset:
Change:
<ins> #![crate_type = "lib"] #[cfg(overflow_checks)] //~ ERROR `cfg(overflow_checks)` is experimental pub fn cast(v: i64)->u32{ todo!() } </ins>

Discussion:
An enhancement request discussed here: (That thread also contains a hacky solution by Yandros). I propose to add a config like this: #[cfg(overflow_checks)] I would like to use it to enable/disable lines of code that perform safe unsafe "as" casts replacing them with casts when I compile with debug builds or with release builds compiled with "-C overflow-checks".
modify labels: C-enhancement
label A-attributes T-compiler
I’d also be interested in this.
Tracking issue:
Change:
use rustc_middle::ty::{ self, suggest_constraining_type_param, Ty, TyCtxt, TypeFoldable, TypeVisitor, }; <ins> use rustc_span::source_map::Spanned; </ins> use rustc_span::symbol::{sym, Ident}; use rustc_span::Span; use rustc_trait_selection::infer::InferCtxtExt;

Discussion:
Code: Playground: Error message: Somehow, in one case this in the expression is unsigned, but in the other case it is signed and everything is fine. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
For the compiler has to suggest to replace it with . The compiler should also suggest to replace with , to remove some hard "as" casts from the code.
claim
I think this is more appropriate as a clippy lint, opened
Change:
if !check && paths.is_empty() { match get_modified_rs_files(build) { Ok(Some(files)) => { <ins> if files.len() <= 10 { for file in &files { println!("formatting modified file {file}"); } } else { println!("formatting {} modified files", files.len()); } </ins> for file in files { <del> println!("formatting modified file {file}"); </del> ignore_fmt.add(&format!("/{file}")).expect(&file); } }

Discussion:
Today I synchronized my local version of the rust repo, made a few changes and formatted. This prints: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is a known issue, it means that you have a remote to the rust-lang repo that is outdated. The 35k lines likely means that it is at least behind the test move. Does running (replace with the remote name if different) fixes it ?
Maybe we should remove these logs?
There is the same problem if you created lots of file in the formatted directories, but did not track them in git: It will print the name of all of these.
I think we should avoid printing the names of the files if there are more than 10 (or whatever number). That would avoid all similar issues.
claim
Hi! May I know if you're still working on this issue?
Change:
|              ^ error: unreachable pattern <del> --> $DIR/exhaustiveness-unreachable-pattern.rs:89:15 </del> <ins> --> $DIR/exhaustiveness-unreachable-pattern.rs:88:19 | LL |                 | false) => {} |                   ^^^^^ error: unreachable pattern --> $DIR/exhaustiveness-unreachable-pattern.rs:96:15 </ins> | LL |             | true) => {} |               ^^^^ error: unreachable pattern <del> --> $DIR/exhaustiveness-unreachable-pattern.rs:95:15 </del> <ins> --> $DIR/exhaustiveness-unreachable-pattern.rs:102:15 </ins> | LL |             | true, |               ^^^^ <del> error: aborting due to 18 previous errors </del> <ins> error: aborting due to 19 previous errors </ins>

Discussion:
The match remains exhaustive with highlighted pattern removed, but it does not produce any warnings: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I know where the problem comes from: this bit of code tries to handle unreachable sub-or-patterns diagnostics, but it's a bit of a hack. What remains is to come up with a better solution. claim
Change:
var isModule = hasClass(document.body, "mod"); if (!isModule) { <del> block("primitive", "Primitive Types"); block("mod", "Modules"); block("macro", "Macros"); block("struct", "Structs"); block("enum", "Enums"); block("union", "Unions"); block("constant", "Constants"); block("static", "Statics"); block("trait", "Traits"); block("fn", "Functions"); block("type", "Type Definitions"); block("foreigntype", "Foreign Types"); block("keyword", "Keywords"); block("traitalias", "Trait Aliases"); </del> <ins> block("primitive", "primitives", "Primitive Types"); block("mod", "modules", "Modules"); block("macro", "macros", "Macros"); block("struct", "structs", "Structs"); block("enum", "enums", "Enums"); block("union", "unions", "Unions"); block("constant", "constants", "Constants"); block("static", "static", "Statics"); block("trait", "traits", "Traits"); block("fn", "functions", "Functions"); block("type", "types", "Type Definitions"); block("foreigntype", "foreign-types", "Foreign Types"); block("keyword", "keywords", "Keywords"); block("traitalias", "trait-aliases", "Trait Aliases"); </ins> } // `crates{version}.js` should always be loaded before this script, so we can use

Discussion:
In rustdoc sidebars, most headings are clickable links. For instance, "Required Methods" and "Implementors" in the sidebar of However, the headings under "Other items in..." are not clickable. We should link those to the appropriate subheading on the module page. That allows the user to see a more verbose listing of items in the module, since each one has a description alongside it. <img width=150 src="https://user-"<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
So, for instance, sidebar heading should lead ?
claim
Yes, that's correct.
By the way be aware this will conflict with Resolving the conflict should be pretty easy though.
Thanks
any progress on this? I'd like to get it landed before the beta cut, so we have a consistent UI where headings in the sidebar are clickable.
sorry, i couldn't make time last ,i will unassign me, thanks.
Change:
err.help("you could instead create a new `enum` with a variant for each returned type"); } <del> fn is_return_ty_unsized<'a>(&self, fcx: &FnCtxt<'a, 'tcx>, blk_id: hir::HirId) -> bool { if let Some((_, fn_decl, _)) = fcx.get_fn_decl(blk_id) && let hir::FnRetTy::Return(ty) = fn_decl.output && let ty = fcx.astconv().ast_ty_to_ty( ty) && let ty::Dynamic(..) = ty.kind() { return true; </del> <ins> /// Checks whether the return type is unsized via an obligation, which makes /// sure we consider `dyn Trait: Sized` where clauses, which are trivially /// false but technically valid for typeck. fn is_return_ty_definitely_unsized(&self, fcx: &FnCtxt<'_, 'tcx>) -> bool { if let Some(sig) = fcx.body_fn_sig() { !fcx.predicate_may_hold(&Obligation::new( fcx.tcx, ObligationCause::dummy(), fcx.param_env, ty::TraitRef::new( fcx.tcx, fcx.tcx.require_lang_item(hir::LangItem::Sized, None), [sig.output()], ), )) } else { false </ins> } <del> false </del> } pub fn complete<'a>(self, fcx: &FnCtxt<'a, 'tcx>) -> Ty<'tcx> {

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
bisected to cc
This can be made to ICE on stable as well:
duplicate of

<!-- 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
almost exactly 3 years old :cake: :partying_face: :pinata: searched toolchains nightly-2020-04-17 through nightly-2023-04-22 Regression in nightly-2020-04-23 found 7 bors merge commits in the specified range commit[0] 2020-04-21: Auto merge of - spastorino:dyn-fnonce-alignment, r=nikomatsakis commit[1] 2020-04-22: Auto merge of - ehuss:update-cargo, r=ehuss commit[2] 2020-04-22: Auto merge of - JohnTitor:rollup-vh6dut5, r=JohnTitor commit[3] 2020-04-22: Auto merge of - nnethercote:bitcode-in-rlib, r=alexcrichton commit[4] 2020-04-22: Auto merge of - Dylan-DPC:rollup-iunh61a, r=Dylan-DPC commit[5] 2020-04-22: Auto merge of - nnethercote:alphabetize-C-and-Z-options, r=petrochenkov commit[6] 2020-04-22: Auto merge of - Dylan-DPC:rollup-rvm6tfy, r=Dylan-DPC probably ? cc
I feel like i've seen this before -- probably a dupe? Or at least I think I've chatted with about this.
Could be :D probably 90% of the ICEs I am seeing are already reported in some way or another and sometimes one might slip through
different stacktrace with debug assertions: `
Change:
let _len = addr_to_sockaddr(address, &mut storage); let res = unsafe { let addr_p = &storage as *const _ as *const libc::sockaddr; <del> uvll::uv_tcp_bind(l.handle, addr_p) </del> <ins> uvll::uv_tcp_bind(l.handle, addr_p, 0) </ins> }; return match res { 0 => Ok(l.install()),

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> error[E0121]: the type placeholder `_` is not allowed within types on item signatures for return types --> $DIR/issue-77179.rs:7:22 | LL | fn test() -> Pointer<_> { |              --------^- |              |       | |              |       not allowed in type signatures |              help: replace with the correct return type: `Box<i32>` error: aborting due to previous error For more information about this error, try `rustc --explain E0121`. </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
The backtrace suggests that ICE is caused by error formatting machinery. This is a corner case that should be fixed, but my original intention was to provide a concrete type. Sadly, it didn't work out either: results in: Will this be possible one day? My intuition tells me that the snippet above should work. Apologies if this is an improper place for such questions.
The original no longer ICEs since , however the following does Maybe a different ICE?
And the above no longer ICEs since
Change:
return cmd; fn append_arg(cmd: &mut String, arg: &str) { <del> let quote = arg.chars().any(|c| c == ' ' || c == 't'); </del> <ins> // If an argument has 0 characters then we need to quote it to ensure // that it actually gets passed through on the command line or otherwise // it will be dropped entirely when parsed on the other end. let quote = arg.chars().any(|c| c == ' ' || c == 't') || arg.len() == 0; </ins> if quote { cmd.push_char('"'); }

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:
] [[package]] <del> name = "tester" version = "0.5.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "5e812cb26c597f86a49b26dbb58b878bd2a2b4b93fc069dc39499228fe556ff6" dependencies = [ "getopts", "libc", "term 0.4.6", ] [[package]] </del> name = "textwrap" version = "0.11.0" source = "registry+https://github.com/rust-lang/crates.io-index"

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. 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.
I suspect miri just needs a compiletest update cc
triage: P-medium. Removing nomination label.
So, the compiletest-update was semver-breaking?
The failure seems to be a panic in cargo...?
not quite, nightly rustc broke compiletest and we play catch up with that since the nightly feature is "current nightly" the cargo panic you're seeing is an osx bug in cargo that got fixed
Is this a recent bug? It looks (in Miri CI) as if the bug occurred with stable cargo.
this bug appeared in nightly and got fixed on the next day. Could you cargo version from CI (after installing master toolchain)?
It's recent, but not on stable, maybe you're seeing something else.
FWIW, the trouble was that Travis on the auto branch used a beta cargo, not a stable one, due to caching.
Change:
} fn main() { <del> assert_eq!(1028, std::mem::size_of_val(&move_before_yield())); assert_eq!(1032, std::mem::size_of_val(&move_before_yield_with_noop())); assert_eq!(2056, std::mem::size_of_val(&overlap_move_points())); assert_eq!(1032, std::mem::size_of_val(&overlap_x_and_y())); </del> <ins> assert_eq!(1025, std::mem::size_of_val(&move_before_yield())); assert_eq!(1026, std::mem::size_of_val(&move_before_yield_with_noop())); assert_eq!(2051, std::mem::size_of_val(&overlap_move_points())); assert_eq!(1026, std::mem::size_of_val(&overlap_x_and_y())); </ins> }

Discussion:
Currently they use a hardcoded discriminant, which is quite a lot of room considering that generators don't typically have billions of states. They should be able to use the smallest unsigned integer type that fits all states instead (so in the vast majority of cases).
The discriminant is also never marked with a valid range, meaning that it never provides any niches that could be used to store other values. Not sure if doing that has any drawbacks, but it seems like a somewhat easy size optimization on first glance.
Fixing this was way easier than I expected, but I'd appreciate help with benchmarking the runtime impact of the fix in . So if anyone knows any async/await benchmarks that are not I/O heavy (so that they mostly test CPU overhead of async/await), I'd be happy to run them.
Change:
// build the redirect pages let _guard = builder.msg_doc(compiler, "book redirect pages", target); <del> for file in t!(fs::read_dir(builder.src.join(&relative_path).join("redirects"))) { </del> <ins> for file in t!(fs::read_dir(redirect_path)) { </ins> let file = t!(file); let path = file.path(); let path = path.to_str().unwrap();

Discussion:
This might not be a valid request (I have to tell it what to test), but surely it shouldn't just result in such an obscure panic. Cc
you don't have dir ?
it doesn't exists until fetching the submodule
Seems like I don't have that submodule checked out; I don't work on the book so it's not needed (and I keep the checked-out submodules to a minimum to avoid having to update them all the time).
I reproduced it in local, without in and don't update submodule manually, will fail like this.
I can fix it tomorrow, feel free to work on it if you want to fix it earlier.
by the way, do you know why we use those for here?
Not particularly, I am not so familiar with the compiletest code. Probably we panic there so the compiletest runner process can handle(being able to understand compiletest was failed) that.
The fix shouldn't make any changes on the compiletest side. We just need to avoid using submodules(if doesn't exists) instead of assuming that they exist.
Yes, that's another issue, I just met it today.
Change:
<ins> error: reaching this expression at runtime will panic or abort --> $DIR/const-eval-query-stack.rs:18:28 | LL |     let x: &'static i32 = &(1 / 0); |                           -^^^^^^^ |                            | |                            dividing by zero | = note: `#[deny(const_err)]` on by default query stack during panic: #0 [const_eval_raw] const-evaluating `main::promoted[1]` #1 [const_eval_validated] const-evaluating + checking `main::promoted[1]` #2 [const_eval_validated] const-evaluating + checking `main::promoted[1]` #3 [normalize_generic_arg_after_erasing_regions] normalizing `main::promoted[1]` #4 [optimized_mir] optimizing MIR for `main` #5 [collect_and_partition_mono_items] collect_and_partition_mono_items end of query stack </ins>

Discussion:
Evaluating of promoteds currently looks very confusing in the query stack: is not a const, so "const-evaluating " is just nonsense. I presume that this is easy to fix but only would know how. ;) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Also see
Let's give a try :wink:
claim
awesome. :) Let us know if you need any help. I am not very familiar with that specific code, but can still help with more general questions, and I hope can help with the specifics. :D
Change:
use crate::dataflow::impls::MaybeInitializedPlaces; use crate::dataflow::move_paths::MoveData; use crate::dataflow::ResultsCursor; <ins> use crate::transform::{ check_consts::ConstCx, promote_consts::is_const_fn_in_array_repeat_expression, }; </ins> use crate::borrow_check::{ borrow_set::BorrowSet,

Discussion:
The following code: gives the following error: However, is a , so this code can be made to compile by creating a new item: We should suggest this to user when a function is being called in the array initializer. <strikeAssuming that is accepted, we could eventually suggest an inline block.</strikeOn Nightly, we could suggest an inline block. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think this would make a good first issue for someone looking to get started contributing. I'd be happy to mentor anyone who wants to work on this.
claim
Is this still an issue that I can work on?
Yes, assuming that is no longer working on this.
Should I claim it?
It looks like DavidHusicka hasn't had any activity this month, so I think it would be fine for you to take the issue. Feel free to reach out to me if you have any questions about how to get started implementing this.
claim
Change:
<ins> struct T1<const X1: usize>; struct T2<const X1: usize, const X2: usize>; struct T3<const X1: usize, const X2: usize, const X3: usize>; impl T1<1> { const C: () = (); } impl T2<1, 2> { const C: () = (); } impl T3<1, 2, 3> { const C: () = (); } fn main() { T1<1>::C; //~ ERROR: comparison operators cannot be chained T2<1, 2>::C; //~ ERROR: expected one of `.`, `;`, `?`, `}`, or an operator, found `,` T3<1, 2, 3>::C; //~ ERROR: expected one of `.`, `;`, `?`, `}`, or an operator, found `,` } </ins>

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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: Ideally the output should mention that the user needs to use a turbofish here: cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
the help message seems to only be missing if there are 2 const arguments: using type parameters or just one const param causes a useful help message
claim
It turns out 's repro is different than the original repro. My PR fixes 's examples but not the original one. I'll update it to fix the original one too.
All fixed.
Change:
// the global context. _timer = Some(self.sess.timer("free_global_ctxt")); if let Err((path, error)) = queries.finish() { <del> self.sess.dcx().emit_err(errors::FailedWritingFile { path: &path, error }); </del> <ins> self.sess.dcx().emit_fatal(errors::FailedWritingFile { path: &path, error }); </ins> } ret

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. --With as a dependency. <!-- 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. --: This is repeated for what seems like every parallel compilation unit.
It appeared to be related to running out of space in the target directory.
Thank you for opening the issue and that explanation. This is probably fixed by (which will be in 1.76 but not 1.75) but I'll try to reproduce the crash just in case it isn't fixed by that.
The reproducer script I cooked up for reproduces this ICE backtrace on stable, so I'm linking this to that PR.
Change:
Some(format!("/{}/{}", drive, &s[drive.len_utf8() + 2..])) } } <ins> fn write_file(path: &Path, data: &[u8]) { let mut vf = t!(fs::File::create(path)); t!(vf.write_all(data)); } </ins>

Discussion:
Can we include the output of into the source archives? It can be important for beta and nightly. Ideally the download page should also display them.
This should be a pretty easy bug to tackle for anyone aspiring to do so. Let's just create a file called in our tarballs with basically the output of
This will require editing the makefiles in as well as the rustbuild build system in . The version info is in . I realized that the installers already include this info in a file called 'version', so we can just duplicate that logic. Use the same lower case naming for consistency.