jiebi/CodeConvo huggingface dataset:
Code change:
/// Parses a statement. This stops just before trailing semicolons on everything but items. /// e.g., a `StmtKind::Semi` parses to a `StmtKind::Expr`, leaving the trailing `;` unconsumed. pub fn parse_stmt(&mut self) -> PResult<'a, Option<Stmt>> { <del> Ok(self.parse_stmt_(true)) } fn parse_stmt_(&mut self, macro_legacy_warnings: bool) -> Option<Stmt> { self.parse_stmt_without_recovery(macro_legacy_warnings).unwrap_or_else(|mut e| { </del> <ins> Ok(self.parse_stmt_without_recovery(true).unwrap_or_else(|mut e| { </ins> e.emit(); self.recover_stmt_(SemiColonMode::Break, BlockMode::Ignore); None <del> }) </del> <ins> })) </ins> } fn parse_stmt_without_recovery(

Related discussion:
text: Although I would also guess that the initial idea is very unlikely to end up accepted, it feels premature to unilaterally hijack the thread in your very first comment and make it have a different (and in a way opposite) purpose. Teams of the Rust project are designed to make decisions collectively. Improving diagnostics sounds good, but issue numbers are cheap.
Implementing something as a diagnostic actually brings you closer to a working implementation -- I think more proposals should start out as diagnostics. I will not bother the other language team members with not-fully-formed proposals that we will not accept in either case. I converted the issue into the most actionable and productive thing it could be. The place for ephemeral discussions is either on Discord or on internals. If you want to discuss this further, I'm available at Discord (but will not respond to it further here). wasting everyone's time with things that will go nowhere (because it won't be accepted and because it is not important enough to be raised at the team) is not.
IMHO, the original thing this issue was opened for should be an RFC, not an issue. I'd have closed this, pointed the OP to the RFCs repo, and opened a new issue for the diagnostic issue.
This issue was literally in the RFCs repo initially, transferred it from there.
Language bashing is not welcome here
Wait, so should I unassign here, and assign to the new issue?
Nah, just use this one.
Yeah, thats fine. You can just change this issue to be for diagnostics instead.
I'm sorry, I've been pretty busy with coursework, and I'm still fighting my Python installation to even build the compiler, let alone make progress on this. Sorry :(
I'll assign this to myself to work on when I have time. If you want to work on it however, feel free to work-steal it from me!
I would like to help with this
Sorry; should have updated this issue...! There's a PR at the moment. Feel free to leave suggestions on it if you like. :)
Code change:
/// Parses a statement. This stops just before trailing semicolons on everything but items. /// e.g., a `StmtKind::Semi` parses to a `StmtKind::Expr`, leaving the trailing `;` unconsumed. pub fn parse_stmt(&mut self) -> PResult<'a, Option<Stmt>> { <del> Ok(self.parse_stmt_(true)) } fn parse_stmt_(&mut self, macro_legacy_warnings: bool) -> Option<Stmt> { self.parse_stmt_without_recovery(macro_legacy_warnings).unwrap_or_else(|mut e| { </del> <ins> Ok(self.parse_stmt_without_recovery(true).unwrap_or_else(|mut e| { </ins> e.emit(); self.recover_stmt_(SemiColonMode::Break, BlockMode::Ignore); None <del> }) </del> <ins> })) </ins> } fn parse_stmt_without_recovery(

Related discussion:
text: From The following code should be using the common list parsing utilities: CC
What/where are the common list parsing utilties? Edit: never mind, I've got it. , , etc. for anyone who's wondering.
Code change:
label: &Destination, cf_type: &str, ) -> bool { <del> if self.cx == LabeledBlock { </del> <ins> if !span.is_desugaring(DesugaringKind::QuestionMark) && self.cx == LabeledBlock { </ins> if label.label.is_none() { struct_span_err!( self.sess,

Related discussion:
text: I've been playing around with today, and it comes in super handy in blocks. However, it seems to run into issues when combined with the feature. I tried this code: I expected to see this happen: the code should compile just fine. Instead, this happened: This is a continuation of the discussion . As , this code (following the from the label-break-value RFC) compiles: : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
So the error is generated here if I had to guess, I would assume that this function ought to be modified to check whether the and, if so, not to emit the error. (See  rust docs for a bit more info.)
Tagged as E-mentor since there are some instructions above.
claim
Code change:
<del> Subproject commit a7348ae0df3c71581dbe3d355fc0fb6ce6332dd0 </del> <ins> Subproject commit e048e97f5280e8a232a43ae134d395aeab67c2e8 </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 attach a tarball with a small reproducer (few dependencies from , lock file, empty ). Now run this using rustc 1.56.0: I expect the sha256sum to be the same for the libpalette so file but it's often different. This breaks any binary caches, similarly to what did but that ticket turned out to be a problem with the crate. This time it seems problem with itself (or rather LLVM: stay tuned): 1.55.0 produces same binary/crate hash on every build. Note that in there's: Without this, the issue does not present itself. This perhaps makes it look similar to or but I think it's different. As far as I saw, it didn't produce a difference in ordering of symbols in the resulting though I may be mistaken. Please feel free to close as duplicate if you deem it to be the same issue. I have ran with and after careful sifting through few GiB of output, I found the differences seem to start in . I have bisected itself and ran it on our original code which exhibited the problem. I started the bisect at common merge point with 1.55.0 though the problem turned out well into the 1.56.0 release: cc who did the update : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
One thing I found: if I run it with I can't reproduce it anymore. claim
Well, I was wrong. Still reproducible even with . Produced files are identical though.
Consistent with my findings with as well.
Update: this IS a LLVM bug, I'm able to reproduce it with just ll input file using mainline LLVM. Filed to LLVM.
I have a fix: Do we want to apply it to llvm-rust or are we going to wait for LLVM review?
Good job, thank you!
I wonder if rust needs too.
Answering my own question: it does.
Could you also do a PR for
Sure, will do.
Code change:
<del> Subproject commit a7348ae0df3c71581dbe3d355fc0fb6ce6332dd0 </del> <ins> Subproject commit e048e97f5280e8a232a43ae134d395aeab67c2e8 </ins>

Related discussion:
text: Created
Actually I was too slow, there is already
FWIW, while taking the 1.56.0 source and applying the 2 LLVM reproducibility patches fixes the issues we have with Firefox, the latest nightly doesn't: there's a remaining reproducibility issue on i686 linux. I'll test a patched beta next.
The next beta release should be fixed, per . (Should go out near 00:00 UTC -- I guess it will be .)
the beta branch + the patches seems to fix it, but I've found something new: depending how llvm is built, the result can vary. Specifically, llvm built with a sysroot exhibits reproducibility issues that are not present when not building with a sysroot. I'll wait for the official build for 1.57.0-beta.4 for a definite answer whether the issue is fixed. One thing is sure, though, there's an additional regression in nightly.
So, as far as Firefox is concerned, everything is fixed in the latest betas. I did find a source of non-determinism that is not fixed, but a) it seems to also affects clang (as in, I also have found one in clang, and I think it's the same root cause) b) it goes away with PGO, so it doesn't actually affect Firefox.
is there a ticket about this one somewhere? It's great that it doesn't impact Firefox but it may be impacting other rust software
I haven't filed it because the smallest reproducer I have at the moment is "build firefox with these flags and observe how sometimes some functions have an extra mov", and from experience, those don't lead to any action.
I see, thanks. It sounds like binary-reproducability thing and ABI should(?) be the same at least. And this is a regression in new LLVM version (rustc 1.56 and beyond)?
I don't know if this affects rustc, but I narrowed down yet another source of non-determinism in debuginfo, and upstream came up with a patch:
We tried using 1.57.0 and it seems broken still. I'll try to get a repro tomorrow. Should I open a new ticket or will someone reopen this one?
Actually, seems it comes from a derive crate in our dependency tree, similar to what we saw in ; So maybe it's fine.
Code change:
} impl<'tcx> FieldDef { <del> /// Returns the type of this field. The `subst` is typically obtained /// via the second field of `TyKind::AdtDef`. </del> <ins> /// Returns the type of this field. The resulting type is not normalized. The `subst` is /// typically obtained via the second field of `TyKind::AdtDef`. </ins> pub fn ty(&self, tcx: TyCtxt<'tcx>, subst: SubstsRef<'tcx>) -> Ty<'tcx> { tcx.type_of(self.did).subst(tcx, subst) }

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. --When compiling on an Apple M1 processor: <!-- 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
Can also reproduce this when compiling on an Intel Macbook
I've encountered the same error on a different platform (x8664) when compiling . The project doesn't use cargo so repro is nontrivial, but from I can see that the ICE started occurring at which is a rollup of . <details<summary<strongBacktrace</strong</summary<p</p</details
Also seems to be hitting starlark-rust, , as per
Somewhat minimized standalone testcase: Builds on stable, fails on nightly. cc
Thanks for the minimization! Seems like we've hit again, but through a different code path. I'm investigating.
I think might be another duplicate of this, triggered when compiling the crate.
Code change:
<ins> // only-x86_64 // check-fail #![feature(lang_items, no_core, target_feature_11)] #![no_core] #[lang = "copy"] pub trait Copy {} #[lang = "sized"] pub trait Sized {} #[lang = "start"] #[target_feature(enable = "avx2")] //~^ ERROR `start` language item function is not allowed to have `#[target_feature]` fn start<T>(_main: fn() -> T, _argc: isize, _argv: *const *const u8, _sigpipe: u8) -> isize { 0 } fn main() {} </ins>

Related discussion:
text: This works (but it shouldn't): similar to , cc (tracking issue) label T-lang T-compiler C-bug I-unsound F-targetfeature11
cc , author of Note that this is about the nostd panic handler, not about the function. This fails as it should: gives
ugh we really need a way to make sure that every single "this is called by rust" function gets a check... I assume that these functions can't be unsafe, so I guess those checks are a food way to start looking and make sure to deduplicate the logic there?
Yeah sadly we do need to make sure, not just for the constructs that we have now but also it needs to be kept in mind for the future constructs we add or stabilize. A lot thankfully goes through either the trait system (operators or the GlobalAlloc trait used by ) or function pointers (alloc error hook, std panic hook). Functions that you can make callable solely by setting an attribute, those are rare. The best list of lang items I could find was in the , so that would be a great start for such an exhaustive search. Thankfully most of them are unstable, but still it needs to be addressed for each of them before stabilization (if that is a target).
WG-prioritization assigning priority (). label -I-prioritize +P-medium
label +requires-nightly
There is also another table of lang items in the source code, .
Code change:
use rustc_middle::mir::interpret::{sign_extend, truncate}; use rustc_middle::ty::layout::{IntegerExt, SizeSkeleton}; use rustc_middle::ty::subst::SubstsRef; <del> use rustc_middle::ty::{self, AdtKind, ParamEnv, Ty, TyCtxt, TypeFoldable}; </del> <ins> use rustc_middle::ty::{self, AdtKind, Ty, TypeFoldable}; </ins> use rustc_span::source_map; use rustc_span::symbol::sym; use rustc_span::{Span, DUMMY_SP};

Related discussion:
text: While reviewing I noticed for the first time that the improperctypes lint normalizes with the "revealall" mode. I don't have a nuanced understanding of what that means exactly but based on the general description in the rustc docs and experimentation (see below) I think that's probably the wrong choice for this lint, because it exposes details to the user that are normally hidden during type checking. For example, using existential types, the lint pierces through otherwise-opaque existentials to look at the underlying (hidden) type, thus it both accepts code that is only FFI-safe because of the particular type underlying the existential, which users of that type shouldn't know or rely on leaks the underlying type to the user in error messages when (correctly) rejecting uses of an existential type as FFI-unsafe I can't quickly find an equivalent using only stable , because we don't have , but if there's a way to write "Option of the return type of this function" in stable Rust, then that would presumably have the same issue. cc for fact-checking my understanding that this is because of reveal_all
User-facing diagnostics should avoid the mode, yeah. In fact, the other variant of is literally - also the doc comments are pretty explicit about this: cc
I've been using 's over in recent PRs that modify the lint (see , , and ). In each recent PR, I've ensured that opaque types are prohibited (in the spirit of "FFI-safety of a type not relying on particular type behind an opaque type being FFI-safe") - with the exception of when a opaque type is used in a projection (). Unless there are specific examples of behavior that still need to be changed as a result of this issue - should this issue be closed?
My litmus test for closing this would be "all the normalizing done in improper_ctypes uses ", which is hard to audit for while there's multiple PRs in flight that address parts of the problem. After those PRs are all merged, we can see if there's any remaining and if so, their location should tell us how to exercise any remaining questionable behavior.
I've opened to fix the remaining two places that is used now that the other PRs have landed.
Code change:
/// } /// ``` #[must_use] <del> #[unstable(feature = "panic_info_message", issue = "66745")] </del> <ins> #[stable(feature = "panic_info_message", since = "CURRENT_RUSTC_VERSION")] </ins> pub fn message(&self) -> PanicMessage<'_> { PanicMessage { message: self.message } }

Related discussion:
text: was closed when stabilized the corresponding language feature, but we didn’t realize that it was also the tracking issue for this standard library feature: History: [x] Original tracking issue: [x] Discussion of payload vs message [x] Making .message() infallible: [x] Split core/std PanicInfo into two types: This made core::panic::PanicInfo::message() infallible. [x] Use opaque return type: [x] FCP [x] Stablization PR: Unresolved questions: [x] Should it be infallible? Yes, by making std::panic::PanicHookInfo a different type. [x] What should the return type be? or an opaque ? The first is simpler, but the latter allows a bit more flexibility for future changes.
Instead of making a PR go through the queue to fix the tracking issue, should we stabilize this method? fcp merge The doc-comment is slightly wrong or out of date. Its second line shoudl be removed. always creates a where is , regardless of the number of arguments given. In the single-argument case, that argument is required to have type . At first returning seemed unusual to me and I considered that we could make the method return instead, on the basis that calling its impl is almost the only useful thing to do with a . But has been stable and documented as the return type of since 1.0.0, so maybe it’s fine.
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [ ] [x] [x] [ ] [ ] [ ] Concerns: single-arg core::panic () 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.
The module also links to that closed tracking issue. Let’s consider the pFCP above to also include stabilizing it. ( is stable.)
concern single-arg core::panic Should we change libcore’s macro so that its single-argument form creates a with a instead of one with a ?
Code change:
/// } /// ``` #[must_use] <del> #[unstable(feature = "panic_info_message", issue = "66745")] </del> <ins> #[stable(feature = "panic_info_message", since = "CURRENT_RUSTC_VERSION")] </ins> pub fn message(&self) -> PanicMessage<'_> { PanicMessage { message: self.message } }

Related discussion:
text: CC Pushing this idea further, it’s tempting to maybe remove entirely and instead have a whose dynamic type can be . But that doesn’t work because is a method of and is not .
I thought the point of the message field was that core can't make a payload since it can't allocate?
The struct is: Both the and fields involve borrowing. As far as is concerned, they could both be borrowing form a stack frame. (And as far as I understand they are, in practice today.) It’s in the case of unwinding that there’s an owned that can return, which requires allocating.
Based on the timing of it looks like you may have thoughts on this :)
Ah, goes into how and why the panic handler in libstd (which is called by if libstd is linked) ignores the it receives. We could probably change this but it gets tricky: while most implementations of for environments would be fine with receiving a borrowed payload, libstd wants to potentially take ownership and box it for unwinding.
I have zero recollection for why this is the way it is, and I'm not really particularly interested in doing all the archaeology to dig up why it is the way it is. I'm not a huge fan of just stabilizing things because they happen to be there, but I don't really see why we wouldn't want to stabilize this. If there were a reason to not stabilize this though an investigation would presumably turn that up, but I'm not up to do that investigation myself.
That’s totally fair. I’m confident that this was more likely forgotten than deliberately left unstable. If deliberate we would have kept the tracking issue open or made a new one for the remaining bits. This is what lead me to propose stabilization. Having dug a little more, and thanks to Ralf’s blog post, I think we may want at some point to revisit what data we expect to contain or not in various situation. In particular it could be interesting to extend to support payloads other than and make it closer to . Given those possibly-desirable changes, it may not be the time to add more constraints: fcp cancel
proposal cancelled.
Lol, I had no idea. ;) So, indeed, I was wondering if we could do something about the duality of the and fields in . I assume we cannot change the fact that the same type is used both of panic handlers and panic hooks.
Code change:
/// } /// ``` #[must_use] <del> #[unstable(feature = "panic_info_message", issue = "66745")] </del> <ins> #[stable(feature = "panic_info_message", since = "CURRENT_RUSTC_VERSION")] </ins> pub fn message(&self) -> PanicMessage<'_> { PanicMessage { message: self.message } }

Related discussion:
text: Concretely, I was thinking of adjusting somewhat like this: That would at least remove the need for the hack in . (The hack would likely move to instead, but that is a smaller hack IMO: the hack is now not encoded in the state of any more, just in its dynamic API.) I think this would retain all current functionality while clarifying the invariant of wrt. the payload (and explicitly calling the message a "payload"; right now it seems to be something that sits next to the payload which is inaccruate). But there are enough subtleties here that we'll only really know once someone implements this. With this change, the panic hook would always get a . We should likely provide a method somewhere in libstd to factor out this code: I was imagining something like an extension trait on with a type like . However, the panic hook is not the only place where that conversion is useful; another situation is code that caught a panic and wants to extract the message. I expect most instances of that to just handle payloads, not knowing that payloads are also common (that is certainly what happened when I wrote such code). So ideally we'd have a method that takes and returns , but I do not have a good idea where to put that. This is the hard part, as we cannot use . I wonder if we can use a take-based approach, similar to ? Conceptually, would put the panic into an , and somehow pass an to the panic handler, and the implementation of said handler could then the payload if it needs full ownership (like for unwinding). Except the panic handler cannot be generic, so it would have to be , which is not a thing. But with enough unsafe code we could re-implement something that behaves like that. I don't see any way to do this entirely safely; the panic handler that wants to take out the payload and put it somewhere needs to dynamically determine the size of the payload and arrange for there to be enough space. In liballoc, we could provide a safe wrapper for this that puts things into a , but in libcore, I don't think there is a safe API that we could provide to grab ownership.