jiebi/CodeConvo huggingface dataset:
Change:
## `Cell<T>` <del> [`Cell<T>`][cell] is a type that provides zero-cost interior mutability, but only for `Copy` types. </del> <ins> [`Cell<T>`][cell] is a type that provides zero-cost interior mutability by moving data in and out of the cell. </ins> Since the compiler knows that all the data owned by the contained value is on the stack, there's no worry of leaking any data behind references (or worse!) by simply replacing the data.

Discussion:
broke a library of mine where I had code like this: calls that used to call this trait method now call the new inherent method, but since that’s unstable the crate didn’t build until I . After that I could remove the trait since the new method has the same behavior. Anyway, this is just FYI. If we don’t want this kind of breakage we can’t add any new method to existing types ever, so that doesn’t sound viable. If the new method had had different behavior or if I wanted to keep supporting older compilers, it wouldn’t be too hard to rename my trait’s method or use UFCS.
Yeah in general we reserve the right to break downstream code with differences in method resolution because the downstream code can always be written in an "elaborated" form which works on all compilers (e.g. using ufcs). If a change to the standard library breaks an excessive amount of code in the ecosystem, though, then we'd need to take the steps much more purposefully.
Sounds good. Again, I don’t expect anything to change here and only made the previous comment to let people know this happened. I made this particular crate as an experiment, I don’t know of anyone actually using it.
Given that the core changes to the bounds on existing methods were instantly stable, it doesn't make a lot of sense to keep and as unstable. I propose we immediately stabilize these APIs. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, 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.
ping (checkbox)
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.
What’s the next step here? Batch stabilization PR near the end of the release cycle?
Yep, I'm preparing one right now.
Change:
use std::ops::Bound::*; use std::panic::{catch_unwind, AssertUnwindSafe}; use std::rc::Rc; <ins> use std::sync::atomic::{AtomicU32, Ordering}; </ins> use std::vec::{Drain, IntoIter}; struct DropCounter<'a> {

Discussion:
Looking here, the internal length of the vector is only adjusted at the end of the loop This has the caveat that if cloning panics, the Vec will start to unwind and only drop the first elements which doesn't include the most recently appended ones. Something more in line with how the stdlib does things might look like this: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is not unsafe, leaking items is safe:
Sure; never said it was unsafe. This is more about making sure programs who gracefully handle panics don't wind up eventually exhausting resources.
Assigning as part of the .
I would like to fix this claim
The fix seems pretty straight-forward. The Clone specialization just needs a RAII type that handles adjusting the Vec's new len in its Drop implementation, as I've linked in my MiniVec. Copy can't fail so there's no need to adjust that specialization. The only thing that could theoretically panic in that case would be reallocating and in that case, there's no need to worry about the len.
Change:
/// Used only for error recovery when arriving to EOF with mismatched braces. matching_delim_spans: Vec<(token::DelimToken, Span, Span)>, last_unclosed_found_span: Option<Span>, <ins> last_delim_empty_block_spans: FxHashMap<token::DelimToken, Span> </ins> } impl<'a> TokenTreesReader<'a> {

Discussion:
Many editors helpfully auto close delimiters when writing them down. It is not uncommon for this to cause the following to occur: It'd be a good idea for the parser or lexer to keep track of these empty blocks to provide an error closer to
can I take this on, if nobody is working on this?
go ahead!
Are you still working on this? I'm happy to take it if not.
Please allow me 2-3 days to check this issue.
Please take this forward.
Ok, I'll try to dive into.
Change:
<del> Subproject commit d9ae0285169e52050416fb3618f05b5fdf582b6b </del> <ins> Subproject commit d4e4fe71e6a9568f5d081d99f1c621c5a4ddd7db </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. 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! cc the PR reviewer, and nominating for compiler team prioritization.
triage: has PR (in ). Marking P-medium and removing nomination.
Change:
} } <ins> fn collect_non_exhaustive_tys<'p, 'tcx>( pat: &DeconstructedPat<'p, 'tcx>, non_exhaustive_tys: &mut FxHashSet<Ty<'tcx>>, ) { if matches!(pat.ctor(), Constructor::NonExhaustive) { non_exhaustive_tys.insert(pat.ty()); } pat.iter_fields() .for_each(|field_pat| collect_non_exhaustive_tys(field_pat, non_exhaustive_tys)) } </ins> /// Report that a match is not exhaustive. fn non_exhaustive_match<'p, 'tcx>( cx: &MatchCheckCtxt<'p, 'tcx>,

Discussion:
Sorry about the long title :sweat_smile: Given the following code (): The current output is: Note how the first diagnostic, emitted when matching on a , contains additional information about why this exhaustive match does not pass the exhaustiveness check. Ideally, this information should be to the second diagnostic as well: modify labels: +A-exhaustiveness-checking +A-patterns +D-terse
Hm, even though has a different size on different architectures, should always be exhaustive, right? Then that code would be accepted, but the following would still error: We could have the error for this say "missing pattern: ", which would also work if there's a around it. That said, pretty sure what you describe also happens for enums too, and there we'll want to do what you suggest.
see also
I forgot this issue existed, but yeah this is a lint we want. I explained a bit about how this might be done in , if anyone wants to tackle this feel free to ping me
Change:
pub fn is_tainted_by_errors(&self) -> bool { debug!( "is_tainted_by_errors(err_count={}, err_count_on_creation={},  <del> tainted_by_errors_flag={})", </del> <ins> tainted_by_errors={})", </ins> self.tcx.sess.err_count(), self.err_count_on_creation, <del> self.tainted_by_errors_flag.get() </del> <ins> self.tainted_by_errors.get().is_some() </ins> ); if self.tcx.sess.err_count() > self.err_count_on_creation { return true; // errors reported since this infcx was made } <del> self.tainted_by_errors_flag.get() </del> <ins> self.tainted_by_errors.get().is_some() </ins> } /// Set the "tainted by errors" flag to true. We call this when we /// observe an error from a prior pass. pub fn set_tainted_by_errors(&self) { debug!("set_tainted_by_errors()"); <del> self.tainted_by_errors_flag.set(true) </del> <ins> self.tainted_by_errors.set(Some( self.tcx.sess.delay_span_bug(DUMMY_SP, "`InferCtxt` incorrectly tainted by errors"), )); </ins> } pub fn skip_region_resolution(&self) {

Discussion:
should be to guarantee that we emit an error when that flag is set. This is already done for of other types in rustc. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
renamed to to keep consistent.
Change:
# Azure's Windows image. Having the conversion enabled caused regressions both # in our test suite (it broke miri tests) and in the ecosystem, since we # started shipping install scripts with CRLF endings instead of the old LF. <ins> # # Note that we do this a couple times during the build as the PATH and current # user/directory change, e.g. when mingw is enabled. </ins> - bash: git config --global core.autocrlf false displayName: "Disable git automatic line ending conversion"

Discussion:
Since the change from travis to azure pipelines some of the rust-std archives have DOS line endings in their script, which results in errors like the following when trying to execute: Running works around the issue for now. Not all archives have this issue. Specifically does. Possibly others as well, but our install process fails after the first error, so I am not sure. See mattgodbolt/compiler-explorer-image and mattgodbolt/compiler-explorer-image
Thanks for reporting this! A tentative fix for this landed in , hopefully tomorrow's nightlies will be fixed.
Still happening on :/
Oh, this is concerning, we'll need to look into it a bit more. Thanks for the update. modify labels: regression-from-stable-to-beta -regression-from-stable-to-nightly
May have been actually .. Double checking.
is also affected, does that mean src is now generated from Windows or this is broken even more than it seems?
This is caused by the Azure migration, as it started happening right after we switched nightlies production to it. The initial hypothesis was that git's on Windows was the culprit, but that landed days ago so we need to look deeper :/
The source tarball is generated by all the dist builders and uploaded each time, so the last dist builder to finish will be the one producing the final tarball. I think we see the error there just because our slower builders are all Windows at the moment.
Assigning myself to investigate in the next few days.
Relevant: https://git-
The fix should've landed in today's nightly. Thanks everyone for reporting this!
Just a note, you might want to spin up a beta build as well. was affected by this as well.
yes, beta is still not fixed. The fix was nominated for beta backport though, so once the team approves we will backport it to the beta branch.
We backported the change!
Change:
use core::prelude::*; use core::iter::{FromIterator}; <del> use core::mem::{zeroed, replace, swap}; </del> <ins> use core::mem::swap; </ins> use core::ptr; use slice;

Discussion:
BinaryHeap is using and may not be exception safe. I.e. it is in an inconsistent state after being recovered after panic. See issue and others. Relevant code is cc
My immediate ideas are one of Use PPYP and set vector length to zero temporarily. Panicing in comparison functions will leak all elements in the heap Use more swaps
got the idea:
Long ago I suggested two other strategies: A two-pass phase where you do all comparisons first, then once you've found the Final Destination you actually do the swaps (which requires no untrusted code to run). A panic guard which on drop puts the "working" element back in the "uninit" location in the array
triage: I-nominated, T-libs
I'm trying gankro's panic guard idea.
Change:
attribute. Such a function must have the following type signature (for more information, view [the unstable book][1]): <del> [1]: https://doc.rust-lang.org/unstable-book/language-features/lang-items.html#writing-an-executable-without-stdlib </del> <ins> [1]: https://doc.rust-lang.org/unstable-book/language-features/start.html </ins> ``` # let _:

Discussion:
or The examples don't compile and the list of items is outdated. Should the list at the bottom of the page still be updated? The amount of language items has grown and there's already a list . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim label: +A-lang-item
I think linking to the source code is better than trying to keep the list up to date, yes. We might still want to document the language items that are required for a binary, since those are "user facing" in a way the others aren't.
Ideally we could find a way to run rustdoc on the examples (as doctests) so they don't get outdated.
The guidance could be to the nomicon because there's already .
Change:
<ins> // run-pass // only-x86 // min-system-llvm-version: 16 // compile-flags: -Ctarget-feature=+sse2 use std::hint::black_box; fn main() { let n: i64 = black_box(0x3fffffdfffffff); let r = f32::from_bits(0x5a7fffff); assert_ne!((n as f64) as f32, n as f32); // FIXME: these assertions fail if only x87 is enabled assert_eq!(n as i64 as f32, r); assert_eq!(n as u64 as f32, r); } </ins>

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. --rust-num/num-bigint The code prints the output below and exits successfully. The code prints the output below and panics. <!-- 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. --:
Here's some reproduction on Godbolt. The problem seems unrelated to i64 and it's entirely the u64 -f32 conversion that's buggy. The fact that we use the floating point numbers as some sort of address makes it seem like we are loading the value from a lookup table and there might be a bug in Windows' table:
Took me way too long, but I figured it out. The fact that FPU instructions are used means that it runs into problems with the FPU accuracy. By default the control word is set to 0x27f on Windows and 0x37f on Linux. In particular the 0x3 vs 0x2 is the precision control setting of the FPU. 01 = Not used 10 = 53 bits (REAL8) 11 = 64 bits (REAL10) So on Windows it's in 53-bits mode whereas on Linux it's in 64-bits mode. Running the following code therefore fixes the problem on Windows: This probably is an LLVM bug where LLVM assumes the FPU is configured like on Linux instead of like on Windows. MSVC for example just emits a call to instead, which is probably the correct thing to do. (Also it's a little surprising to me the FPU is used at all, when i686 afaik even has SSE2 available by default).
The function that lowers the uint to float cast is in . There's basically a bunch of checks to generate shorter versions if various conditions are met, but all of them fail and it has to resort to using the FPU. There actually is one case in there where they treat Windows differently, I'm guessing something similar can be done to not fall into the FPU default case here as well. In particular because both SSE2 and a builtin function that does exactly this cast exist.
I tested it with some other code and thought it was resolved.
This was patched upstream (thanks icedrocket!)

but it seems like they reverted the patch, as unfortunately it broke Chrome's build: I don't know if it is more profitable to work around this on our end by emitting the relevant call? It looks like there's an intention to use another fix:
A new fix has been commited to upstream: llvm/llvm-project
Change:
use rustc_middle::ty::{self, DefIdTree, RootVariableMinCaptureList, Ty, TyCtxt}; use rustc_session::lint; use rustc_span::symbol::{kw, sym, Symbol}; <del> use rustc_span::Span; </del> <ins> use rustc_span::{BytePos, Span}; </ins> use std::collections::VecDeque; use std::io;

Discussion:
I got this error message recently: will work, but just removing completely from the pattern would be better. E.g. the suggestion could be . The particular example was within rustc, but it should be very easy to replicate in a self-contained example. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Is this ? Where does this suggestion come from? Can I please get the path for it!
claim
It's been 3 months - are you still working on this? If not, I'd like to claim it instead.
There was no activity for a while, so I took a liberty of implementing this. claim
Change:
use rustc_expand::base::{self, *}; use rustc_parse::parser::Parser; use rustc_parse_format as parse; <del> use rustc_span::symbol::{kw, sym, Symbol}; </del> <ins> use rustc_span::{ symbol::{kw, sym, Symbol}, BytePos, }; </ins> use rustc_span::{InnerSpan, Span}; struct AsmArgs {

Discussion:
People used to gcc/clang inline assembly may try using the or directives directly in the assembly string, which can cause issues. Ideally, we should detect attempts to use those directives. Attempting to use should generate an error stating that that's the default. Attempting to use should generate an error and point to the option, ideally with a rustfix-applicable suggestion. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Is anyone currently working on this? I would like to do it if not.
Not to my knowledge, no.
claim
Change:
<ins> // edition:2018 async fn test() -> Result<(), Box<dyn std::error::Error>> { macro!(); //~^ ERROR expected identifier, found `!` Ok(()) } fn main() {} </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --edit: I reduced some code of a different occurrence and came up with <!-- 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. --I bisected the regression to / <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Reduced code from another project that also triggers this ICE: `
Cargo-bisetc-rustc points to /
cc and
The error on stable is So it's a case of error-ICE.
After some trying I found out that this will panic for every keyword, that is followed by an unexpected token, in an async function, that returns
Assigning and removing as in the prioritization working group.
I can also reproduce the ICE with the following code:
After investigation, I think I have found the cause of the bug. When we get to the contained in is a , because of the invalid or or any wrong syntax. Then we call which expects a so it panics.
Unless someone gets to it before, but I can get a fix in by if not over the weekend. Though from what I understand about that code it shouldn't be TyKind::Error, it should be Infer/Tuple. interesting...
Potential fix in
A possible duplicate.
Fix in (in progress)
The third time's the charm. More future proof solution:
I was just about to open a new issue when I saw this and it looks like it has been fixed—but since I already typed it out and it might provide further info, here it is: <!-- 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. --or No ICE when: just the return value is omitted just the args are omitted both the return value and args are omitted is replaced with <!-- 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.

--: No ICE on <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I hit a similiar bug... As it is already known and fixed, I won't post a new bug report, but as I already have it, here is my data point: I don't have a minimal example, I just know that I got an error on the following git checkout: <!-- 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. --: The following command triggered the ICE: <details<summary<strongBacktrace</strong</summary<p</p</details
Change:
<del> use crate::spec::{base, CodeModel, Target, TargetOptions}; </del> <ins> use std::borrow::Cow; use crate::spec::{base, CodeModel, SplitDebuginfo, Target, TargetOptions}; </ins> pub fn target() -> Target { Target {

Discussion:
On riscv64gc linux, split-debuginfo ="unpacked" caused error: A dwo section may not contain relocations. For rust 1.64, this error occurs. For rust <=1.64, cargo didn't pass flag to rustc. For rust 1.64, a segmentation fault happens in rustc. For rust < 1.64, it builds fine I think the behavior of rust < 1.64 is correct. The following steps: caused the following failure: No response Related:
Transferred to rust-lang/rust, since this looks to be a compiler issue.
says that LLVM doesn't support this combination of flags. It's unclear to me whether it's impossible or just not implemented yet, but in the meantime, cargo should probably stop passing -C split-debuginfo to proc-macros? there's some mention of in the upstream issue, I'm not sure how that's related.
The report above doesn't mention proc-macros. It seems to happen for normal binaries. The following seems to fail for me: If split-debuginfo isn't supported on this target, then rustc should report that it isn't supported (Cargo already tests for this). I believe that is defined by the field in the target definition.
I'm getting the same issue with when cross compiling for , it seems to be all values except that causes issues.
Change:
<ins> // aux-build: foreign-generic-mismatch.rs extern crate foreign_generic_mismatch; fn main() { foreign_generic_mismatch::const_arg::<()>(); //~^ ERROR function takes 2 generic arguments but 1 generic argument was supplied foreign_generic_mismatch::lt_arg::<'static, 'static>(); //~^ ERROR function takes 1 lifetime argument but 2 lifetime arguments were supplied } </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. --cc still crashes after <!-- 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 --
Sigh, yeah, this is just the same bug but for lifetime params. I'll fix it, shouldn't be too hard. claim
Hey, , thanks for getting this fixed! Unfortunately, I seem to be running into the same issue (or a very similar one) using the latest nightly, and I've not been able to create a standalone reproducer: <details<summaryBacktrace</summary<p</p</detailsSorry if this is the wrong place to be reporting this ICE, but I wasn't sure whether to file a new issue or maybe get one of the resolved issues re-opened. Thank you!