jiebi/CodeConvo huggingface dataset:
Change:
} fn visit_expr(&mut self, expr: &'tcx Expr) { <ins> let scope = self.region_scope_tree.temporary_scope(expr.hir_id.local_id); </ins> match &expr.kind { ExprKind::Call(callee, args) => match &callee.kind { ExprKind::Path(qpath) => {

Discussion:
I have some code which asynchronously computes an integer, and selects an item from a static slice in the same expression. This used to work (it does on stable), but after a nightly update the compiler ICEs when computing generator layout. The bug stops reproducing if I change the static to a local variable, or extract the index into a separate variable. rustc 1.41.0-nightly ( 2019-11-23) binary: rustc commit-hash: commit-date: 2019-11-23 host: x86_64-unknown-linux-gnu release: 1.41.0-nightly LLVM version: 9.0
De-nominating from compiler team as we have a fix pending.
triage: P-high.
Change:
i += 1; } <del> while i < j && lines[i].trim().is_empty() { i += 1; } </del> // like the first, a last line of all stars should be omitted if j > i && !lines[j - 1].is_empty() && lines[j - 1].chars().all(|c| c == '*') { j -= 1; } <del> while j > i && lines[j - 1].trim().is_empty() { j -= 1; } </del> if i != 0 || j != lines.len() { Some((i, j)) } else { None } }

Discussion:
See the test in . This code: renders as: rather than the expected: Meanwhile, changing some s to s and vice versa causes it to render as expected. cc
This is the expected behaviour actually: it converts the into a directly. So if you don't put empty doc comments between, it's as expected.
But why are the newlines in the stripped?
Oh, I didn't see that. I think it's because we use to remove whistespaces which also removes backlines. We should instead merge all doc comments before doing anything.
Change:
type __ = isize; //~ ERROR type `__` should have a camel case name such as `CamelCase` <ins> struct X86_64; struct X86__64; //~ ERROR type `X86__64` should have a camel case name such as `X86_64` struct Abc_123; //~ ERROR type `Abc_123` should have a camel case name such as `Abc123` struct A1_b2_c3; //~ ERROR type `A1_b2_c3` should have a camel case name such as `A1B2C3` </ins> fn main() { }

Discussion:
Specifically, there are snakecase names that cannot be converted into CamelCase (as interpreted by this lint) without losing semantics: anything that contains two numbers with a separator. E.g does not have a CamelCase equivalent that's accepted by the lint but is not confusable with the conversion result of . Originally discovered in

I feel like the warning fires wrongly on this variant name in particular.
the warning fires whenever the name contains a ` if the characters directly before and after are digits?
Adding an exception for digits only will lead to to an issue later about some other non-letter case. What should be done instead, IMO, is check that the character before and after are letters and only warn then. /me shrugs. Very bikeshedy thing to discuss.
I understand wanting this to just work, but it's getting uncomfortably clever. Requiring a suppression here isn't so bad. Is this a case that comes up other than for "X86_64"?
Change:
""" <ins> from __future__ import print_function </ins> import sys import os.path import re

Discussion:
When a doc test fails, the console output looks like this: A traceback should only be shown if there was an error in the python script itself - in this case it should only show the matches error, something like this:
cc me. I'm surely willing to fix that as soon as I get enough spare time.
did you ever get a chance to look at this? (Do you know if the situation has changed?)
No, also I'm not aware of any update. Looks like that I've forgotten this at that time (as flt2dec was being matured); I have virtually no energy to contribute nowadays, so I probably cannot work on this right now.
Change:
<ins> // Copyright 2014 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. use std::mem::size_of; #[cfg(target_word_size = "32")] pub fn main() { assert_eq!(size_of::<[u8, ..(1 << 31) - 1]>(), (1 << 31) - 1); } #[cfg(target_word_size = "64")] pub fn main() { assert_eq!(size_of::<[u8, ..(1 << 47) - 1]>(), (1 << 47) - 1); } </ins>

Discussion:
LLVM does not support objects larger than bytes, because it represents sizes as counts of bits. Currently, to be safe, I'm blocking compile-time objects bigger than 2 GiB (in case LLVM uses an int count of bytes somewhere). It would be nice to find out how much can we increase this, especially on 64-bit targets.
bounds object size by 2 GiB on 32-bit architectures and 128 TiB () on 64-bit architectures.
Change:
non_exhaustive_omitted_patterns_lint, non_lifetime_binders, non_modrs_mods, <ins> none, </ins> nontemporal_store, noop_method_borrow, noop_method_clone,

Discussion:
Before , this gave an error: But after , that no longer gives an error. Ideally it shouldn't give an error in any case, but that's . Inlining/flattening format_args shouldn't change what compiles and what doesn't compile, so, for now, this still shouldn't compile.
Luckily the fix is easy. We just need to make sure that any with arguments still results in an expansion that involves borrowing a temporary.
Fix here:
Change:
// In practice this means that enums with `count > 1` are unlikely to claim niche zero, since they have to fit perfectly. // If niche zero is already reserved, the selection of bounds are of little interest. let move_start = |v: WrappingRange| { <del> let start = v.start.wrapping_sub(1) & max_value; </del> <ins> let start = v.start.wrapping_sub(count) & max_value; </ins> Some((start, Scalar { value, valid_range: v.with_start(start) })) }; let move_end = |v: WrappingRange| {

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --This code: () Panics with the message from inside futures-rs. The code driving this particular object is also in futures-rs , but this code couldn't possibly result in the panic that we see. That would require the Join future to get polled after it was completed, but that future is only ed, so this should never happen. This is a regression from stable to beta, bisected to PR . It still exists in nightly. <details<summaryBacktrace</summary<p</p</details modify labels: +regression-from-stable-to-beta -regression-untriaged <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Note that this regression is in the newly-promoted-to-beta 1.57, not 1.56 which is being released as stable this week.
Minimized:
claim
label: -A-async-await
Assigning as and removing .
(Posted in the fix PR as well for redundancy) For the record, while I may have seen I do not recall ever reviewing the change it links to (), which is where the bug was introduced (I was tipped off by the closures which did not exist in the version of that PR I reviewed).
the fix still needs a backport
This was backported in
Change:
<ins> // compile-flags: -Zunpretty=hir // check-pass #![feature(let_else)] #[prelude_import] use ::std::prelude::rust_2015::*; #[macro_use] extern crate std; fn foo(x: Option<u32>) { let Some(_) = x else { { ::std::rt::begin_panic("explicit panic") } }; } fn main() { } </ins>

Discussion:
Link to : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
searched nightlies: from nightly-2022-01-01 to nightly-2022-08-08 regressed nightly: nightly-2022-07-14 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: aarch64-apple-darwin Reproduce with: </details
It was probably regressed by , cc
label F-let-else
Change:
<del> Subproject commit 9b64ca5b7e1e3583978f9ac8af6d93b220a13d90 </del> <ins> Subproject commit f2b0c67661f19bb2564225d47aca424ad0449791 </ins>

Discussion:
The libc crate cron job has started failing to build on master for the target . To reproduce: errors with libcore failing to build for the target is bad - that it prevents to build the libc crate for the target is a sideeffect of that.
I wasn't able to reproduce this based on your instructions. Though for me there is no attempt to even build core, it just builds libc.
Weird. The first thing does is build a sysroot for the target, and the first step of doing that is building .
See the exact build failure in libc's CI which mentions the exact same invocation and how the first thing does is building libcore: https://travis-
I suspect that it doesn't build libcore because it's already distributed by rustup (and removing the rustup target makes compilation fail with libcore not found). Maybe something needs to be done to force building of libcore even for a non-custom target?
I don't really follow. and ignore anything distributed by rustup, except for the component, which include libcore sources, and as can be seen in the logs, the first thing they do is compiling the crate, which fails with an LLVM error since the LLVM upgrade.
AFAIK, we do not ship a rust-std component for this particular target.
has a rust-std component that contains just libcore (it's the only target we ship that works on Cortex-M0 chips, so it's quite important for embedded)
can you try to bisect the regression -- ideally to a specific PR? The tool may be of use! I'm marking this as P-high so that we check in on it but it seems like it's not yet clear whether this is a compiler bug exactly or what.
I think it would be helpful if somebody else can reproduce this issue first. Following the instructions that I posted in the OP, I can reproduce this both on a x8664-unknown-linux-gnu and a x8664-apple-darwin host, with the current nightly (rustc 1.38.0-nightly ( 2019-07-24)). which host are you on ?
PR wise we started seeing this right after was merged. I'm afraid that on my home laptop compiling rustc twice to test will take me... days.
I also cannot reproduce on x86_64-unknown-linux-gnu using the instructions above.
I was able to reproduce after doing a .

I'm not sure why that works while doesn't. Now I get the LLVM error.
Ah, indeed! makes the error appear.
So I do indeed have nightly as my default Rust toolchain, and on libc's CI this is the case as well for that build job. I'll report this to xargo upstream.
There's a couple of places that can throw this error, the one we hit is The symbol in question is , a jump-table label.
Finally managed to get a reproducer (turns out this only crashes llc at ):
I've opened an LLVM bug at
FYI rust-lang/stdarch game boy advance build job is affected by this as well.
Fixed upstream in and backported to LLVM 9 in LLVM submodule update pending in .
Change:
} } <ins> #[stable(feature = "mpsc_debug", since = "1.7.0")] impl<T> fmt::Debug for Receiver<T> { fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { write!(f, "Receiver {{ .. }}") } } </ins> #[stable(feature = "rust1", since = "1.0.0")] impl<T> fmt::Debug for SendError<T> { fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {

Discussion:
All public types should implement Debug. Per conversation on #rust-internals, there might be some useful information that could be printed for these types -- but even just "Sender { .. }" etc. would be a start.
Was this
probably. It has been suggested that way more useful info could actually be printed instead of the opaque placeholders -- but that would be more of a wishlist item than a bug... The patch is sufficient to fix the actual problem I was running into: not being able to #[derive(Debug)] on any structure containing mpsc Senders/Receivers.
Ok, closing.
Change:
// modifications, including adding/removing typically non-semantic // tokens such as extra braces and commas, don't happen. if let Some(tokens) = tokens { <ins> if GOOD_TOKEN_CACHE.with(|cache| cache.borrow().contains(&source)) { return tokens; } </ins> // Compare with a non-relaxed delim match to start. if tokenstream_probably_equal_for_proc_macro(&tokens, &reparsed_tokens, sess, false) { <ins> GOOD_TOKEN_CACHE.with(|cache| cache.borrow_mut().insert(source.clone())); </ins> return tokens; }

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --We have a library that compiles fine on 1.47.0 but after uggrading to 1.48.0 the compilation hangs. This code-snippet above is reduced from the original code as much as I can. I'm having problems understanding exactly where the problem is coming from and any further modifications to reduce it haven't worked. It uses the "paste" crate, and I've tried a few different versions including the latest one but it doesn't make a difference . I've been building it with at 1.47.0 and 1.48.0 to reproduce the issue which I got just by running doesn't work on works on </p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --
Some quick notes as I find them: This reproduces on just a cargo check, so has nothing to do with codegen (unsurprising) Compilation time scales by a little more than 2x for each additional number (going from 0 to 20 took 11 seconds, 21 took 26, 22 took 1 min 5) Given that I don't think this is a hard hang per se, just a really really long running compilation Definitely something in macro expansion, compiling the post- code is instant Reproduces on current nightly. -Zself-profile shows all the time is spent in . Unfortunately I don't have a debug build of rustc handy, but I imagine slapping a profiler on one should make the issue fairly obvious. I'd recommend cutting the provided example down from 64 to 20 though.

searched nightlies: from nightly-2020-08-24 to nightly-2020-10-03 regressed nightly: nightly-2020-10-02 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsLooks like
If it helps, this crate was exploring some ideas related to the crate
Assigning and removing as in the prioritization working group.
This is caused by some of the extra logic I in to ensure that we don't throw out the captured unnecessarily. I'm looking into improving the performance. In the longer term, this will be solved by getting rid of the pretty-print/retokenize hack entirely.
Change:
features: "+m,+a,+f,+d,+c".into(), llvm_abiname: "ilp32d".into(), max_atomic_width: Some(32), <ins> supported_split_debuginfo: Cow::Borrowed(&[SplitDebuginfo::Off]), </ins> ..base::linux_gnu::opts() }, }

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:
let targets: HashSet<_> = match build.config.cmd { // We don't need to check cross targets for these commands. crate::Subcommand::Clean { .. } <del> | crate::Subcommand::Check { .. } </del> | crate::Subcommand::Suggest { .. } | crate::Subcommand::Format { .. } | crate::Subcommand::Setup { .. } => {

Discussion:
Some time over the last days, this started happening: The third invocation should finish immediately, but instead it rebuilds everything. So what is usually a 1s edit-test cycle now takes a full minute. Cc
I wonder if has anything to do with this.
Yeah that sounds likely. Configuring the linker sets some env vars and when those differ between check and test builds, everything gets rebuilt.
Should we revert that PR then? Or is there some other short-term fix? This is a significant hurdle for rustc development right now.
I suppose that we could for now just skip the command from I tried the three commands that you have posted, and the last command did not rebuild anything (or rather, everything was fresh). What code should I modify between running these commands to reproduce the behavior that the third command rebuilds a lot of stuff?
Nevermind, I reproduced it. And the fix with removing check from configuring the linker works. I'll send a PR.
I think excluding is quite good short-term fix.
Change:
} _ if field.is_sized() => return simple(), ty::Slice(..) | ty::Str | ty::Foreign(..) => return simple(), <del> ty::Adt(def, _) => { if def.repr().packed() { // FIXME(eddyb) generalize the adjustment when we // start supporting packing to larger alignments. assert_eq!(self.layout.align.abi.bytes(), 1); return simple(); } } </del> _ => {} }

Discussion:
This code panics, but it should not: The panic disappears when the is inlined (because then we hit a different code path in ). What happens here is a bug in the logic that computes the offset of : since it is an unsized field, the offset is computed dynamically, by taking the statically known offset and then rounding it up to the dynamic alignment of the field. However, since the struct is packed, we need to cap the dynamic alignment of the field to the packing of the surrounding struct -- which we currently do not do. This is just yet another case where the non-compositional nature of is causing issues...
A slight variant of this code ICEs: It hits which, it seems, was never updated when support for was implemented.
WG-prioritization assigning priority (). label -I-prioritize +P-medium EDIT: lowered priority after discussion on Zulip
Change:
#[stable(feature = "rust1", since = "1.0.0")] #[rustc_promotable] #[rustc_const_stable(feature = "const_ptr_null", since = "1.24.0")] <ins> #[rustc_diagnostic_item = "ptr_null"] </ins> pub const fn null<T>() -> *const T { 0 as *const T }

Discussion:
I propose we add a lint that detects code like Some people seem to think that this is okay in contexts like or , but that is not the case -- on a NULL pointer is UB even as a place expression. To implement this, you can use the lint as a template: should check for  expressions with a operator, and then check the operand to be either a cast of to a pointer type, or a call to one of the methods. To detect the methods, make them "diagnostic items"; the lint does that e.g. for so it can again serve as a template here. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Ah, turns out clippy already has a lint for this: . So maybe we should just move that to rustc? Cc
claim
awesome. :) Let me know if you need any help.
Thanks :)
Did you mean something slightly different with your "okay in contexts like" examples, perhaps? Neither of those two actually compile as written, since they're just attempts to deference something that isn't even a pointer. You get: in both cases.
oops I screwed up the casts, should be fixed now.
Yeah, happy to have Clippy lints upstreamed to rust, let us know when it's done so we can deprecate it on our end
for detecting a call like you said to use . However I do not know what to use for the symbol argument. There is that defines symbol but nothing looks like creating a null ptr. Should I add one what should it look like ?
You first need to add the diagnostic item attribute to the relevant function inside , like so: This name must be globally unique, e.g. and . Then you add those names to the list in (please keep it alphabetically sorted), and then you can use them for .
Change:
// substitutions. use crate::check::FnCtxt; use hir::def_id::LocalDefId; use rustc_data_structures::fx::FxHashMap; use rustc_errors::ErrorGuaranteed;

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
Minimized a bit more:
It started ICE-ing in 1.41.0:
This compiles successfully without the bound. It also compiles if you change the bound to constrain the associated type:
I bisected it to be between and : I've tried to bisect between these commits, but I'm getting a compilation error in llvm.
It'll be , which changed the coherence rules to allow . The impl in this code is intentionally allowed under the new rules and should be fine, so it didn't really regress in that PR so much as it was newly permitted but likely surfaced a pre-existing bug. I tried to replicate this issue with a local trait but compiles successfully, so this does seem to involve the built-in trait and operator (the error message complains about the MIR statement which is a built-in index).
Further reduced to: , but not on 1.24.0 I agree with assessment:
So it could be considered a stable-to-stable regression? I don't how or who could add this label.
Yeah, I guess we could modify labels +regression-from-stable-to-stable although it's a regression from a very old stable
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium