jiebi/CodeConvo huggingface dataset:
Change:
mir::BinOp::Shl => common::build_unchecked_lshift(bx, lhs, rhs), mir::BinOp::Shr => common::build_unchecked_rshift(bx, input_ty, lhs, rhs), mir::BinOp::Ne | mir::BinOp::Lt | mir::BinOp::Gt | <del> mir::BinOp::Eq | mir::BinOp::Le | mir::BinOp::Ge => if is_unit { bx.cx().const_bool(match op { mir::BinOp::Ne | mir::BinOp::Lt | mir::BinOp::Gt => false, mir::BinOp::Eq | mir::BinOp::Le | mir::BinOp::Ge => true, _ => unreachable!() }) } else if is_float { </del> <ins> mir::BinOp::Eq | mir::BinOp::Le | mir::BinOp::Ge => if is_float { </ins> bx.fcmp( base::bin_op_to_fcmp_predicate(op.to_hir_binop()), lhs, rhs

Discussion:
libcore however doesn't use those for the implementations for and for the unit type. This means that the special case in cg_ssa can be removed.
Hi I'd like to work on this. Would be a good initial contribution to Rust :)
I'm really new to the code base, though. Could you clarify what the means above?
That's , a part of the code generation code in rustc. The code in the first snippet is located there.
Thanks for clarifying that! I'll go through the code and post any questions here.
Would love to help but don't know where to start. If mentoring is still possible please ping me or send me in the right direction somehow .
or maybe if your up to the task :)
I think you just need to look at and remove the check for that was mentioned. You can check https://rust- for an overview of the compiler and instruction on how to build it and run tests.
Thanks seems to be a little simpler then I thought once I dug into the docs. Will do hope your having a good one .
Change:
#[derive(Copy, Clone, Debug)] enum ValueSource<'a, 'tcx> { Rvalue(&'a Rvalue<'tcx>), <ins> DropAndReplace(&'a Operand<'tcx>), </ins> Call { callee: &'a Operand<'tcx>, args: &'a [Operand<'tcx>],

Discussion:
In the following example, and are allowed but isn't: The reason is that is lowered to in MIR, and that's not handled in const-checking as a and an assignment (which it functionally is). EDIT: nevermind, promotion works based on temporaries, so it shouldn't be affected. cc
I'm going to label this as a bug since it seems covered by from a T-Lang perspective.
Change:
<ins> // check-pass // Extending `improper_ctypes` to check external-ABI fn-ptrs means that it can encounter // projections which cannot be normalized - unsurprisingly, this shouldn't crash the compiler. trait Bar { type Assoc; } type Foo<T> = extern "C" fn() -> <T as Bar>::Assoc; fn main() {} </ins>

Discussion:
Create an empty crate, add to dependencies, and . [ ] Previous Stable [ ] Current Stable [X] Current Beta [X] Current Nightly Discovered on since 1.72.0-nightly ( 2023-07-03). The previous version 2023-07-02 is good. The breaking day is the same as . I suspect this is also related to . But fix to that does NOT fix this ICE though. cc The error message is similar to , but that occurs on an earlier version 2023-06-28. I guess it's unrelated.
label regression-from-stable-to-beta
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
vector, even the heap-allocated memory. This happens deterministically, at the end of the scope. <del> We'll cover [vectors] in detail later in this chapter; we only use them </del> <ins> We covered [vectors] in the previous chapter; we use them </ins> here as an example of a type that allocates space on the heap at runtime. They behave like [arrays], except their size may change by `push()`ing more elements onto them. Vectors have a [generic type][generics] `Vec<T>`, so in this example `v` will have type <del> `Vec<i32>`. We'll cover generics in detail later in this chapter. </del> <ins> `Vec<i32>`. We'll cover [generics] in detail in a later chapter. </ins> [arrays]: primitive-types.html#arrays [vectors]: vectors.html

Discussion:
Ownership, borrowing and lifetimes are discussed after vectors and before methods, but the text seems written with another order in mind. In particular, there's an inaccuracy in , which says: Should this be removed/rephrased/dealt with some other way? I might try a PR for this (removing the inaccuracy) myself.
A PR for this would be great; I would say "in a later chapter" and create a forward reference.
Change:
/// outside it's module and should not be matchable with an empty match /// statement. pub module: DefId, <ins> param_env: ty::ParamEnv<'tcx>, </ins> pub pattern_arena: &'a TypedArena<Pattern<'tcx>>, pub byte_array_map: FxHashMap<*const Pattern<'tcx>, Vec<&'a Pattern<'tcx>>>, }

Discussion:
Attempting to pattern match a slice with a constant value and THEN a slice literal causes an ICE. Simple test case: However simply changing the order to test the slice literal and then the const slice compiles fine: Error message: rustc version:
So... I do have a fix for byte slices, but that just exposed that we have the same ICE for other slices: This can be fixed, too, but I need to wait for to be merged before being able to do this in a reasonable way.
Change:
# x86_64-pc-windows-gnu configuration CROSS_PREFIX_x86_64-pc-windows-gnu=x86_64-w64-mingw32- CC_x86_64-pc-windows-gnu=gcc <del> LINK_x86_64-pc-windows-gnu=gcc </del> CXX_x86_64-pc-windows-gnu=g++ CPP_x86_64-pc-windows-gnu=gcc -E AR_x86_64-pc-windows-gnu=ar

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:
<ins> // check-pass #![feature(min_type_alias_impl_trait)] #![feature(type_alias_impl_trait)] //~^ WARNING: the feature `type_alias_impl_trait` is incomplete pub trait AssociatedImpl { type ImplTrait; fn f() -> Self::ImplTrait; } struct S<T>(T); trait Associated { type A; } impl<'a, T: Associated<A = &'a ()>> AssociatedImpl for S<T> { type ImplTrait = impl core::fmt::Debug; fn f() -> Self::ImplTrait { () } } 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. --Minimized: also occurs for but not <!-- 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. --: also on Rust Playground <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Somehow I missed that this does not require async. Also crashes with and returning .
minimized:
-- the minimization no longer ICEs for me
-- this sure looks like a dup of
After a discussion with Niko about this and assigning to myself we saw that there's already a PR. Unassigning myself then :).
Change:
tcx.fn_sig(assoc.def_id).skip_binder(), assoc.ident, tcx.predicates_of(assoc.def_id), <ins> assoc, </ins> ) } ty::AssocKind::Type => format!("type {} = Type;", assoc.ident),

Discussion:
In the error message below, the first argument of is not named . () Errors: modify labels: T-compiler, A-diagnostics, C-enhancement, D-papercut, F-arbitraryselftypes. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I managed to fix this issue by just manually checking if the argument is of type , and if it is it returns where ty is the type of the argument (in this case std::pin::Pin<&mut Self). I'm not sure if there is a better way, I'm going to make a PR tomorrow, if anyone has a better solution, please tell me.
I’m not just interested in a fix for this particular case. Types that allow dispatch can be arbitrarily nested AFAIK and also I didn’t tag for no reason - these can be extended. Furthermore the correct way to fix this is probably not to just add code but rather to change ~existing logic that must be somewhere already, for example some code currently does make , and parameters print correctly and differently from non-self parameters that have type or~...... let me double-check that.... Oh, wow, I’ll expand this bug-report. Create a binary crate named “my-crate” with: Error message is:
Makes sense as if I recall correctly (can't link files rn as I am on my phone) the code literally just checks if the type is (&/&mut)Self and if it is it prints (&/&mut)self otherwise it prints _: Type. A potential fix could be printing (&/&mut)self only if it's the first argument of the function
Won’t be enough. The first parameter of a trait fn could be of type without being named . It actually needs to check if it’s a parameter. That information should be retrievable somewhere in the compiler. Furthermore then the rest is easy: First step: check if it’s a parameter. If not: use . If it however is one, then check for the type being or or , printing , or respectively; otherwise print .

Another issue related to this is when you have a function that has a signature of The compiler suggests to implement the function using , but that doesn't work I should have fixed it, as soon as all of the tests pass I will make a PR
Change:
= help: use `//` for a plain comment error: unused doc comment <del> --> $DIR/unused-doc-comments-edge-cases.rs:29:27 </del> <ins> --> $DIR/unused-doc-comments-edge-cases.rs:33:9 | LL |         /// useless doc comment |         ^^^^^^^^^^^^^^^^^^^^^^^ LL | LL |         foo: 3 |         ------ rustdoc does not generate documentation for expression fields | = help: use `//` for a plain comment error: unused doc comment --> $DIR/unused-doc-comments-edge-cases.rs:45:9 | LL |         /// useless doc comment |         ^^^^^^^^^^^^^^^^^^^^^^^ LL | LL |         foo |         --- rustdoc does not generate documentation for pattern fields | = help: use `//` for a plain comment error: unused doc comment --> $DIR/unused-doc-comments-edge-cases.rs:55:27 </ins> | LL | fn doc_comment_on_generic<#[doc = "x"] T>(val: T) {} |                           ^^^^^^^^^^^^ - rustdoc does not generate documentation for generic parameters

Discussion:
The same warning is produced at other places like statements, expressions, functions etc. For completeness and consistency it should be produced for pattern and expression fields too. No response rustc 1.74.0-nightly ( 2023-09-01) binary: rustc commit-hash: commit-date: 2023-09-01 host: x8664-pc-windows-msvc release: 1.74.0-nightly LLVM version: 17.0.0 rustc version older than 1.74.0 may ICE on this code. The ICE was fixed in 1.74.0 <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
The reason these warnings are not produced is because the lint infrastructure currently exposes no hooks for and , i.e. there are no and methods on (or for that matter). To fix the issue, these methods may have to be here: and then invoked from here: and here: Alternatively, we can emit the warning from the already existing and methods of and not bother with the above changes at all.
Yeah, I would expect this is the best way of doing it.
claim
label -needs-triage
Change:
infer::LateBoundRegionConversionTime::HigherRankedType, bound_predicate.rebind(data), ); <del> let normalized_ty = ocx.normalize( &obligation.cause, obligation.param_env, self.tcx.mk_projection(data.projection_ty.def_id, data.projection_ty.substs), ); </del> <ins> let unnormalized_term = match data.term.unpack() { ty::TermKind::Ty(_) => self .tcx .mk_projection(data.projection_ty.def_id, data.projection_ty.substs) .into(), ty::TermKind::Const(ct) => self .tcx .mk_const( ty::UnevaluatedConst { def: ty::WithOptConstParam::unknown(data.projection_ty.def_id), substs: data.projection_ty.substs, }, ct.ty(), ) .into(), }; let normalized_term = ocx.normalize(&obligation.cause, obligation.param_env, unnormalized_term); </ins> debug!(?obligation.cause, ?obligation.param_env); <del> debug!(?normalized_ty, data.ty = ?data.term); </del> <ins> debug!(?normalized_term, data.ty = ?data.term); </ins> <del> let is_normalized_ty_expected = !matches!( </del> <ins> let is_normalized_term_expected = !matches!( </ins> obligation.cause.code().peel_derives(), ObligationCauseCode::ItemObligation(_) | ObligationCauseCode::BindingObligation(_, _)

Discussion:
thread panicked at 'called on a value', <details<summaryBacktrace</summary</detailsRegression in nightly-2022-12-04, in rollup , likely from (
Change:
err "either clang or gcc is required" fi <ins> # OS X 10.9, gcc is actually clang. This can cause some confusion in the build # system, so if we find that gcc is clang, we should just use clang directly. if [ $CFG_OSTYPE = apple-darwin -a -z "$CFG_ENABLE_CLANG" ] then CFG_OSX_GCC_VERSION=$("$CFG_GCC" --version 2>&1 | grep "Apple LLVM version") if [ $? -eq 0 ] then step_msg "on OS X 10.9, forcing use of clang" CFG_ENABLE_CLANG=1 putvar CFG_ENABLE_CLANG fi fi </ins> if [ ! -z "$CFG_LLVM_ROOT" -a -e "$CFG_LLVM_ROOT/bin/llvm-config" ] then step_msg "using custom LLVM at $CFG_LLVM_ROOT"

Discussion:
I get this error: This patch seems to fix the problem for me:
This should have been fixed by . Are you using an older version of rust?
I'm using a version from a few hours ago, and I've tried clobbering any local state with . The error still happens. :/
What revision are you using?
I am also running into this error on OSX 10.9, on .
This is a 10.9 error. You can work around it by removing -L $(TMPDIR) from However this is likely to break the build on other platforms.
I think it's caused by Clang implicitly including the current directory as a link argument. Since there is no gcc on 10.9 anymore, this has started happening.
I think I found a proper fix. If you change to have , I managed to get passed this build issue with c-static-dylib. So we should change configure to use clang by default if it detects we are on 10.9.
Another option is to add to the line in : <pre--- a/src/test/run- +++ b/src/test/run- -1,5 +1,5 RUSTC := (TMPDIR) -L $(TMPDIR) -CC := (TMPDIR) +CC := (TMPDIR) RUN = (1) FAILS = (1) && exit 1 exit 0 </preSee:
This is probably not quite enough since this option doesn't seem to exist in gcc. Do we have a CFG variable that detects whether we're using clang or gcc?
Change:
fn clone(&self) -> Box<rtio::RtioPipe + Send> { box PipeWatcher { <del> stream: StreamWatcher::new(self.stream.handle), </del> <ins> stream: StreamWatcher::new(self.stream.handle, false), </ins> defused: false, home: self.home.clone(), refcount: self.refcount.clone(),

Discussion:
When using libgreen on Windows (verified not to occur with libnative) when I'm reading from a TcpStream and the remote host closes the stream (specifically I'm closing the client by pressing ctrl + c), the server silently terminates with no error messages. It appears SIGSEGV is being called. The code I was writing which caused this issue can be found here: Using Windows 8.1 x64 with latest Rust nightly. Attempts to backtrace using gdb have failed:
cc
I have acquired a backtrace by attaching gdb to a running process rather than running the process from gdb to begin with (why this works I have no idea)
After debugging with visual studio I figured out the exact line causing the segfault. At it is . here is a null reference, which was transmuted from getting the data of the handle, which is apparently 0. I don't know what is setting it to 0 though.
It appears even sending packets to the connection causes it to die. Has anyone even tested libgreen on Windows with TCP?
I have determined the cause of the bug to be a race condition. Specifically every time I open up a connection, is called 3 times and is called once. If the 3 new streams all occur before the read call, the pointer remains non-zero. If one of them occurs after the read call, then the pointer becomes zero, and the read callback segfaults. I have verified this through multiple runs and statements everywhere.
To further expand, is called when a TcpStream is created, and also everytime I clone the . Since cloning a is the only way to share it across tasks (it doesn't impl ), I had to spawn two tasks, one to read and one to write. Because I spawned the reading one first it would start a read before I cloned the tcp for the writing task, and once I cloned it, the data pointer got reset so the data pointer the read callback received was null thereby causing the segfault.
Yes, no commit gets pushed to master unless it passes all tests on windows, and that includes many networking tests. Do you have a small test case which reproduces this bug? It's likely that there's just some different callback-invoking behavior on windows than on unix that was accidentally not dealt with.
Here is a minimal code example:
Change:
} let fn_sig = self.tcx.fn_sig(def_id).instantiate(self.tcx, args); <ins> // Additionally, check that the body that we're inlining actually agrees // with the ABI of the trait that the item comes from. if let InstanceDef::Item(instance_def_id) = callee.def && self.tcx.def_kind(instance_def_id) == DefKind::AssocFn && let instance_fn_sig = self.tcx.fn_sig(instance_def_id).skip_binder() && instance_fn_sig.abi() != fn_sig.abi() { return None; } </ins> let source_info = SourceInfo { span: fn_span, ..terminator.source_info }; return Some(CallSite { callee, fn_sig, block: bb, source_info });

Discussion:
<!-- [31mICE[0m: Rustc '-Zmir-opt-level=0 -Zpolymorphize=on -Zinline-mir=yes -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'index out of bounds: the len is 6 but the index is 6'', 'thread 'rustc' panicked at 'index out of bounds: the len is 6 but the index is 6'' 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: [optimizedmir] optimizing MIR for [unusedgenericparams] determining which generic parameters are unused by [analysis] running analysis passes on this crate --
cc
Change:
} } } match (t_from, t_cast) { // These types have invariants! can't cast into them. (_, Int(CEnum) | FnPtr) => Err(CastError::NonScalar),

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. --: On playgrounds it seemed to affect and for , and . <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Looks like it also happens without the re-borrow, but with a different error. <details<summary<strongBacktrace</strong</summary<p</p</details
Regression in nightly-2021-11-14 found 7 bors merge commits in the specified range commit[0] 2021-11-12: Auto merge of - matthiaskrgr:rollup-ou6yrlw, r=matthiaskrgr commit[1] 2021-11-13: Auto merge of - workingjubilee:use-simd, r=MarkSimulacrum commit[2] 2021-11-13: Auto merge of - jfrimmel:rtcopychecks, r=Mark-Simulacrum commit[3] 2021-11-13: Auto merge of - mystor:expandliteral, r=petrochenkov commit[4] 2021-11-13: Auto merge of - the8472:privatize-the-means-of-rawvec-production, r=joshtriplett commit[5] 2021-11-13: Auto merge of - jhpratt:stabilize-constrawptrderef, r=oli-obk commit[6] 2021-11-13: Auto merge of - mfrw:mfrw/librustdoc, r=GuillaumeGomez ERROR: no CI builds available between and within last 167 days
Regression in nightly-2019-06-17 found 7 bors merge commits in the specified range commit[0] 2019-06-15: Auto merge of - RalfJung:cfg-if,

r=alexcrichton commit[1] 2019-06-16: Auto merge of - Centril:rollup-3p3m2fu, r=Centril commit[2] 2019-06-16: Auto merge of - matthewjasper:optimize-false-edges, r=pnkfelix commit[3] 2019-06-16: Auto merge of - chansuke:separate-unit-tests, r=petrochenkov commit[4] 2019-06-16: Auto merge of - nikomatsakis:trait-caching-perf-3, r=pnkfelix commit[5] 2019-06-16: Auto merge of - glaubitz:sparc64-ffi-abi, r=petrochenkov commit[6] 2019-06-16: Auto merge of - Centril:stabilize-underscoreconstnames, r=petrochenkov ERROR: no CI builds available between and within last 167 days
WG-prioritization assigning priority (). label -I-prioritize +P-medium
This also returns ICE, but ICE message varies between rustc version.
Change:
pub interpreted_as_const: Option<InterpretedAsConst>, #[subdiagnostic] pub adt_defined_here: Option<AdtDefinedHere<'tcx>>, <ins> #[note(mir_build_privately_uninhabited)] pub witness_1_is_privately_uninhabited: Option<()>, </ins> #[note(mir_build_pattern_ty)] pub _p: (), pub pattern_ty: Ty<'tcx>,

Discussion:
The following code compiles on nightly (): But if the wrapper type is moved into a module to make the field private, then it does not: (): Making the field makes it compile again. Is this expected? I suppose I could understand if it is; the private fields could change to make actually be constructable and therefore make the pattern refutable. But if that's the case, then I think the compiler should point this out, like . If indeed this is expected, is there any way for me as a library author to somehow convince the compiler that I will never change the fields to make the type constructable? I want users of my library to be able to elide match arms when I give them an . label +T-compiler +F-never_type +D-confusing +requires-nightly +S-bug-has-mcve
label +F-exhaustive_patterns
are we sure this is actually a bug? As I said, I could understand how it's not:
I'm not sure either way - however at the very least, as you point out, it makes sense to have some better diagnostics
This is definitely intentional. But yeah, it should have a better error message. Not currently I don't think. It would probably require us to add an trait, eg. something like: This trait would then need to be a lang item so that the exhaustiveness check could make use of it. Adding this trait would require an RFC but I doubt there'll be much enthusiasm for adding another special trait for such a niche use-case. Alternatively, you could give an or method to expose the uninhabitedness of the inner value. It's not quite what you're asking for but it's still concise-ish:
Is supposed to be “injected” where an otherwise required match arm was omitted? Wouldn't that run into the same discussions project-deref-patterns had about impure code (code with side effects) inside patterns? Their existence would heavily hinder optimizations of match expressions (like translation to jump tables or reordering).
If the type implementing really is uninhabited then there won't actually be any impure code in the match. The call to would only need to be injected for types that fake uninhabitedness with an impl that panics/aborts. We could also rule that out be instead making -only like .

Making a trait isn't straightforward exactly because inhabitedness depends on visibility questions. It would probably have to mean "Uninhabited as far as the outside world is concerned", or it could use a trick like the in to make it depend on the module.