jiebi/CodeConvo huggingface dataset:
Code change:
} } <del> pub fn is_async(self) -> bool { matches!(self, CoroutineKind::Async { .. }) } pub fn is_gen(self) -> bool { matches!(self, CoroutineKind::Gen { .. }) </del> <ins> pub fn as_str(self) -> &'static str { match self { CoroutineKind::Async { .. } => "async", CoroutineKind::Gen { .. } => "gen", CoroutineKind::AsyncGen { .. } => "async gen", } </ins> } pub fn closure_id(self) -> NodeId {

Related discussion:
text: () Reproduces on the playground using . label +D-incorrect +F-gen_blocks +requires-nightly
Code change:
use rustc_middle::ty; <ins> // Please change the public `use` directives cautiously, as they might be used by external tools. // See issue #120130. </ins> pub use self::drop_flag_effects::{ drop_flag_effects_for_function_entry, drop_flag_effects_for_location, move_path_children_matching, on_all_children_bits, on_lookup_result_bits, }; pub use self::framework::{ <del> fmt, lattice, visit_results, Analysis, AnalysisDomain, Direction, GenKill, GenKillAnalysis, JoinSemiLattice, MaybeReachable, Results, ResultsCursor, ResultsVisitable, ResultsVisitor, </del> <ins> fmt, graphviz, lattice, visit_results, Analysis, AnalysisDomain, Backward, Direction, Engine, Forward, GenKill, GenKillAnalysis, JoinSemiLattice, MaybeReachable, Results, ResultsCursor, ResultsVisitable, ResultsVisitor, SwitchIntEdgeEffects, </ins> }; <del> use self::framework::{Backward, SwitchIntEdgeEffects}; </del> use self::move_paths::MoveData; pub mod debuginfo;

Related discussion:
text: has made it impossible to import some structures in when implementing dataflow analyses in external tools. When implementing for a custom dataflow problem, we can no longer import the or direction. is the source code of such an implementation. is needed to set the type of the trait. Previously, it under the export, but for now it is . The default implementation of the , so I can simply use the default value as a workaround. However, if I need to write a backward analysis, I must rewrite some parts of the framework in our source code because they cannot be imported. There are other tools in the ecosystem that use that API, e.g.: These changes will make problems if they decide to update to the recent toolchain. Could you please take a look at this matter? Are these changes intentional? Could we make some of the exports public again? cc
Feel free to send in a PR to make it public again. Please add a comment on the items saying they're used by external tools.
I will double-check which of the removed imports might be beneficial for external tools and will send a PR if there are no objections.
Code change:
let _ = &packed2.y; // ok, has align 2 in packed(2) struct let _ = &packed2.z; // ok, has align 1 } <ins> unsafe { struct U16(u16); impl Drop for U16 { fn drop(&mut self) { println!("{:p}", self); } } struct HasDrop; impl Drop for HasDrop { fn drop(&mut self) {} } #[allow(unused)] struct Wrapper { a: U16, b: HasDrop, } #[allow(unused)] #[repr(packed(2))] struct Wrapper2 { a: U16, b: HasDrop, } // An outer struct with more restrictive packing than the inner struct -- make sure we // notice that! #[repr(packed)] struct Misalign<T>(u8, T); let m1 = Misalign( 0, Wrapper { a: U16(10), b: HasDrop, }, ); let _ref = &m1.1.a; //~ ERROR reference to packed field //~^ previously accepted let m2 = Misalign( 0, Wrapper2 { a: U16(10), b: HasDrop, }, ); let _ref = &m2.1.a; //~ ERROR reference to packed field //~^ previously accepted } </ins> }

Related discussion:
text: I tried this code: I expected to see this happen: The reference is aligned Instead, this happened: : label I-unsound A-mir
We have a pass to add moves for drops in packed structs, but it doesn't fire in this case. That's because there's a bug - this computation cannot just take into account the innermost field, it needs to compute a minimum of some sort.
is this a regression? What did you exactly expected the output to be? (I'd like to run a bisection). thanks.
This was right in . Getting a consistent reproduction of this is slightly difficult because the reference might happen to align correctly by accident. In other words, the fact that the example above prints a pointer that is not 2-aligned means that something is certainly wrong. However, if the address were to be 2-aligned that could either be because the bug is fixed or because we happened to get lucky. The consistent way to check this is by looking at . In 1.52.0 the MIR contains which is correct (the move ensures that the resulting place is aligned) while 1.53.0 contains Note that there is no move.
WG-prioritization assigning priority (). label -I-prioritize +P-high E-needs-bisection
I have run a bisection with on your . The bisection could not pinpoint a single commit, maybe it sinked into a rollup merge. But if it helps, the regression should be in and coming from one of these PRs do you see in any of those a possible culprit? (I don't have the context to)
Yeah, it's , cc
Not sure how would have an effect here, it should be a NOP for with . Looks like something else is amiss as well and that PR surfaced the bug? Where is the logic that moves packed structs to a new place before dropping implemented? That's odd, I would have expected this to be inside ... after all calling on a packed struct also has to do this move. Why does MIR building adjust the caller to satisfy a requirement that the callee should be responsible for?
the pass is called or something like that.
Code change:
let _ = &packed2.y; // ok, has align 2 in packed(2) struct let _ = &packed2.z; // ok, has align 1 } <ins> unsafe { struct U16(u16); impl Drop for U16 { fn drop(&mut self) { println!("{:p}", self); } } struct HasDrop; impl Drop for HasDrop { fn drop(&mut self) {} } #[allow(unused)] struct Wrapper { a: U16, b: HasDrop, } #[allow(unused)] #[repr(packed(2))] struct Wrapper2 { a: U16, b: HasDrop, } // An outer struct with more restrictive packing than the inner struct -- make sure we // notice that! #[repr(packed)] struct Misalign<T>(u8, T); let m1 = Misalign( 0, Wrapper { a: U16(10), b: HasDrop, }, ); let _ref = &m1.1.a; //~ ERROR reference to packed field //~^ previously accepted let m2 = Misalign( 0, Wrapper2 { a: U16(10), b: HasDrop, }, ); let _ref = &m2.1.a; //~ ERROR reference to packed field //~^ previously accepted } </ins> }

Related discussion:
text: And this can't take place inside the callee because the callee receives a , and if that reference is unaligned then UB has already occurred and there's nothing the callee can do to fix things anymore
takes a raw pointer, so it could very well be the place where the packed struct alignment trouble is handled. And IMO it'd be a much more natural place than doing this by transforming caller MIR.
I don't understand the suggestion. The example above never calls for a packed struct. The offending drop in the MIR in the example above is . The type of that place is - but if were to be responsible for moving, then we would need to emit a move in literally every drop shim for a non-trivial alignment type.
Oh I see, I didn't quite read the example correctly. The problematic drop is the one that happens on field assignment, and we know it's a packed field because of the path we are accessing it with. EDIT: no wait this makes no sense. Now I am confused by your comment.
No what I just said makes no sense. What happens is that this is a partial drop -- one field has been moved out () and then the logic for dropping the remaining fields seems to be wrong. So is relevant because it changed . And it looks like somehow the change is wrong; here is also despite the reference being unaligned.
should fix this.
Code change:
#[start] fn main(_argc: isize, _argv: *const *const u8) -> isize { <del> let _x = box 1; </del> <ins> let _x = Box::new(1); </ins> 0 } #[lang = "eh_personality"] extern fn rust_eh_personality() {} <del> #[lang = "panic_impl"] extern fn rust_begin_panic(info: &PanicInfo) -> ! { unsafe { intrinsics::abort() } } </del> <ins> #[lang = "panic_impl"] extern fn rust_begin_panic(_info: &PanicInfo) -> ! { intrinsics::abort() } </ins> #[no_mangle] pub extern fn rust_eh_register_frames () {} #[no_mangle] pub extern fn rust_eh_unregister_frames () {} ```

Related discussion:
text: There is no such thing as boxsyntax anymore :D <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
does the same.
It probably makes sense to search across the repository (including submodules) any references to this removed feature and remove them
claim
Code change:
use _Unwind_VRS_DataRepresentation::*; pub const UNWIND_POINTER_REG: c_int = 12; <ins> pub const UNWIND_SP_REG: c_int = 13; </ins> pub const UNWIND_IP_REG: c_int = 15; #[cfg_attr(all(feature = "llvm-libunwind",

Related discussion:
text: When I tested 1.40.0-beta.5 on , never completed on . When I run that test on arm directly, I get: The same happens when I use official builds of Rust 1.40-beta and 1.41-nightly, so it's not just a problem with Fedora's build of rustc or LLVM. This test didn't exist before , but running 1.39 on the current test just fails even earlier, as expected, "entered unreachable code: catch_unwind should not have caught foreign exception." I tried compiling the C++ part with GCC 9.2.1 and Clang 9.0.0, both with the same result. That's using libstdc++ either way though, because we don't have LLVM's libc++ available. cc
cc
PS: while I initially saw this on Fedora rawhide, my followup testing has been on stable Fedora 31.
That is very strange. And this behavior only occurs on ARM? I'm tempted to say that this is a bug in GCC's unwinder (in libgcc). Can you try this C++-only code to see if it has the same issue? a.cpp b.cpp This should print the message once and then fail with an uncaught exception.
Yes, the other arches completed and passed that test. Needs for , but then it works:
I tried stable 1.39 again commenting out the call to , then gets stuck in the same "caught foreign exception in catch" loop on the C++ side. In fact, this happens on every compiler I tried back to 1.13, which is the earliest I could get working at all! So at least it's not a new problem. Maybe we're generating bad unwind data, or maybe my libgcc has a bug in handling foreign exceptions, I don't know...
I think this might be a bug in the way the personality routine in libstdc++ (libsupc++ actually) handles foreign exceptions on ARM. Can you try using libc++ instead of libstdc++? Just change the linker args for rustc from to .
Oh, I found that Fedora does have libc++ packaged, and . But when I tried to use it simply as you indicate, foreign exceptions don't seem to be caught at all, in either direction.
Code change:
use _Unwind_VRS_DataRepresentation::*; pub const UNWIND_POINTER_REG: c_int = 12; <ins> pub const UNWIND_SP_REG: c_int = 13; </ins> pub const UNWIND_IP_REG: c_int = 15; #[cfg_attr(all(feature = "llvm-libunwind",

Related discussion:
text: I see the binary still gets linked implicitly though, I think because adds it to std. I'll try to get a full build of rustc with just libc++ instead.
It's fine to link to , since that contains the libunwind implementation. The actual C++ personality functions are in libstd++/libc++abi. Can you post the test output with libc++?
Maybe this is obvious, but I have to compile the C++ part with clang++, not g++, or it gets "undefined reference to ". I wasn't sure whether to also use , but either way the C++ exception is not caught by Rust: So I commented out again to just try :
you may need to explicitly link libcxxabi depending on how libcxx was built. That should fix undefined reference error.
I did use -- do you mean more than that? If anyone else is interested in arm-linux, it would be great to get more hands on this, because that target is not a high priority for me. I will probably disable this test for arm in Fedora in the meantime.
I managed to reproduce this on Arch Linux with , so it's definitely not a Fedora-only issue.
no, that should be fine. Guess passing to the Clang (supported since 9.0.0) doesn't help either?
The link error was only when using g++ to compile That much was ok with clang++. I just tried adding to the clang command too, but got "argument unused during compilation".
I'm hitting this on Debian too. Running by itself does result in infinite-loop printing however the rust test suite is actually running . Directly running this however exits immediately, so I don't know why the test is hanging. I'll see if I can grab the environment from next time.
Ah nvmd, I just had to wrap the thing in single-quotes to reproduce the loop, the output of "pstree" is misleading.
Since this test is new in 1.40 I'll just for the time being in Debian.
Should be fixed by
Code change:
TyCtxt, TypeSuperVisitable, TypeVisitable, TypeVisitor, }; use rustc_session::config::TraitSolver; <del> use rustc_span::def_id::{DefId, CRATE_DEF_ID}; </del> <ins> use rustc_span::{ def_id::{DefId, CRATE_DEF_ID}, DUMMY_SP, }; </ins> use rustc_trait_selection::traits; fn sized_constraint_for_ty<'tcx>(

Related discussion:
text: <!-- 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
probably Regression in searched nightlies: from nightly-2023-02-15 to nightly-2023-03-16 regressed nightly: nightly-2023-02-20 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
It's actually
Or at least, the logic broke because of , so the ICE message probably changed in that PR from some other message, to this one in the title.
label +S-bug-has-mcve
Code change:
<ins> - // MIR for `bitwise_not` before JumpThreading + // MIR for `bitwise_not` after JumpThreading fn bitwise_not() -> i32 { let mut _0: i32; let mut _1: i32; let mut _2: bool; let mut _3: i32; let mut _4: i32; scope 1 { debug a => _1; } bb0: { StorageLive(_1); _1 = const 0_i32; _1 = const 1_i32; StorageLive(_2); StorageLive(_3); StorageLive(_4); _4 = copy _1; _3 = Not(move _4); StorageDead(_4); _2 = Eq(move _3, const 0_i32); switchInt(move _2) -> [0: bb2, otherwise: bb1]; } bb1: { StorageDead(_3); _0 = const 1_i32; goto -> bb3; } bb2: { StorageDead(_3); _0 = const 0_i32; goto -> bb3; } bb3: { StorageDead(_2); StorageDead(_1); return; } } </ins>

Related discussion:
text: <!-- 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: always panic Instead, this happened: only -Zmir-opt-level=2 panic For mir-opt-level 0, 1 and 3, they all normally return <!-- 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 --
equals , so I think the panic case is incorrect?
Yeah, I think so.
Looks like it's JumpThreading that incorrectly removes the condition
I managed to create an example without panic, just wrong value
Most likely
ha, I found the bug. We're optimizing incorrectly in the jump threading code. Right now it's only written to handle bool correctly. I'll put up a fix claim
Code change:
} else { let args: Vec<_> = args .into_iter() <del> .map(|arg| unpack!(block = this.as_local_operand(block, arg))) </del> <ins> .map(|arg| unpack!(block = this.as_local_call_operand(block, arg))) </ins> .collect(); let success = this.cfg.start_new_block();

Related discussion:
text: The following code fails on stable: When compiled in release mode, the assert is optimized out by LLVM even though it checks the exact same condition as the other assert, as can be verified by testing in debug mode. Note that it's theoretically possible for the stack to be aligned correctly such that the bug is suppressed, but that's not likely. The 256's can be replaced with larger alignments if that happens. The bug is caused by the impl of copying to the stack with the default alignment of 16. ()
and seem related
This is a soundness hole.
So... I guess the problem is that the that rustc emits for the unsized local doesn't use ? That's... kind of bad, because it doesn't look like even supports dynamically setting the alignment: If this is correct, the issue should be renamed to something like "unsized locals do not respect alignment".
A way to fix this would be to change the ABI for dynamic trait calls that take by value to always pass by address. When the trait object is created is where the trampoline function would be generated, so there is no additional cost for static calls.
This can also be fixed by not allowing dynamically-sized local variables with an alignment more than some maximum value and having all dynamically-sized locals use that maximum alignment unless optimizations can prove that a smaller alignment suffices.
Messing with the ABI wouldn't help with unsized locals in general (assuming is correct), since e.g. will also need an alloca with dynamic alignment in general. Given only a value, there is no static way to say anything about its alignment, so how would you distinguish whether calling a method on it is OK?
Can we call and then align the pointer for the local ourselves as a workaround until we come up with a good solution?
In clang there's a function which might or might not be useful in this case.
requires a constant alignment. Non constant alignments are . This matches semantics of LLVM instruction, so it's not helping, as alignment of value in is unknown at compile time when moving from .
I think that overallocating for unsized locals of unknown alignment may make sense. You can and then make use of to compute the offset. Sure, it increases stack requirements, but it seems acceptable for , and in most cases you end up with extra 7 bytes on stack or less. 256 alignment seems like an edge case where wasting 255 bytes doesn't matter.
Code change:
} else { let args: Vec<_> = args .into_iter() <del> .map(|arg| unpack!(block = this.as_local_operand(block, arg))) </del> <ins> .map(|arg| unpack!(block = this.as_local_call_operand(block, arg))) </ins> .collect(); let success = this.cfg.start_new_block();

Related discussion:
text: if we keep setting as the default alignment we can skip the overallocating and offset dance for types with an alignment below that.
My idea was that rustc would prohibit coercing overaligned types to a dyn trait that takes by value. So:
The alignment is dynamically determined though, not sure if saving 15 bytes of stack space is worth the conditional branch?
Oh right. Yea that's probably not helpful.
Since , this would be backwards incompatible (at latest) once trait object upcasting is finally implemented: and trait objects would have to have the same alignment restriction (because you can upcast to ), but today you can freely create such objects with any alignment.
I was under the impression that calling didn't require dynamic , is that related to missing MIR optimizations, meaning we have unnecessary moves which end up duplicating the data on the stack using a dynamic ?
Correctness shouldn't rely on optimizations to fire...
Sure, I was just hoping we weren't relying on "unsized locals", only unsized parameters (i.e. ), for what we're exposing as stable. And I was hoping an optimization wouldn't need to be involved to get there. I wonder if it would even be possible to restrict "unsized locals" to the subset where we can handle it entirely through ABI, and not actually have dynamic s anywhere, since that would make me far more comfortable with 's implementation or even stabilization. Ironically, if that works, it's also the subset we could've implemented years earlier than we did, since most of the complexity, unknowns (and apparently bugs) are around dynamic s, not calling trait object methods on a dereference of .
That should be possible. I think everything that is necessary is performing the deref of the box as argument () instead of moving the box contents to a local first () That would also make it possible to call in cg_clif. Cranelift doesn't have alloca support, so the current MIR is untranslatable.
Hmm, but that's not trivially sound because it could lead to MIR calls where argument and return places overlap, which is UB. We'd potentially have to special-case it to derefs, but even then what's to stop someone from doing ? Maybe we could introduce a temporary for the return value instead, for these kinds of virtual calls? That should remove any potential overlap while allowing the call.
Code change:
} else { let args: Vec<_> = args .into_iter() <del> .map(|arg| unpack!(block = this.as_local_operand(block, arg))) </del> <ins> .map(|arg| unpack!(block = this.as_local_call_operand(block, arg))) </ins> .collect(); let success = this.cfg.start_new_block();

Related discussion:
text: (Unrelatedly, I just realize we use a copying-out shim for vtable entries that take by value, even when would be passed as at the call ABI level. We would probably have to make computing the call ABI a query for this microopt to not be expensive)
That would result in being moved to a temp first before dropping and calling the boxed closure. If it wasn't moved first before the drop of , then borrowck would give an error. (I meant for this change to be done at mir construction level, not as an optimization pass, so borrowck should catch any soundness issues)
We can try it, I guess, but right now a lot relies on many redundant copies/moves being created by MIR building and may not catch edge cases like this. But also I don't think moving out of a moves the itself today. Me too, but I was going with the "correct by construction" approach of creating a redundant copy/move, just on the return side, instead of the argument side, of the call.
After revisiting on triage, removing nomination.
pre-triage: nominated for discussion in the next weekly meeting.
I just checked and, a function call roughly this (touched up for clarity): Some of my previous comments assumed the wasn't there and the call would use the destination directly, but given that there is a move, that simplifies my suggestion. <hr/For virtual by-value calls, we can skip one move when building the MIR, specifically the move out of the dereference of a for the argument. Given that we already move the result of the call, there should be no aliasing caused by this, but if we decide to change anything about how we build MIR calls, we'd need to be extra careful. We can also make this pattern be gated by a separate feature-gate (rather than ), and make sure the standard library only uses that feature-gate and not . This should solve any alignment issues might have, because we'd not be using dynamic unless the broader feature is used.
OK, if I understand what's being proposed here, it is to excerpt a subset of the "original unsized-locals plan" -- specifically, to permit locals with unsized types, but only in contexts where we can be guaranteed that we can point to the original storage and don't actually have to move any value (and hence we don't require variable size stack frames).