jiebi/CodeConvo huggingface dataset:
Change:
// appropriately sized integer and we have to convert it let tmp = builder.bitcast(llforeign_arg, type_of::arg_type_of(ccx, rust_ty).ptr_to()); <del> builder.load(tmp) </del> <ins> let load = builder.load(tmp); llvm::LLVMSetAlignment(load, type_of::align_of(ccx, rust_ty)); load </ins> } else { builder.load(llforeign_arg) }

Discussion:
The attached source produces code that misbehaves on some platforms that are picky about memory access alignment. The code should exit with code 2, but on both Emscripten-generated JavaScript and ARMv5, it finishes with exit code 1 to indicate that the field is incorrectly tested as equal to . Changing the field to a type results in proper execution on these platforms. All optimization levels seem to cause it. Libraries that make use of structs with fields followed by enums seem particularly prone to this problem. It all works fine on platforms that allow unaligned memory access like x86, ARMv6, etc. Expected output: (x86, ARMv6) Actual output: (ARMv5, Emscripten) Note that the same ARM binary runs on both ARMv5 and ARMv6 platforms, producing the different results. See also: ( and removed)
To quote myself:
Change:
name = "std_shim" version = "0.1.0" dependencies = [ <ins> "core 0.0.0", </ins> "std 0.0.0", ]

Discussion:
This looks weird. Isn't a .dll the right thing for this target? cc
Could you try passing ? Seems like may not be making its way to Cargo, or the shim is really messing up here (probably the latter)

Because that's what the old build system does: but rustbuild and rsbegin.o ends up being an ELF on linux: The fix should be simple in theory. You just have to pass to the in the code linked above. But then you run in problems with the order of the operations: " not found for $TARGET". cc
FWIW, trying to cross compile to i686-pc-windows-gnu I get this: Trying to cross compile to x86_64-pc-windows-gnu results in
Yeah not passing would do it, should be easy to add though! (I think that's all that's necessary)
Actually, the solution is the opposite. rustbuild is building these startup files for linux but it should compile them for windows hence the has to be .
Oh right sorry "it" there was "would cause this problem", we should indeed pass !
Change:
<del> Subproject commit 67c04afc251ad7d80ea22e2056c93349e7e9df58 </del> <ins> Subproject commit 38b5f236d2c62ff0b1017efd183b193f5db33123 </ins>

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! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Some error message changes (cc ) broke Miri, but some "null pointer is not allowed for this operation" changes look... wrong? For example: (and many more) They are all not .
Yeah my patch makes no sense... working on a fix.
I don't think the toolstate is fixed: ! But it's just error message differences: claim
Change:
#[multipart_suggestion( lint_addr_suggestion, style = "verbose", <del> applicability = "machine-applicable" </del> <ins> // FIXME(#53934): make machine-applicable again applicability = "maybe-incorrect" </ins> )] Cast { deref_left: &'a str,

Discussion:
No response The lint is marked able but applying the suggestion fails: ` No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Same problem with
claim
I think this is a known issue with with applying all suggestions even if they are multually exclusive. I'm pretty sure there's nothing to do in the lint, it correctly suggests the two (valid) suggestions, only one of them should be applied.
Well we can either remove one of the suggestions or make the lint MaybeIncorrect or something?
I think this is We can't remove one of the suggestions, they are both necessary. We can however make them for the time being.
That is indeed unfortunate.
Change:
}; use crate::clean; <ins> use crate::clean::inline::build_external_trait; </ins> use crate::clean::{AttributesExt, MAX_DEF_IDX}; use crate::config::{Options as RustdocOptions, RenderOptions}; use crate::config::{OutputFormat, RenderInfo};

Discussion:
For example  should have a bound, but we're a little too aggressive about pruning out the bounds. For comparison  does indeed have the bound. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This also applies to bounds on traits.
This prompted a question on IRC about whether requires , because the bound is not visible in the libstd documentation. It is visible in the libcore docs though.
Triage: This still happens
This actually ended up biting me today, is there a plan to handle this? I could help implement if I get pointers
did not fix this - it now shows , which is nice, but it doesn't show bounds on traits. For traits it does matter because the default is .
I would start by finding out why this is different between local crates and cross-crate re-exports. I expect is behaving differently from .
Ah, I also hit this today when looking at . Kudos to whoever can figure this one out :)
claim
Change:
#[no_mangle] // CHECK-LABEL: @wider_reduce_into_iter pub fn wider_reduce_into_iter(x: Simd<u8, N>) -> u16 { <del> // FIXME MIR inlining messes up LLVM optimizations. // WOULD-CHECK: zext <8 x i8> // WOULD-CHECK-SAME: to <8 x i16> // WOULD-CHECK: call i16 @llvm.vector.reduce.add.v8i16(<8 x i16> </del> <ins> // CHECK: zext <8 x i8> // CHECK-SAME: to <8 x i16> // CHECK: call i16 @llvm.vector.reduce.add.v8i16(<8 x i16> </ins> x.to_array().into_iter().map(u16::from).sum() }

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. --I tried this code: code originally from <!-- 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. --: When compile with , there is a which does not occur with `
Due to inlining of :
does the no_mangle attr have done kind of effect? can't check on mobile right now
I think it's more likely the struct's being ignored when performing that field access. cc
A slightly simplified example: It only arises when inlining a generic function (in this case ) that bitcasts a .
The difference seems to be that bitcasts a pointer to a vector, while the inlined bitcasts a vector directly. I suspect that the extra move that happens when is inlined causes vector value to be stored behind a pointer. I can reproduce the crash using just to force an extra move. As for why puts the vector behind a pointer, the default rust abi passes vector types by-ref to ensure that changing target features doesn't change the abi.
With that crashes at and without it gives the following LLVM ir:
It's interesting that the failure (in my example) required to be generic—that shouldn't affect the ABI of the monomorphized function, should it?
Indeed. It shouldn't affect the ABI.
The original no longer crashes since , but still does
Triage: The above mentioned example now compiles fine with the latest nightly, I guess is related. Marking as .
Change:
pub sign: OverflowingBinHexSign, #[subdiagnostic] pub sub: Option<OverflowingBinHexSub<'a>>, <ins> #[subdiagnostic] pub sign_bit_sub: Option<OverflowingBinHexSignBitSub<'a>>, </ins> } pub enum OverflowingBinHexSign {

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. --I tried this code: I expected the code to compile since its i am assigning into x binary representation of i32::MIN, instead the compiler throws an error. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Similar issue happens with i16 as well where the below code dosen't compile
This looks intended to me. The binary literal , along with all other integer literals, represents the number in a more mathematical sense, instead of in a memory layout sense, so really means the integer , not (=)
A similar code compiles in c++ and hence I assumed it was a bug.
The C++ code works because C++ has implicit integer conversion. On a typical int = 32bit platform, means (in both rust and C++), and is typed in C++ (because it doesn't fit in . "The type of the integer literal is the first type in which the value can fit"), and then when you assign it back to int32_t, the result is {implementation-defined (C++17 or earlier)} / {reinterpreted in terms of 2's complement(C++20 or later)}, which gives you back i32::MIN. Its rust equivalent code should be
Ohh okay. Thanks for this information. Now I too feel that this behavior was intentional.
So it sounds like the problem here is that the diagnostic doesn't teach all this.
A nice diagnostic would be that, if an overflowing literal has "sign bit" set, guess the user wants to express a negative number in 2's complement, and suggest using the negative number literal
I can try and give this a shot. claim
Thus that very weird and probably a bad practice in most case. Doing binary operation on signed number is never a good thing in my book.

In that case, the compiler emits an error if you do it at compile-time since it's a case of the operation inducing wraparound (which lands on the same value). That's not a satisfying answer as to why the mere literal fails to compile.
Sorry, I haven't had the time to work on this. Releasing in hopes someone can pick it up. release-assignment
I'd like to give this a try, but I need some assistance as I have no experience working on the compiler. claim My idea is to add another and when the literal fits in the unsigned variant, but not the signed variant (in the provided example, and respectively) Facing a blocker now. How could one emit multiple suggestions (that share the same span) or "help"s? Would love to hear suggestions or guidance :)
Thank you all for closing this
Change:
<ins> // aux-build: issue-118809.rs #[macro_use] extern crate issue_118809; #[derive(Deserialize)] //~ ERROR mismatched types [E0308] pub struct Build { } fn main() {} </ins>

Discussion:
No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Short code to reproduce the issue.
Change:
/// avoid cloning the waker when they would wake the same task anyway. #[inline] #[must_use] <del> #[stable(feature = "futures_api", since = "1.36.0")] </del> <ins> #[unstable(feature = "local_waker", issue = "118959")] </ins> pub fn will_wake(&self, other: &LocalWaker) -> bool { self.waker == other.waker }

Discussion:
The following code leaks memory: Miri error: The equivalent code with , so I think this is a bug. Cc
I guess this is not too surprising... has but has nothing like that.
Oh, that's may bad. I assumed that RawWaker handled ownership. I can push a PR today in the evening.
This leads to a miri-test-libstd failure every day, would be nice to get a fix soon. :)
Change:
"`...` range patterns are deprecated" } <del> declare_lint_pass!(EllipsisInclusiveRangePatterns => [ELLIPSIS_INCLUSIVE_RANGE_PATTERNS]); </del> <ins> pub struct EllipsisInclusiveRangePatterns { /// If `Some(_)`, suppress all subsequent pattern /// warnings for better diagnostics. node_id: Option<ast::NodeId>, } impl_lint_pass!(EllipsisInclusiveRangePatterns => [ELLIPSIS_INCLUSIVE_RANGE_PATTERNS]); impl EllipsisInclusiveRangePatterns { pub fn new() -> Self { Self { node_id: None, } } } </ins> impl EarlyLintPass for EllipsisInclusiveRangePatterns { <del> fn check_pat(&mut self, cx: &EarlyContext<'_>, pat: &ast::Pat, visit_subpats: &mut bool) { </del> <ins> fn check_pat(&mut self, cx: &EarlyContext<'_>, pat: &ast::Pat) { if self.node_id.is_some() { // Don't recursively warn about patterns inside range endpoints. return } </ins> use self::ast::{PatKind, RangeEnd, RangeSyntax::DotDotDot}; /// If `pat` is a `...` pattern, return the start and end of the range, as well as the span

Discussion:
The parameter is a hack (to fix ) that should be refactored. The idea is that the state should be contained in instead. This should be straightforward to fix. the parameter from (You'll also need to update the signature of in . a method with an identical signature below it. the condition from an early lint pass for at the end. a field to in (Look at for an example of a lint with fields.) You'll also need to initialise it with here: should be replaced with an assignment of the new field in to : should be early-exited if the field is . a implementation to and reset the field to if the pattern ID matches the field ID. sure the UI tests still pass with no changes.
hi I'm happy to take care of this one if it's not taken already.
go ahead! Let me know if you have any questions or problems with the implementation! :)
Change:
use rustc_ast::attr; use rustc_ast::node_id::NodeMap; use rustc_ast::ptr::P; <del> use rustc_ast::visit::{self, AssocCtxt, Visitor}; </del> <ins> use rustc_ast::visit::{self, AssocCtxt, FnCtxt, FnKind, Visitor}; </ins> use rustc_data_structures::fx::FxHashSet; use rustc_errors::struct_span_err; use rustc_hir as hir;

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. --: Also occurs on nightly at <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Semicolon is not the main problem here. Standalone semicolons are allowed as items inside function body. Second function definition would be OK if not for the extern "C" block — AFAIK only function declarations are allowed there, so is not valid syntax.
Prioritized as as per .7B.3B.60)
claim
A possibly clearer repro:
glacier ""
The previous issue has been fixed, let's try again (sorry for the noise!). glacier ""
Change:
min_length: _ } => { let lloffset = common::C_u32(bcx.ccx(), offset); let llindex = self.prepare_index(bcx, lloffset); <del> (build::InBoundsGEP(bcx, tr_base.llval, &[llindex]), </del> <ins> let zero = common::C_uint(bcx.ccx(), 0u64); (build::InBoundsGEP(bcx, tr_base.llval, &[zero, llindex]), </ins> ptr::null_mut()) } mir::ProjectionElem::ConstantIndex { offset,

Discussion:
will fail to compile with an LLVM abort: Seems to be a mis-translation of indexing (trans/mir/lvalue at ).
This is not related to According to we might do something incorrectly with GEPs.
That was my first guess, but it seems that is an rvalue with the type , suggesting itself was loaded.
Oh, my first guess was right: all GEPs are but that's not enough. You see, GEP's first index is for the pointer itself. currently gets (mistakenly) translated as instead of the (correct) . All GEP calls should use as the first index and then the index of the array element/struct field.
Change:
hir::ExprKind::Loop(ref b, _, source) => { self.with_context(Loop(source), |v| v.visit_block(&b)); } <del> hir::ExprKind::Closure(_, ref function_decl, b, _, _) => { </del> <ins> hir::ExprKind::Closure(_, ref function_decl, b, _, movability) => { let cx = if let Some(GeneratorMovability::Static) = movability { AsyncClosure } else { Closure }; </ins> self.visit_fn_decl(&function_decl); <del> self.with_context(Closure, |v| v.visit_nested_body(b)); </del> <ins> self.with_context(cx, |v| v.visit_nested_body(b)); </ins> } hir::ExprKind::Block(ref b, Some(_label)) => { self.with_context(LabeledBlock, |v| v.visit_block(&b));

Discussion:
With: you get: Note how it references "a closure" which seems confusing for a user who doesn't presume the implementation. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I'm assuming its ok to leave this as the same error code of E0267 - in essence it's the same error, just more specific text.
Yeah I think it's fine.
Change:
#![feature(const_bigint_helper_methods)] #![feature(const_black_box)] #![feature(const_char_encode_utf16)] <del> #![feature(const_char_encode_utf8)] </del> #![feature(const_eval_select)] #![feature(const_exact_div)] #![feature(const_float_classify)]

Discussion:
Feature gate: This is a tracking issue for supporting in const scenarios. [x] Implementation: [x] Address diagnostics: [x] Final comment period (FCP) [x] Stabilization PRNone yet.
fcp merge for
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [ ] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
I'll note that in the , making this const seems to require making the panic error message worse (even in the case where isn't used in a context) and also introducing more uses of . I'm not especially happy about that.
The use of unsafe code cannot be avoided as long as slice indexes aren't const-friendly (AFAIK). But I would argue that this use is properly documented and (relatively) invulnerable to UB, although I am open to other views on this. has also noted that could be used to regain full diagnostics in non-const calls – a feature which I would be more than happy trying to implement.
We could have a safe "const fn subslice" that does the bounds check and then uses unsafe fromrawparts. That would avoid introducing new unsafe reasoning in encode_utf8 itself.
resolves the diagnostics question. Can this be without conflicting with the FCP?
Yeah that should be fine. Thank you! I appreciate that. :-)
Plesse add a FIXME(const-hack) next to the const-eval-select to document that it should be removed again in the future, when possible.
Done. :)
:bell: This is now entering its final comment period, as per the . :bell:
Am I supposed to draft a stabilisation PR or is that outside my domain?
If you want to then yes you can draft a stabilization PR. :) Please link it to this issue and mention that it must only land once FCP has completed.
stabilises this.
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon.
Change:
IsInFollow::Yes }, "stmt" | "expr"  => { <del> let tokens = vec!["`=>`", "`,`", "`;`"]; </del> <ins> const TOKENS: &[&str] = &["`=>`", "`,`", "`;`"]; </ins> match tok { TokenTree::Token(token) => match token.kind { FatArrow | Comma | Semi => IsInFollow::Yes, <del> _ => IsInFollow::No(tokens), </del> <ins> _ => IsInFollow::No(TOKENS), </ins> }, <del> _ => IsInFollow::No(tokens), </del> <ins> _ => IsInFollow::No(TOKENS), </ins> } }, "pat" => { <del> let tokens = vec!["`=>`", "`,`", "`=`", "`|`", "`if`", "`in`"]; </del> <ins> const TOKENS: &[&str] = &["`=>`", "`,`", "`=`", "`|`", "`if`", "`in`"]; </ins> match tok { TokenTree::Token(token) => match token.kind { FatArrow | Comma | Eq | BinOp(token::Or) => IsInFollow::Yes, Ident(name, false) if name == kw::If || name == kw::In => IsInFollow::Yes, <del> _ => IsInFollow::No(tokens), </del> <ins> _ => IsInFollow::No(TOKENS), </ins> }, <del> _ => IsInFollow::No(tokens), </del> <ins> _ => IsInFollow::No(TOKENS), </ins> } }, "path" | "ty" => { <del> let tokens = vec![ </del> <ins> const TOKENS: &[&str] = &[ </ins> "`{`", "`[`", "`=>`", "`,`", "`>`","`=`", "`:`", "`;`", "`|`", "`as`", "`where`", ];

Discussion:
E.g. in a vec is created, only to be thrown away if the macro actually works out. I think we can just turn most places into an early return in the happy path and then only allocate in the error path. Do not work on this issue before is merged. Also, hasn't had its docs updated to reflect the source changes.
Are there any reasons to not use constant/static slices and convert them to vecs on demand? Or maybe even convert to something like so there's no need to allocate vecs (In all cases) anymore?
That's a great idea! I haven't checked whether it'll work everywhere, but I think it should.
Change:
<ins> // edition:2021 #[allow(async_fn_in_trait)] pub trait BleRadio<'a> { async fn transmit(&mut self); } </ins>

Discussion:
I was developing one trait in one crate, changing it to use a lifetime, and forgot to add it to the other crate's implementation. The compiler shows de correct error message but breaks. If I fix the code, adding the lifetime to the trait, de compiler works. If it is in the same crate also works. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Same backtrace as .
Thanks for the minimized test! I'll fix this tomorrow.

<!-- 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. --While I was trying to add lifetimes for picoserve's I got into ICE (1.) had a dep of picoserve as 2. That code isn't finished and should not compile yet <!-- 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. --: has ice files
rustc 1.75.0 ( 2023-12-21) binary: rustc commit-hash: commit-date: 2023-12-21 host: x86_64-unknown-linux-gnu release: 1.75.0 LLVM version: 17.0.6 Here ICE is also present
Backtrace from one of the linked files pasted below for the sake of searchability and preservation: <details<summaryBacktrace</summary</details
Change:
#[rustc_legacy_const_generics(0)] //~ ERROR #[rustc_legacy_const_generics] functions must only have fn foo8<X>() {} <ins> impl S { #[rustc_legacy_const_generics(0)] //~ ERROR attribute should be applied to a function fn foo9<const X: usize>() {} } </ins> #[rustc_legacy_const_generics] //~ ERROR malformed `rustc_legacy_const_generics` attribute fn bar1() {}

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 --
minimized: I think it's just that this attr ICEs when attached to methods and not functions.
claim