jiebi/CodeConvo huggingface dataset:
Change:
self.opt_parent(def_id.into()) .is_some_and(|parent| matches!(self.def_kind(parent), DefKind::ForeignMod)) } <ins> pub fn hash_owner_nodes( self, node: OwnerNode<'_>, bodies: &SortedMap<ItemLocalId, &Body<'_>>, attrs: &SortedMap<ItemLocalId, &[rustc_ast::Attribute]>, ) -> (Option<Fingerprint>, Option<Fingerprint>) { if self.needs_crate_hash() { self.with_stable_hashing_context(|mut hcx| { let mut stable_hasher = StableHasher::new(); node.hash_stable(&mut hcx, &mut stable_hasher); // Bodies are stored out of line, so we need to pull them explicitly in the hash. bodies.hash_stable(&mut hcx, &mut stable_hasher); let h1 = stable_hasher.finish(); let mut stable_hasher = StableHasher::new(); attrs.hash_stable(&mut hcx, &mut stable_hasher); let h2 = stable_hasher.finish(); (Some(h1), Some(h2)) }) } else { (None, None) } } </ins> } pub fn provide(providers: &mut Providers) {

Discussion:
<!-- [31mICE[0m: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' 'thread 'rustc' panicked at 'called on a value'', 'thread 'rustc' panicked at 'called on a value'' File: --auto-reduced (treereduce-rust): original: Version information Command: &lt;!-- Include a backtrace in the code block by setting in your environment. E.g. . --&lt;details&lt;summary&lt;strongProgram output&lt;/strong&lt;/summary&lt;p&lt;/p&lt;/details&lt;!-- query stack: note: compiler flags: -Z incremental-verify-ich=yes -C incremental=[REDACTED] -C debuginfo=2 [associatedtypeforimpltraitintrait] creating the associated item corresponding to the opaque type [associatedtypesforimpltraitsinassociatedfn] creating associated items for opaque types returned by [associateditemdefids] collecting associated items or fields of [associateditems] collecting associated items of [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
This will probably make a simple crash in a lot of cases :3
cc
minimal repro:
Hmm, when writing I tried to trigger the case by enabling , but it didn't ICE. I'll check what is the difference with what cargo does.
Fixed in
A workaround to this issue should be to use or which should disable incremental compilation.
run on nightly rust also  but. if you use to switch stable version rust will be run will successful
There’s also an environment variable to control incremental compilation, so you could set CARGO_INCREMENTAL=0 to do that.
I think this error should be completely fixed, otherwise it will still fail to compile in the IDE environment and the automatic build environment of GitHub Action
Sure, we were just offering a workaround to unblock people temporarily. The fix is already present on master and should be available in tomorrow’s nightly.
Oh, this is great
Change:
/// /// [`Drop`]: ../ops/trait.Drop.html fn into_inner(self) -> Box<[u8]> { <del> unsafe { let result = ptr::read(&self.inner); mem::forget(self); result } </del> <ins> // Rationale: `mem::forget(self)` invalidates the previous call to `ptr::read(&self.inner)` // so we use `ManuallyDrop` to ensure `self` is not dropped. // Then we can return the box directly without invalidating it. // See https://github.com/rust-lang/rust/issues/62553. let this = mem::ManuallyDrop::new(self); unsafe { ptr::read(&this.inner) } </ins> } }

Discussion:
This simple code should not trigger any error, except a leak of course. But miri report an error before: First, I suspected a miri bug but look like the code of could be the problem, I don't really understand the code of the . Is this code correct and it's a miri bug or the code is incorrect ? as you write the code maybe you want be ping.
/cc
The code in question:
Should be ok for me but it's still trigger miri
On a first glance this looks like an issue I have seen before, where the problem is that is a normal function call. So the creates a raw pointer and reads from it, but then the original pointer gets used again, which invalidates the raw pointer. So this is basically the same as
What about:
That's basically a transmute, but with even fewer compiler-level checks. At that point I'd just recommend transmuting to .
Isn't transmuting to always valid?
There's in fact a safe method for it, called . ;) But my suggestion does not involve .
While using + comment seems like the better option in the interim, my long-term preference here would be to just remove the check that doesn't let you destructure -implementing types as discussed in
This leads to 's suggestion, which seems to trigger Miri nevertheless. This indeed solves the problem here, but I was wondering about the more general pattern (See ): what if, for instance, had a second non ZST field: needing to extract an unaliased pointer from a struct implementing is actually not that easy to do soundly, once it entirely is not doable; _ Another idea (again, considering that may contain a second field that prevents it from being transmuted into the return value directly):
would be more appropriate than as it more correctly documents what you're doing. Also both and use internally.
So we have 2 clean solutions that doesn't trigger miri what do we pick ?
Change:
<ins> error[E0507]: cannot move out of `*inbounds` which is behind a shared reference --> $DIR/issue-102389.rs:4:11 | LL |     array[*inbounds as usize] |           ^^^^^^^^^ move occurs because `*inbounds` has type `Enum`, which does not implement the `Copy` trait error: aborting due to previous error For more information about this error, try `rustc --explain E0507`. </ins>

Discussion:
noticed this 1.63→1.64 change in I tried this code: I expected to see this happen: because is non-, an error about moving out from behind a reference, like happened in 1.63 , this happened: it compiles fine in 1.64 in nightly is probably cased by Change enum-int casts to not go through MIR casts which is mentioned in It's unclear to me whether this is intentional under the banner of " behaviour", since there's no trait involved.
Prioritized as P-critical in meeting just now. This needs to be fixed by 1.65 at a minimum.
labels +T-compiler This needs work from T-compiler! :)
labels -I-lang-nominated Meeting consensus is that the current behavior is wrong and needs to be fixed.
Change:
let llvm_cmake_dir = out_dir.join("lib/cmake/llvm"); let res = LlvmResult { llvm_config: build_llvm_config, llvm_cmake_dir }; <ins> let smart_stamp_hash = generate_smart_stamp_hash( &builder.config.src.join("src/llvm-project"), &builder.in_tree_llvm_info.sha().unwrap_or_default(), ); </ins> let stamp = out_dir.join("llvm-finished-building"); <del> let stamp = HashStamp::new(stamp, builder.in_tree_llvm_info.sha()); </del> <ins> let stamp = HashStamp::new(stamp, Some(&smart_stamp_hash)); </ins> if stamp.is_done() { if stamp.hash.is_none() {

Discussion:
I tried this code: I expected to see this happen: bootstrap rebuilds LLVM, since it's changed. Instead, this happened: bootstrap does nothing. The problem is that we 're using a stamp file and assume that if the commit hasn't changed then none of the files have changed either: I am not sure why we do that? Are we assuming that CMake rebuilds too frequently? That seems like something we should fix upstream ... cc I think this would make your lives easier. HEAD is branched from .
hmm, looks related. I am not sure why that would be the correct behavior? If CFLAGS has changed we should rebuild; I would expect distros to make sure CFLAGS matches between invocations of bootstrap.
The stamp checking for the "normal" case, when not building from a source tarball, has been there since the initial commit of bootstrap:
Are you trying to address the git "dirty" case, or the non-git case, or both?
Both, but primarily the git case since that's how most people are developing I think.
Ok, I agree the git case is where folks may actually be making changes, and I still think it's ok not to automatically "notice" changes in the non-git case. LLVM is big enough that checking for dirty git may not be cheap though. On my Linux system with NVME, it takes ~0.5s after dropping page caches, and ~0.15s cached. On systems with slower disks, virus scanners, etc., it may be a lot worse.
Yeah, I don't think this is particularly important. The main issue with making changes to LLVM is , which prevents the change from being picked up even if you do commit it.
Change:
} } <ins> fn trait_item_scope_tag(item: &hir::TraitItem) -> &'static str { match item.node { hir::TraitItemKind::Method(..) => "method body", hir::TraitItemKind::Const(..) | hir::TraitItemKind::Type(..) => "associated item" } } fn impl_item_scope_tag(item: &hir::ImplItem) -> &'static str { match item.node { hir::ImplItemKind::Method(..) => "method body", hir::ImplItemKind::Const(..) | hir::ImplItemKind::Type(_) => "associated item" } } </ins> fn explain_span<'a, 'gcx, 'tcx>(tcx: TyCtxt<'a, 'gcx, 'tcx>, heading: &str, span: Span) -> (String, Option<Span>) {

Discussion:
Receiving info about MIR or some other intermediate form in a user error report. I tried this code which most likely has some lifetime issue that I am yet to resolve: I should have received information about the scope defined by some part of my code or if the issue is with auto-generated code then possibly no information about an internal scope. Instead, this happened: :
This seems to be more common than I first thought: Made a resulted in:
Issue exists in latest nightly as well.
Can confirm experiencing it. Smaller sample: Not an issue in current stable or beta, which reports rather than
Does this qualify as a regression?
Yes, though not the kind we'd do a point release for, IMO
should mark as such then :)
Here's another small one:
It took me a minute to figure out that this issue is about the error message & not the error. I've also been getting CallSiteScope and so on nonsense in my error output recently. This seems like a pretty serious regression in the usability of our error messages! My impression has been that this impacts just about every lifetime issue I've been getting recently, but I could be wrong. Could we get this fixed by next stable release? I disagree with that this isn't worth making a point release for (currently its only in nightly, so that's not an issue).
Nominated for consideration by the compiler team.
This appears to be in beta (testing on the playground). Super tiny repro: gives
Has nobody looked into this? I'll take a peek before the compiler meeting today. EDIT: Of course it was me who introduced this bug, or rather triggered sigh. EDIT2: Basically, after , any uses of are suspicious. I'll try to make a PR.
Fix is at , using reduction as the testcase for this issue.
triage: P-high We have a fix though =)
Change:
include ../../run-make-fulldeps/tools.mk <ins> # ignore-msvc </ins> # needs-rust-lld all: RUSTC_LOG=rustc_codegen_ssa::back::link=info $(RUSTC) -Z gcc-ld=lld -C link-args=-Wl,-v main.rs 2> $(TMPDIR)/output.txt

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: and this happened: I expected to see this happen: it would compile my crate. Instead, this happened: lld failed. <!-- 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. --: fixed the problem that I reported in There seems to be a new problem with an unknown linker name. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
Could you post the list of files in the directory in Rust distribution?
I found in the clang invocation:
It looks like maybe clang replaces and changes it from to when calling lld-wrapper?
I can't confirm whether that's the case right now, but if that's true then the fix would be as simple as adding the alternative to in lld-wrapper.
Apple ships its linker as . I couldn't find a file.
I believe the issue is with the usage of in the PR, see: You probably meant to use . Wait. is because of Windows? is the only one that does not play well with it. One solution is to normalise the string or before the match statement.
This is not happening only on osx. I can reproduce this. The path is correct and unchanged by clang, but it's indeed the call that trims too much on unixes because of the weird executable name with a dot. I'll fix it.
The problem still exists, but the error changed to on macos. Need more investigation..
Change:
"libstd/sync/spsc_queue.rs", # BSD "libstd/sync/mpmc_bounded_queue.rs", # BSD "libsync/mpsc_intrusive.rs", # BSD <ins> "test/bench/shootout-binarytrees.rs", # BSD </ins> "test/bench/shootout-fannkuch-redux.rs", # BSD "test/bench/shootout-meteor.rs", # BSD "test/bench/shootout-regex-dna.rs", # BSD

Discussion:
See I propose to change the license of Non trivial contributors: OK OK OK (MoCo employee) Contributors appearing in git blame that are trivial (trivial update due to language changes): OK (MoCo employee) OK OK (MoCo employee) OK OK OK OK OK OK (sent agreement to by email) Contributors with removed and trivial contributions are not considered. For the persons that are not in "OK" state, please respond to this issue saying: Then, I'll propose the corresponding PR. Thanks.
I agree to relicense any previous contributions to according to the term of the computer Language Benchmarks Game license (
We don't need statements from Graydon or Marijn as they both contributed as employees. On Jun 7, 2014 5:50 AM, "TeXitoi" wrote:
I agree to relicense any previous contributions to according to the term of the Computer Language Benchmarks Game license ()
Op updated. could you please respond?
Citing in a private email: can I consider the contribution of negligible? the same for renaming? If yes I can propose a PR for this and for
guh, I suppose so, though I'm disappointed that didn't cooperate.
My change is obviously trivial and I have zero copyright over anything to do with the shootout benchmarks, but if you must, then: I agree to relicense any previous contributions to according to the term of the Computer Language Benchmarks Game license ()
OP updated. Thanks. I'll wait some days to see if respond to my email.
I agree to relicense any previous contributions to according to the term of the Computer Language Benchmarks Game license ()
Change:
#[derive(Debug)] enum InnerAttributeParsePolicy<'a> { Permitted, <del> NotPermitted { reason: &'a str }, </del> <ins> NotPermitted { reason: &'a str, saw_doc_comment: bool, prev_attr_sp: Option<Span> }, </ins> } const DEFAULT_UNEXPECTED_INNER_ATTR_ERR_MSG: &str = "an inner attribute is not 

Discussion:
Given the following we currently emit We should emit at least the following We might also want to provide suggestions when it makes sense (like turning the attr into an outer attr).
Hey , I tried to solve this with a little help of on a rust meetup. I wasn't able to run because of the following message. But I started to add some code you can read here: is this going into the right direction?
thank you for taking a look at this! You should be able to run the tests with . Use to update the relevant files. The code you've written would generate the following output: Instead, we'd want this to be a single error. What you'd want to do is 1) get the span for the prior attribute from 2) expand to also hold an extra field and 3) change the following to be This lets you point at the prior span in the same error. The second part of this ticket is changing the linked code to no longer use , but rather synthesize a new span from the first 's span to the closing . You can use to do so. Finally, we change the above to be something like
Are you still working on this? I'm thinking of giving it a try.
Go on! I don’t have so much time atm so just go there step by step while learning rust. If you want so solve it - awesome
Change:
use rustc_middle::ty::subst::Subst; use rustc_middle::ty::{self, ConstKind, Instance, InstanceDef, ParamEnv, Ty, TyCtxt}; use rustc_session::config::OptLevel; <ins> use rustc_span::def_id::DefId; </ins> use rustc_span::{hygiene::ExpnKind, ExpnData, LocalExpnId, Span}; use rustc_target::spec::abi::Abi;

Discussion:
I tried this code with (, ; minimized and modified from 's ): I expected to see this happen: Successful compilation Instead, this happened: Compiler hangup <!-- 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. --: <details<summaryBacktrace</summary<pCaptured by a command in GDB:  </p</details
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![feature(global_allocator, alloc_system, allocator_api)] extern crate alloc_system; use std::collections::VecDeque; use alloc_system::System; #[global_allocator] static ALLOCATOR: System = System; fn main() { let mut deque = VecDeque::with_capacity(32); deque.push_front(0); deque.reserve(31); deque.push_back(0); } </ins>

Discussion:
I've been seeing lots of bad behavior trying to use VecDeque. I've boiled it down to a relatively simple example which shows some of the bad behavior I was seeing and additionally seg faults. This was with: rustc 1.20.0 ( 2017-08-27) binary: rustc commit-hash: commit-date: 2017-08-27 host: x86_64-apple-darwin release: 1.20.0 LLVM version: 4.0 and also rust 1.19 The output I expect to see is: The output I get is: Note that the fourth from the last byte should be D9. Work around seems to be to use a large VecDeqeue capacity. Here's the code:
Valgrind output with the allocator switched over to alloc_system:
Here is what I believe is a minimal reproduction: Valgrind:
It looks like this was introduced two years ago in Specifically, mixes up its "raw" capacity and the user-visible capacity. These differ by one, so reserve can end up in a situation where it calls into without the capacity having actually increased. The implementation of that method assumes this doesn't happen, and as a result messes up the head and tail pointers so that the next push writes off the end of the buffer. Making a fix right now.
This bug is referenced in :
Change:
<ins> // incremental #![crate_type = "lib"] trait Q { const ASSOC: usize; } impl<const N: u64> Q for [u8; N] { //~^ ERROR mismatched types const ASSOC: usize = 1; } pub fn test() -> [u8; <[u8; 13] as Q>::ASSOC] { todo!() } </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Regression in searched nightlies: from nightly-2023-03-10 to nightly-2023-03-18 regressed nightly: nightly-2023-03-12 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
We relate with during codegen when selecting an impl which now eagerly returns without constraining to anything wheras previously it would have been instantiated with . This then results in codegen returning an impl with in the substs from a query
output on beta/stable:
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
err.emit() } <ins> fn report_unterminated_block_comment(&self, start: BytePos, doc_style: Option<DocStyle>) { let msg = match doc_style { Some(_) => "unterminated block doc-comment", None => "unterminated block comment", }; let last_bpos = self.pos; let mut err = self.sess.span_diagnostic.struct_span_fatal_with_code( self.mk_sp(start, last_bpos), msg, error_code!(E0758), ); let mut nested_block_comment_open_idxs = vec![]; let mut last_nested_block_comment_idxs = None; let mut content_chars = self.str_from(start).char_indices().peekable(); while let Some((idx, current_char)) = content_chars.next() { match content_chars.peek() { Some((_, '*')) if current_char == '/' => { nested_block_comment_open_idxs.push(idx); } Some((_, '/')) if current_char == '*' => { last_nested_block_comment_idxs = nested_block_comment_open_idxs.pop().map(|open_idx| (open_idx, idx)); } _ => {} }; } if let Some((nested_open_idx, nested_close_idx)) = last_nested_block_comment_idxs { err.span_label(self.mk_sp(start, start + BytePos(2)), msg) .span_label( self.mk_sp( start + BytePos(nested_open_idx as u32), start + BytePos(nested_open_idx as u32 + 2), ), "...as last nested comment starts here, maybe you want to close this instead?", ) .span_label( self.mk_sp( start + BytePos(nested_close_idx as u32), start + BytePos(nested_close_idx as u32 + 2), ), "...and last nested comment terminates here.", ); } err.emit(); } </ins> // RFC 3101 introduced the idea of (reserved) prefixes. As of Rust 2021, // using a (unknown) prefix is an error. In earlier editions, however, they // only result in a (allowed by default) lint, and are treated as regular

Discussion:
Given: The compiler says: This initially confused me quite a bit because I couldn't figure out why Rust wasn't seeing block comment terminator. Eventually, I realized that the line changed from being a commented out line, to starting a nested block comment. Since block comments nest in Rust, I'm used to commenting out blocks without worrying about what's inside of them which made this behaviour surprising. I'm not sure how practical it is, but it would be cool if we could check for comments like in block comments to suggest them as the source of the problem. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim
Change:
let lo = self.span; let hi; <del> if self.check(&token::DotDot) { </del> <ins> if self.check(&token::DotDot) || self.token == token::DotDotDot { if self.token == token::DotDotDot { // Issue #46718 let mut err = self.struct_span_err(self.span, "expected field pattern, found `...`"); err.span_suggestion(self.span, "to omit remaining fields, use one fewer `.`", "..".to_owned()); err.emit(); } </ins> self.bump(); if self.token != token::CloseDelim(token::Brace) { let token_str = self.this_token_to_string();

Discussion:
Consider the following code: If you try to compile this, you get the following errors: See the bug? Its because I used when I should have used It would be nice if the compiler, in its ever friendly manner, suggested the latter to me.
I volunteer.