jiebi/CodeConvo huggingface dataset:
Change:
target_os = "emscripten", target_os = "fuchsia", target_os = "l4re", <ins> target_os = "linux", </ins> target_os = "haiku")))] pub fn set_cloexec(&self) -> io::Result<()> { unsafe {

Discussion:
There are several bugs here, but they all stem from the same problem -- the stdlib doesn't handle correctly in a few places. causes most other flags to be ignored, so requiring a mode is a little bit weird. Really, should probably be handled as another mode. This one can be worked around pretty trivially (though it is a bit silly in my view), but unfortunately that's when you hit the next issue: This doesn't work with because file descriptors have which means that all s on them fail (this is a security feature). Rust proactively sets close-on-exec in many different places, which means that any method that ends up triggering an gives a spurrious . The most obvious problem is with but I'm sure there are plenty of other examples: Rust really should use because s are blocked on all descriptors (while works without issue).
It does: There's a fallback to support older kernels that you're probably running into:
I figured out the reason why was missing -- it's because of a bug in a kernel patch I'm writing (which I'm simultaneously writing a Rust library for). So the fact that the "let's try setting explicitly" path gets tripped is totally my fault. However, I would argue Rust still really shouldn't be using -- because it doesn't work for (or any file with ) while always works. This would just boil down to and removing it from the impl.
I just found another problem this causes -- will fail with on files because doesn't work on file descriptors: The patch to fix this issue is literally just: I can submit a PR for this if that would be acceptable?
Sure
PR is here: .
I still do not see any fix for Should I open an new issue for it?
Yeah, I forgot to write a fix for that. I can open a new issue for that...
Are you kidding me? Yesterday I looked at the function where I needed this again after a year. And today I get a notifications here. Do you want to claim that coincidence exists? SGTM
Change:
} cfg_if::cfg_if! { <del> if #[cfg(any(all(target_vendor = "apple", not(target_os = "watchos")), target_os = "netbsd", not(target_arch = "arm")))] { </del> <ins> if #[cfg(any(target_vendor = "apple", target_os = "netbsd", not(target_arch = "arm")))] { </ins> // Not ARM EHABI <ins> // // 32-bit ARM on iOS/tvOS/watchOS use either DWARF/Compact unwinding or // "setjmp-longjmp" / SjLj unwinding. </ins> #[repr(C)] #[derive(Copy, Clone, PartialEq)] pub enum _Unwind_Action {

Discussion:
Building project using should just work, but instead it fails to link to the and symbols. The exact error is: : This worked with , I'll try to bisect it myself. label O-watchos
Ugh, don't you just love it when the culprit is yourself? It's
Change:
<ins> // User type annotation in fn bodies is a a valid defining site for opaque types. // check-pass #![feature(type_alias_impl_trait)] trait Equate { type Proj; } impl<T> Equate for T { type Proj = T; } trait Indirect { type Ty; } impl<A, B: Equate<Proj = A>> Indirect for (A, B) { type Ty = (); } type Opq = impl Sized; fn define_1(_: Opq) { let _ = None::<<(Opq, u8) as Indirect>::Ty>; } fn define_2() -> Opq { 0u8 } fn main() {} </ins>

Discussion:
This used to compile and now ICEs: Compiles on Stable version: 1.70.0 Regressed in 1.71.0-beta.6 (2023-07-08 ) I guess it is , but this shouldn't be in beta? <details<summary<strongBacktrace</strong</summary<p</p</details
Bisection results: searched nightlies: from nightly-2023-05-20 to nightly-2023-07-14 regressed nightly: nightly-2023-06-25 searched commit range: regressed commit: ( -), cc <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Change:
// CHECK:       call i1 @llvm.type.test({{i8*|ptr}} {{%f|%[0-9]}}, metadata !"[[TYPE3:[[:print:]]+]]") } <ins> pub fn foo4<'a>(a: &dyn Trait4<'a, Type4, Output = &'a i32>) { let b = Type4; a.qux(&b); // CHECK-LABEL: define{{.*}}4foo4{{.*}}!type !{{[0-9]+}} // CHECK:       call i1 @llvm.type.test({{i8*|ptr}} {{%f|%[0-9]}}, metadata !"[[TYPE4:[[:print:]]+]]") } pub fn bar4<'a>() { let a = Type4; foo4(&a); let b = &a as &dyn Trait4<'a, Type4, Output = &'a i32>; b.qux(&a); // CHECK-LABEL: define{{.*}}4bar4{{.*}}!type !{{[0-9]+}} // CHECK:       call i1 @llvm.type.test({{i8*|ptr}} {{%f|%[0-9]}}, metadata !"[[TYPE4:[[:print:]]+]]") } </ins> // CHECK: !{{[0-9]+}} = !{i64 0, !"[[TYPE1]]"} // CHECK: !{{[0-9]+}} = !{i64 0, !"[[TYPE2]]"} // CHECK: !{{[0-9]+}} = !{i64 0, !"[[TYPE3]]"} <ins> // CHECK: !{{[0-9]+}} = !{i64 0, !"[[TYPE4]]"} </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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
// different owner. } <ins> fn visit_foreign_item_ref(&mut self, _: &'hir hir::ForeignItemRef<'hir>) { // Explicitly do nothing here. ForeignItemRefs contain hir::Visibility // values that actually belong to an ForeignItem instead of the ItemKind::ForeignMod // we are currently in. So for those it's correct that they have a // different owner. } </ins> fn visit_generic_param(&mut self, param: &'hir hir::GenericParam<'hir>) { if let hir::GenericParamKind::Type { synthetic: Some(hir::SyntheticTyParamKind::ImplTrait),

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
I'm seeing this one as well. Host is a standard Github Actions container. Not sure if the below information is helpful but its additional to the above posted by HYG-YT.
I have to temporarily degrade the version of my nightly installation to 11-24 to make sure everything is functional (it's a discord bot made with twilight-rs)
Similarly, I'm attempting to knock my version back a couple of days as well-- yet to succeed but that's mostly me wrestling with my actions configuration.
I have the same on my Raspberry Pi 3 (Debian 10, Linux 4.19.66):
I can reproduce with on . searched toolchains through regression in Regressed in , cc
MCVE:
Assigning .
I updated to the latest nightly (2020-11-29) and it still fails.
Wait for next nightly. The current one doesn't contain the fix PR.
Got it!
you can also try the latest master using
Change:
results } <del> fn print_diff(expected: &str, actual: &str, context_size: usize) { </del> <ins> fn write_diff(expected: &str, actual: &str, context_size: usize) -> String { use std::fmt::Write; let mut output = String::new(); </ins> let diff_results = make_diff(expected, actual, context_size); for result in diff_results { let mut line_number = result.line_number; for line in result.lines { match line { DiffLine::Expected(e) => { <del> println!("-t{}", e); </del> <ins> writeln!(output, "-t{}", e).unwrap(); </ins> line_number += 1; } DiffLine::Context(c) => { <del> println!("{}t{}", line_number, c); </del> <ins> writeln!(output, "{}t{}", line_number, c).unwrap(); </ins> line_number += 1; } DiffLine::Resulting(r) => { <del> println!("+t{}", r); </del> <ins> writeln!(output, "+t{}", r).unwrap(); </ins> } } } <del> println!(); </del> <ins> writeln!(output, "").unwrap(); </ins> } <ins> output </ins> } pub fn run(config: Config, testpaths: &TestPaths, revision: Option<&str>) {

Discussion:
Note: missing newline after is essential. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I've not been able to reproduce this on the latest nightly, I've bisected it to have been fixed in 2020-07-15 (report used 2020-07-11), probably by ; I've filed with a regression test.
Me neither.
Change:
impl<'tcx> MirPass<'tcx> for RemoveZsts { fn run_pass(&self, tcx: TyCtxt<'tcx>, body: &mut Body<'tcx>) { <ins> // Avoid query cycles (generators require optimized MIR for layout). if tcx.type_of(body.source.def_id()).is_generator() { return; } </ins> let param_env = tcx.param_env(body.source.def_id()); let (basic_blocks, local_decls) = body.basic_blocks_and_local_decls_mut(); for block in basic_blocks.iter_mut() {

Discussion:
Found by 1.56 crater -- https://crater- cc
Fixed by . Sorry for taking over, but since I started looking into it already.
Still needs a backport
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
fixed by
Change:
}; let mut constraints = QueryRegionConstraints::default(); <del> let Ok(InferOk { value, obligations }) = self </del> <ins> let Ok(InferOk { value: mut bounds, obligations }) = self </ins> .instantiate_nll_query_response_and_region_obligations( &ObligationCause::dummy(), param_env,

Discussion:
In that commit, go to folder and run (tested in nightly, stable 1.69 and stable 1.70) : <details<summary<strongBacktrace</strong</summary<p</p</details
This is causing us to leak placeholders into implied bounds. Minimized:
Change:
", $Feature, "assert_eq!(", stringify!($SelfT), "::min_value(), 0);", $EndFeature, " ```"), #[stable(feature = "rust1", since = "1.0.0")] <ins> #[rustc_promotable] </ins> #[inline] pub const fn min_value() -> Self { 0 } }

Discussion:
apint fails to compile (https://crater-) on beta. Note that the crate must be compiled in test mode.
cc -- I believe this is your crate, though it seems plausible this is a bug in the compiler
cc -- beta/stable regression, would be good to proactively triage before meeting if possible
Could this be promotion-related?
Yea. The call to on arrays does not actually do what it advertises, it derefs to a slice and then does . We stopped allowing const fns in promoteds is still marked as promotable, so that shouldn't be the issue. I'll investigate later today when I get back to a PC
yeah that's my crate thanks for linking! I have already stumbled upon this CI error but couldn't yet find time to wrap my head around it. Though I thought it was a bug in a former version of the borrow checker that now got fixed. So if I understood correctly simply using a instead of plain would solve that issue? Maybe we should reiterate on this design for on arrays if that's the case. :D
minimal repro Nope, it's a new bug that I was sure we had regression tests against.
This was injected between rustc 1.31.0-nightly ( 2018-10-03) and rustc 1.31.0-nightly ( 2018-10-04) Log of bors commits in that time in the details block <details% git log .. --author bors --format=oneline Auto merge of - nikomatsakis:universes-refactor-1, r=scalexm Auto merge of - matthewjasper:mir-function-spans, r=pnkfelix Auto merge of - Manishearth:clippyup, r=oli-obk Auto merge of - pietroalbini:rollup, r=pietroalbini Auto merge of - christianpoveda:master, r=kennytm Auto merge of - oli-obk:local_promotion, r=eddyb Auto merge of - arielb1:evaluate-outlives, r=nikomatsakis Auto merge of - KiChjang:issue-, r=nikomatsakis Auto merge of - davidtwco:issue-, r=petrochenkov </details
Hmm I wonder if this could somehow be a consequence fo ...?

update: probably not, since this afflicts both AST-borrowck and MIR-borrowck.
Full diff: (limiting promotability of const fns) also fell in there.
I even unit tests, but never any for promoting functions from the libstd. will only work if a function call is promoted in the same crate where the function is declared. I think the solution is to make the const qualifier eagerly call while a function is qualified to cache the result (in the query engine), so that the query is never evaluated in the perspective of another crate (and add an ) to to safeguard against messing this up
Discussed a bit with and investigated independently. Some details of note: The implementation of relies on . If you don't have the latter, the former will essentially be silently ignored, AFAICT. It seems like there are some holes in 's analysis above. In particular, I attempted to make a unit test with multiple crates, and it seemed like promotion was still happening. See here:
reassigning to for followup investigation and hopefully fixing.
Change:
<ins> error: character literal may only contain one codepoint --> $DIR/unicode-character-literal.rs:7:18 | LL |     let _spade = '♠️'; |                  ^^^ | note: this `♠` is followed by the combining mark `u{fe0f}` --> $DIR/unicode-character-literal.rs:7:19 | LL |     let _spade = '♠️'; |                   ^ help: if you meant to write a `str` literal, use double quotes | LL |     let _spade = "♠️"; |                  ~~~ error: character literal may only contain one codepoint --> $DIR/unicode-character-literal.rs:12:14 | LL |     let _s = 'ṩ̂̊'; |              ^^^ | note: this `s` is followed by the combining marks `u{323}u{307}u{302}u{30a}` --> $DIR/unicode-character-literal.rs:12:15 | LL |     let _s = 'ṩ̂̊'; |               ^ help: if you meant to write a `str` literal, use double quotes | LL |     let _s = "ṩ̂̊"; |              ~~~ error: character literal may only contain one codepoint --> $DIR/unicode-character-literal.rs:17:14 | LL |     let _a = 'Å'; |              ^-^ |               | |               help: consider using the normalized form `u{c5}` of this character: `Å` | note: this `A` is followed by the combining mark `u{30a}` --> $DIR/unicode-character-literal.rs:17:15 | LL |     let _a = 'Å'; |               ^ error: aborting due to 3 previous errors </ins>

Discussion:
I tried to compile the following code (): For the avoidance of doubt, is . I expected the code to compile—but instead, the literal is rejected: Notably, it is accepted if unicode-escaped: :
The spade "character" in your code is not just a single U+2660, it also has a unicode variation selector U+FE0F: On my machine at least, this makes a visible difference in appearance (which github tries to eliminate by adding a U+FE0F unless I "escape" with a code block):
D'oh! Good spot, thanks Perhaps some improved diagnostics could have helped here?
We have similar diagnostics in other cases of misleading Unicode so that seems like a good idea.
Change:
<ins> error[E0277]: the size for values of type `str` cannot be known at compilation time --> $DIR/unsized_type2.rs:14:24 | LL | pub static WITH_ERROR: Foo = Foo { version: 0 }; |                        ^^^ doesn't have a size known at compile-time | = help: within `Foo`, the trait `Sized` is not implemented for `str`, which is required by `Foo: Sized` note: required because it appears within the type `Foo` --> $DIR/unsized_type2.rs:5:12 | LL | pub struct Foo { |            ^^^ error[E0277]: the size for values of type `str` cannot be known at compilation time --> $DIR/unsized_type2.rs:14:30 | LL | pub static WITH_ERROR: Foo = Foo { version: 0 }; |                              ^^^^^^^^^^^^^^^^^^ doesn't have a size known at compile-time | = help: within `Foo`, the trait `Sized` is not implemented for `str`, which is required by `Foo: Sized` note: required because it appears within the type `Foo` --> $DIR/unsized_type2.rs:5:12 | LL | pub struct Foo { |            ^^^ = note: constant expressions must have a statically known size error[E0308]: mismatched types --> $DIR/unsized_type2.rs:14:45 | LL | pub static WITH_ERROR: Foo = Foo { version: 0 }; |                                             ^ expected `str`, found integer error: aborting due to 3 previous errors Some errors have detailed explanations: E0277, E0308. For more information about an error, try `rustc --explain E0277`. </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. --(reduced) <details<summary<strongOriginal</strong</summary<p</p</details<!-- 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
Bisects to , but I guess it just made the ICE easier to reach. cc
Nope unfortunately this one only reproduces with statics, and thus can't be reached on stable or before that PR. It's still not useful to look at to figure out why it's ICEing now, as the ICE is happening somewhere else entirely.
Change:
"don't clear the resolution tables after analysis"), keep_ast: bool = (false, parse_bool, "keep the AST after lowering it to HIR"), <ins> show_span: Option<String> = (None, parse_opt_string, "show spans for compiler debugging (expr|pat|ty)"), </ins> } pub fn default_lib_output() -> CrateType {

Discussion:
Not a breaking change since it is an unstable option.
Is it already an unstable option?
this issue is saying that should be changed to . It is already an unstable option.
So can accept as arguments. How would those be specified if were changed to a ?
Hopefully exactly the same way, not sure how possible that is. If it is not possible right now, then this probably isn't an easy issue to fix. I can look into it next week.
We've got kinda our own syntax for the flags so where today you pass it could instead be
Change:
let cause = self.misc(expr.span); let expr_ty = self.resolve_type_vars_with_obligations(checked_ty); let mut err = self.report_mismatched_types(&cause, expected, expr_ty, e); <ins> // If the expected type is an enum with any variants whose sole // field is of the found type, suggest such variants. See Issue // #42764. if let ty::TyAdt(expected_adt, substs) = expected.sty { let mut compatible_variants = vec![]; for variant in &expected_adt.variants { if variant.fields.len() == 1 { let sole_field = &variant.fields[0]; let sole_field_ty = sole_field.ty(self.tcx, substs); if self.can_coerce(expr_ty, sole_field_ty) { let mut variant_path = self.tcx.item_path_str(variant.did); variant_path = variant_path.trim_left_matches("std::prelude::v1::") .to_string(); compatible_variants.push(variant_path); } } } if !compatible_variants.is_empty() { let expr_text = print::to_string(print::NO_ANN, |s| s.print_expr(expr)); let suggestions = compatible_variants.iter() .map(|v| format!("{}({})", v, expr_text)).collect::<Vec<_>>(); err.span_suggestions(expr.span, "perhaps you meant to use a variant of the expected type", suggestions); } } </ins> if let Some(suggestion) = self.check_ref(expr, checked_ty, expected) {

Discussion:
produces I think the first item in this list should be
More generally, if the expected type is an enum, and the found type is T, then you should search the enum's variants and check them whether is the sole argument of one of them. If yes, suggest the variant constructor.
I agree we should list variants like that, but I also think the functions suggestions are sort of silly; see
Change:
<ins> Subproject commit 4ebb8169dfe569b3dcbeab560607800bb717978a </ins>

Discussion:
This is an issue for moving Rust By Example, which is currently at , to . I will be working on the first step shortly. [x] Convert RBE to a submodule under [x] Add RBE to the bookshelf (thanks [x] Update book release process on forge After it is converted and RBE reaches stable: [ ] Update the main English website link a 301
Step one done! Now waiting for this to reach stable.
The forge documentation can be updated now.
This has all been done!
Change:
<ins> error: heap allocations are not allowed in const fn --> $DIR/bad_const_fn_body_ice.rs:2:5 | LL |     vec![1, 2, 3] //~ ERROR heap allocations are not allowed in const fn |     ^^^^^^^^^^^^^ | = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info) error: aborting due to previous error </ins>

Discussion:
<short summary of the bugReturning from a const fn causes internal compiler error, with the message 'bad input type for cast'. I tried this code: Minimal example Original example I expected to see this happen: program compiles and prints 'Hello 1' or I get a compiler error. Instead, this happened: ICE
that gives the exact backtrace above.
Relavent code: The types here are and .
The actual bug would be here then, right?
Not quite sure, but the real bug is that we allow the keyword in const fn XD I already have a fix since yesterday, but the german bahn didn't give me electricity so my notebook died while tests were running
no ICE fix from the ICE? :p
Change:
* which remaining fields are copied; see comments on `StructBaseInfo`. */ pub fn trans_adt<'a>(mut bcx: &'a Block<'a>, <del> repr: &adt::Repr, </del> <ins> ty: ty::t, </ins> discr: ty::Disr, fields: &[(uint, Gc<ast::Expr>)], optbase: Option<StructBaseInfo>, dest: Dest) -> &'a Block<'a> { let _icx = push_ctxt("trans_adt"); let fcx = bcx.fcx; <ins> let repr = adt::represent_type(bcx.ccx(), ty); // If we don't care about the result, just make a // temporary stack slot </ins> let addr = match dest { <del> Ignore => { for &(_i, ref e) in fields.iter() { bcx = trans_into(bcx, &**e, Ignore); } for sbi in optbase.iter() { // FIXME #7261: this moves entire base, not just certain fields bcx = trans_into(bcx, &*sbi.expr, Ignore); } return bcx; } SaveIn(pos) => pos </del> <ins> SaveIn(pos) => pos, Ignore => alloc_ty(bcx, ty, "temp"), </ins> }; // This scope holds intermediates that must be cleaned should

Discussion:
The current translation for struct update in the case of ignore looks incorrect. It should only move those fields that are not specified manually. This can mean the difference between moving the base as a whole and not. Probably the easiest thing to do is to create an alloca, use the same code as the normal path, and just drop the alloca afterwards.
See FIXME.
visiting for triage. nominating for production ready.
Accepted for production-ready
visting for triage, still relevant. FYI, the module in question is