jiebi/CodeConvo huggingface dataset:
Change:
unsafe fn data_offset<T: ?Sized>(ptr: *const T) -> isize { // Align the unsized value to the end of the `ArcInner`. // Because it is `?Sized`, it will always be the last field in memory. <ins> // Note: This is a detail of the current implementation of the compiler, // and is not a guaranteed language detail. Do not rely on it outside of std. </ins> data_offset_align(align_of_val(&*ptr)) }

Discussion:
In the implementation of , we find: (And similarly in with .) Note the comment: Is this actually true, even for instantiations where happens to be ? Does the language guarantee that there exist no type such that the fields of would be re-ordered? Or do we need to add to and ? CC
If this were user-facing code it would be a clear case of "no that's not specified, don't assume that". However, I believe rustc does currently honor this assumption and libstd can of course rely on rustc implementation details. would know best. Note that because unsizing happens with "reorganizing" the struct, the struct with a sized T has to be laid out "as if unsized" from the start. For example, and and many other can all be casted to without touching the , the differences in layout between those are quite constrained (limited to different amounts of paddding to respect alignment, I think?). This reasoning wouldn't apply if there was a type that couldn't ever be involved in unsizing, but I don't think the compiler can ever realistically rule that out locally, and I'm rather certain that it doesn't today.
Ah that’s a good point. The constraint that layout cannot change while unsizing is probably enough indeed.
We should probably add a comment to that effect so "don't assume that" is clearer to everyone.
We should! See
FWIW these are nowadays so this got properly fixed at some point.
Change:
<ins> -include ../../run-make-fulldeps/tools.mk # Regression test for issue #85401 # Verify that we do not ICE when trying to access MIR for statics, # but emit an error when linking. OUTPUT_FILE := $(TMPDIR)/build-output all: $(RUSTC) --crate-type rlib --crate-name foo -Crelocation-model=pic --edition=2018 foo.rs -Zalways-encode-mir=yes --emit metadata -o $(TMPDIR)/libfoo.rmeta $(RUSTC) --crate-type rlib --crate-name bar -Crelocation-model=pic --edition=2018 bar.rs -o $(TMPDIR)/libbar.rlib --extern=foo=$(TMPDIR)/libfoo.rmeta $(RUSTC) --crate-type bin --crate-name baz -Crelocation-model=pic --edition=2018 baz.rs -o $(TMPDIR)/baz -L $(TMPDIR) --extern=bar=$(TMPDIR)/libbar.rlib > $(OUTPUT_FILE) 2>&1; [ $$? -eq 1 ] cat  $(OUTPUT_FILE) $(CGREP) 'crate `foo` required to be available in rlib format, but was not found in this form' < $(OUTPUT_FILE) # -v tests are fragile, hopefully this text won't change $(CGREP) -v "internal compiler error" < $(OUTPUT_FILE) </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. --I tried this code: I expected to see this happen: generate Instead, this happened: <!-- 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
This is strange, Miri uses but statics seem to work fine for us?
Does the test case I gave work for Miri? I notice that produces much larger rmeta files than would, which are in turn larger than 's rmetas (as expected). It would be nice to have an option to make lone produce the same output as , and I was hoping that it would just be a matter of stabilizing , but they don't seem to be equivalent. Ideally they'd produce the same output, but I'd be happy with functionally interchangable - which is what this issue is about. Overall, I'm finding it hard to work out what controls what goes into a file. I audited all the places where either or both of and/or are checked, and unifying them does not produce an output where and together produce the same as . I guess I haven't confirmed that MIR is the only difference between the two cases.
Yes: when I set up a 2-crate workspace matching your 2 files and then do , it works as expected.
PR adds so that generates equivalent rmetas to .
Change:
<ins> // Copyright 2018 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. // only-x86_64 // aux-build:using-target-feature-unstable.rs extern crate using_target_feature_unstable; fn main() { unsafe { using_target_feature_unstable::foo(); } } </ins>

Discussion:
Given this code: it compiles as: How odd!
Not technically a regression but this needs to be fixed before 1.27 hits stable, so tagging as a nightly regression

Given: and you'll see: But that's not right! Only the original crate should need this directive, and it indeed has such a directive.
Change:
} } <del> fn print_diagnostic(topic: &str, lvl: level, msg: &str) { let t = term::Terminal::new(io::stderr()); </del> <ins> fn print_maybe_colored(msg: &str, color: u8) { </ins> let stderr = io::stderr(); <del> if !topic.is_empty() { stderr.write_str(fmt!("%s ", topic)); } </del> <ins> let t = term::Terminal::new(stderr); </ins> match t { Ok(term) => { if stderr.get_type() == io::Screen { <del> term.fg(diagnosticcolor(lvl)); stderr.write_str(fmt!("%s: ", diagnosticstr(lvl))); </del> <ins> term.fg(color); stderr.write_str(msg); </ins> term.reset(); <del> stderr.write_str(fmt!("%sn", msg)); </del> } else { <del> stderr.write_str(fmt!("%s: %sn", diagnosticstr(lvl), msg)); </del> <ins> stderr.write_str(msg); </ins> } }, <del> _ => stderr.write_str(fmt!("%s: %sn", diagnosticstr(lvl), msg)) </del> <ins> _ => stderr.write_str(msg) </ins> } } <ins> fn print_diagnostic(topic: &str, lvl: level, msg: &str) { let stderr = io::stderr(); if !topic.is_empty() { stderr.write_str(fmt!("%s ", topic)); } print_maybe_colored(fmt!("%s: ", diagnosticstr(lvl)), diagnosticcolor(lvl)); stderr.write_str(fmt!("%sn", msg)); } </ins> pub fn collect(messages: @mut ~[~str]) -> @fn(Option<(@codemap::CodeMap, span)>, &str, level) { let f: @fn(Option<(@codemap::CodeMap, span)>, &str, level) =

Discussion:
'warning', 'note', and 'error' are colorized; I think it'd be nice to also colorize the underlining of the affected code, as clang does. clang makes it green, I believe.
+1 for doing whatever clang does re error reporting.
Change:
let ret_expr = if let Some(catch_node) = catch_scope { let target_id = Ok(self.lower_node_id(catch_node).hir_id); P(self.expr( <del> e.span, </del> <ins> try_span, </ins> hir::ExprKind::Break( hir::Destination { label: None,

Discussion:
Currently E277's message is confusing and seemingly ambiguous when it occurs on a try () expression (this may not be limited to E277, it's just the one I noticed). For example, in : The problem is that 's error type is while 's error type is . In this case the error isn't too confusing, but if the try is in a chained expression () and you're a noob it isn't clear why it wants implemented on . It doesn't necessarily even require a whole fix suggestion, all it would take is making the error only highlight the , as the issue is actually occuring when unwrapping the result. Thanks!
Change:
"=".to_string(), Applicability::MaybeIncorrect, ) <ins> .help("if you meant to overwrite, remove the `let` binding") </ins> .emit(); self.bump(); true

Discussion:
This code: gives the following error: It's not clear or even close to what the actual problem is. I think it should throw the E0067 error code. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<del> //! This checks the output of some `--print` options when //! output to a file (instead of stdout) </del> <ins> //! This checks the output of some `--print` options when output to a file (instead of stdout) // ignore-tidy-linelength //@ needs-llvm-components: aarch64 arm avr bpf csky hexagon loongarch m68k mips msp430 nvptx powerpc riscv sparc systemz webassembly x86 // FIXME(jieyouxu): there has to be a better way to do this, without the needs-llvm-components it // will fail on LLVM built without all of the components listed above. If adding a new target that // relies on a llvm component not listed above, it will need to be added to the required llvm // components above. </ins> use std::path::PathBuf;

Discussion:
Tests doing codegen for specific targets need directives. These are the tests that are currently missing the directives and failing if LLVM is built without various aarch64/arm/thumb components or wasm. [ ] testsrun-makeprint-target-list [ ] testsrun-makeprint-to-output [ ] testsrun-makeprint-cfg [ ] testsrun-maketarget-without-atomic-cas Originally posted by in
E.g. for this looks a bit awkward, maybe we can dump , where is shamelessly stolen from tidy: Between this directive and , it is not exactly very clear what's happening.

In noticed was failing for (and other experimental llvm components) on the CI builder with (specifically ) it was already noticed that seemed to fail for . Is this expected? Or what is the expected test behavior when is ran (on the CI builder)? Or is it expected that we should skip trying to run this check for the and other experimental llvm component targets? Update: this is also true for experimental llvm components , , and , not too sure what the correct behavior is. Currently these targets are skipped by 's check.
Is there any COMPILETESTNEEDSALLLLVMCOMPONENTS set by us for this jobs?. It seems like the same issue. I will check it later.
Well, I'm not familiar with rmake. However, the right logic should be like: If is not set and do not have the , then we could skip it. is set at , and it is only used at now.
Ah thank you, that sounds about right.
Change:
assert_eq!(span.hi().0, 6); assert!(sm.span_to_snippet(span).is_err()); } <ins> #[cfg(target_os = "linux")] #[test] fn read_binary_file_handles_lying_stat() { // read_binary_file tries to read the contents of a file into an Lrc<[u8]> while // never having two copies of the data in memory at once. This is an optimization // to support include_bytes! with large files. But since Rust allocators are // sensitive to alignment, our implementation can't be bootstrapped off calling // std::fs::read. So we test that we have the same behavior even on files where // fs::metadata lies. // stat always says that /proc/self/cmdline is length 0, but it isn't. let cmdline = Path::new("/proc/self/cmdline"); let len = std::fs::metadata(cmdline).unwrap().len() as usize; let real = std::fs::read(cmdline).unwrap(); assert!(len < real.len()); let bin = RealFileLoader.read_binary_file(cmdline).unwrap(); assert_eq!(&real[..], &bin[..]); // stat always says that /sys/devices/system/cpu/kernel_max is the size of a block. let kernel_max = Path::new("/sys/devices/system/cpu/kernel_max"); let len = std::fs::metadata(kernel_max).unwrap().len() as usize; let real = std::fs::read(kernel_max).unwrap(); assert!(len > real.len()); let bin = RealFileLoader.read_binary_file(kernel_max).unwrap(); assert_eq!(&real[..], &bin[..]); } </ins>

Discussion:
In this diff is subtly broken: because it trusts that the size of the file returned by is trustworthy, and it does not need to be. The correct implementation is to call until EOF is reached. This can be observed by trying to (just be sure to use the resultant ).
WG-prioritization assigning priority (). label -I-prioritize +P-high
Change:
use anyhow::{Context, Result}; <del> use clap::{self, Parser}; </del> <ins> use clap::Parser; </ins> #[derive(Parser)] struct CommandLine {

Discussion:
Right now when doing a local , we first compress the artifacts with max compression ratio, just to immediately unpack them again when installing them to disk. Making the compression level less aggressive or skipping it altogether can probably save 5-10 minutes on an x.py install. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc You probably want to use the gzip'd artifacts which are less intensely compressed.
tbh it seems strange that we're compressing these at all - why not put them into an uncompressed .tar archive when using ?
or even better, copy them directly from the build directory to the install directory without going through a .tar archive first.
claim
Skipping the compressions and archiving in favor of directly copying the artifacts seems like a reasonable solution for . But it requires significant changes to how we currently handle . I'm planning to do a comprehensive review on bootstrapping from all angles(including T-bootstrap issues) and make a roadmap for future development. To avoid conflicts(e.g, if we have improvement ideas on dist/install modules, implementing this might increase the technical debt which will require more effort from the team), I will postpone this task for now and re-prioritize it once we have organized the plans.
Change:
[[package]] name = "libgit2-sys" <del> version = "0.9.0" </del> <ins> version = "0.9.1" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "8c2078aec6f4b16d1b89f6a72e4f6eb1e75ffa85312023291e89c6d3087bc8fb" </del> <ins> checksum = "a30f8637eb59616ee3b8a00f6adff781ee4ddd8343a615b8238de756060cc1b3" </ins> dependencies = [ "cc", "libc",

Discussion:
Do we have plan to get rid of this restriction recently? A newer version of cc-rs is needed for VxWorks
can't currently be updated due to a build problem with riscv. More info at I think the issue is that rustbuild uses cc to discover cc toolchains, and gained riscv support, and so now it thinks it should use a gcc toolchain that doesn't exist. The detection is in and Alex mentioned just setting a env var in the riscv container might be enough. It's been on my todo list for a while, but I haven't had a chance to look at it. I can maybe try to look at it this weekend.
Thanks for working on this issue. Enjoy your weekend, it is not that urgent.
Change:
fn struct_span_err<S: Into<MultiSpan>>(&self, sp: S, m: &str) -> DiagnosticBuilder<'a> { self.sess.span_diagnostic.struct_span_err(sp, m) } <ins> fn struct_span_warn<S: Into<MultiSpan>>(&self, sp: S, m: &str) -> DiagnosticBuilder<'a> { self.sess.span_diagnostic.struct_span_warn(sp, m) } </ins> crate fn span_bug<S: Into<MultiSpan>>(&self, sp: S, m: &str) -> ! { self.sess.span_diagnostic.span_bug(sp, m) }

Discussion:
from a crater run: crate affected: interact (0.3.3), named-tuple (0.1.2), photonix (0.1.1), serdetuple (0.2.2), susy-codec (3.1.0), thrift (0.12.0), zeroize (0.6.0) authors: logs: https://crater- https://crater- https://crater- https://crater- https://crater- https://crater-, https://crater- probable duplicate of
cc
thrift and zeroize are the regressions that are most notable here; the others don't have notable reverse dependencies.
Change:
incremental = true # Make the compiler and standard library faster to build, at the expense of a ~20% runtime slowdown. lto = "off" <del> # Build the llvm-bitcode-linker as it is required for running nvptx tests llvm-bitcode-linker = true </del> [llvm] # Will download LLVM from CI if available on your platform.

Discussion:
With the latest , when I run a run-make test twice in a row, bootstrap rebuilds and : This has to be a recent regression, it didn't happen until ~yesterday. Confirmed with that it also happens for them.
Sounds suspiciously similar to
Yeah this is again caused by being enabled :laughing: Do you think that there's some more general solution to the rebuild problem?
Thanks for notifying me about this. I am travelling this weekend, meaning i might not have a chance to thoroughly investigate before Monday. (But I will at the latest be able to look on Monday). The last time it was due to dependency on the same crates with different rustflags. One from llbc-linker and one from some other tool (rustdoc?). The two different invocations maps to the same cache entry but is invalid between each other and thus triggers a rebuild. The solution last time was to mimic the rustflags being used other places in llbc-linker. That might be a good short term solution now as well. I don't know about the long term solution but it seems like either caching multiple versions of a crate or unifying the rustflag somewhere might be alternatives?
Of course, there's no rush, I just wanted to let you know, given that you already have some experience in debugging this :laughing: This seems rather brittle though, as you mention. I wonder what's so unique about this tool that it causes these rebuilds so often. You mentioned that we cannot share flags between all Step invocations. But maybe it would make sense to better share flags between at least this tool and other steps, rather than hardcoding selected flags? (as was done last time with the parallel compiler).
Actually, I wonder if we really need to enable this linker by default in all four bootstrap profiles.
Sure, seems fine to me. I didn't expect it to be a problem this frequently.
posted instead to disable this flag by default, I don't think it should be enabled for most contributors.
Change:
<ins> //@ run-pass //@ edition: 2024 //@ compile-flags: -Zunstable-options #![allow(incomplete_features)] #![feature(ref_pat_eat_one_layer_2024)] struct Foo; //~^ WARN struct `Foo` is never constructed fn main() { || { //~^ WARN unused closure that must be used if let Some(Some(&mut x)) = &mut Some(&mut Some(0)) { let _: u32 = x; } }; } </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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
rustc repro:
This ^ bisects to cc
This likely exposed a preexisting bug in cc previously was silently bailing when it couldn't deref a type it expected to be able to deref.
is most likely going to be removed, but this also reproduces with edition 2024 and : claim
Change:
<del> error: this code is interpreted as a block expression, not an array </del> <ins> error: this is a block expression, not an array </ins> --> $DIR/issue-87830-try-brackets-for-arrays.rs:3:22 | LL |   const FOO: [u8; 3] = { |  ______________________^ <ins> LL | | </ins> LL | |     1, 2, 3 LL | | }; | |_^ | <del> = note: to define an array, one would use square brackets instead of curly braces help: try using [] instead of {} </del> <ins> help: to make an array, use square brackets instead of curly braces </ins> | LL ~ const FOO: [u8; 3] = [ <ins> LL | </ins> LL |     1, 2, 3 LL ~ ]; | <del> error: this code is interpreted as a block expression, not an array --> $DIR/issue-87830-try-brackets-for-arrays.rs:7:24 </del> <ins> error: this is a block expression, not an array --> $DIR/issue-87830-try-brackets-for-arrays.rs:8:24 </ins> | LL | const BAR: [&str; 3] = {"one", "two", "three"}; |                        ^^^^^^^^^^^^^^^^^^^^^^^ | <del> = note: to define an array, one would use square brackets instead of curly braces help: try using [] instead of {} </del> <ins> help: to make an array, use square brackets instead of curly braces </ins> | LL | const BAR: [&str; 3] = ["one", "two", "three"]; |                        ~                     ~ <del> error: this code is interpreted as a block expression, not an array --> $DIR/issue-87830-try-brackets-for-arrays.rs:11:5 </del> <ins> error: this is a block expression, not an array --> $DIR/issue-87830-try-brackets-for-arrays.rs:12:5 </ins> | LL |     {1, 2, 3}; |     ^^^^^^^^^ | <del> = note: to define an array, one would use square brackets instead of curly braces help: try using [] instead of {} </del> <ins> help: to make an array, use square brackets instead of curly braces </ins> | LL |     [1, 2, 3]; |     ~       ~ error: expected one of `.`, `;`, `?`, `}`, or an operator, found `,` <del> --> $DIR/issue-87830-try-brackets-for-arrays.rs:16:6 </del> <ins> --> $DIR/issue-87830-try-brackets-for-arrays.rs:17:6 </ins> | LL |     1, 2, 3 |      ^ expected one of `.`, `;`, `?`, `}`, or an operator

Discussion:
, we should provide a structured suggestion as we already do when . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
seems easy enough, claim
Change:
fn drop(&mut self) { unsafe { match &self.flavor { <del> ReceiverFlavor::Array(chan) => chan.release(|c| c.disconnect()), </del> <ins> ReceiverFlavor::Array(chan) => chan.release(|c| c.disconnect_receivers()), </ins> ReceiverFlavor::List(chan) => chan.release(|c| c.disconnect_receivers()), ReceiverFlavor::Zero(chan) => chan.release(|c| c.disconnect()), }

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. --I tried this code: I expected to see this happen: I expected to see the struct in the Sender buffer get dropped after the Receiver is dropped during the unwind of the panicking thread. Instead, this happened: The data in the Sender buffer is not dropped until the whole process ends. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.66.1 <!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. --</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 --
bisection seems to point to cc searched nightlies: from nightly-2022-11-01 to nightly-2023-02-01 regressed nightly: nightly-2022-11-14 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:
In crossbeam, the unbounded channel does this (), but the bounded channel does not. There is no particular intent, it just hasn't been implemented. cc
Change:
<ins> // Regression test for #66270, fixed by #66246 struct Bug { incorrect_field: 0, //~^ ERROR expected type } struct Empty {} fn main() { let Bug { any_field: Empty {}, } = Bug {}; } </ins>

Discussion:
This code (): results in an ICE:
Isn't that a close cousin of
Not really, this is an associated function rather than an inner function.
I'm investigating this. Still repros on . With : <details<summaryBacktrace </summary</details
After investigating, the current ICE is caused by the () inside of not being able to locate the generic parameter it is trying to substitute for. The code at fault is: Which should try and find based on the (), but the current code only handles the situation like .
No longer ICEs, I believe down to Looking at the backtrace on nightly-2019-12-05 this seems related to and also
This no longer ICEs OR errors, at least for me. What backtrace do you mean? AFAICT this can be closed.
Whoops, wrote the wrong date down. I meant the nightly when it did ICE, it was 2019-12-01 or thereabouts. Yeah it can be closed once there's a regression test