jiebi/CodeConvo huggingface dataset:
Change:
<ins> // The error message here still is pretty confusing. fn main() { let primes = Vec::new(); primes.contains(3); //~^ ERROR mismatched types } </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 --
mcve Crashes on nightly and , stable 167:
claim
searched nightlies: from nightly-2023-01-01 to nightly-2023-03-02 regressed nightly: nightly-2023-01-07 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details cc
Change:
let rlink_data = fs::read(file).unwrap_or_else(|err| { sess.fatal(&format!("failed to read rlink file: {}", err)); }); <del> let mut decoder = rustc_serialize::opaque::Decoder::new(&rlink_data, 0); let codegen_results: CodegenResults = rustc_serialize::Decodable::decode(&mut decoder); </del> <ins> let codegen_results = match CodegenResults::deserialize_rlink(rlink_data) { Ok(codegen) => codegen, Err(error) => { sess.fatal(&format!("Could not deserialize .rlink file: {error}")); } }; </ins> let result = compiler.codegen_backend().link(sess, codegen_results, &outputs); abort_on_err(result, sess); } else {

Discussion:
This allows giving a better error when attempting to use the original source file with -Zlink-only rather than crashing and allows rejecting rlink files produced by a different rustc version.
To clarify: here's what I thought you had to do: But that gives an inscrutable error like this: The correct way to invoke is actually this If the file has a header, the code that reads it can check for that header. If it's not present (e.g. because somebody passed a file by mistake) then it can give a nice error message like "this doesn't look like a .rlink file".
I tried to look at this. is a struct that is serialized to files using the machinery. I tried to create a wrapper struct that would serialize and deserialize a header to provide nicer messages, but it's not really easy to provide a custom message if decoding of the header fails currently, since you removed the s from methods :sweat_smile: I see several solutions to this: 1) Catch panic that could be caused by invalid decoding of the header and provide a nicer message in that case (seems dubious). 2) Implement serialization and deserialization of the header using manual byte writes/reads, going around the traits. 3) Return sto methods (probably not worth it because of this). What do you suggest, solution 2)?
The crate metadata encodes and decodes the header separately from the contents. For crate metadata the header is of the form "rust" + 32bit be version number (currently 5 I believe) + 32bit offset of the crate root + rustc version string. During decoding the header is checked for "rust", the right version number and then the right rustc version. Only after that is a created to decode the contents. The rlink header could work the same way except omitting the offset of the crate root and using say "rsld" (rust ld) or "rustlink" as start instead of "rust" like the crate metadata.
Thanks for the hint. I checked rmeta decoding and it basically decodes the magic header byte slice with , which should be easy, but then it uses for decoding the rustc version, which will panic if the version is missing. So with this approach we could have a nice error if header magic is missing, nice error if rust version is wrong, but weird error if rust version if missing.

That is basically the same that we get for parsing, so I suppose that's ok?
Yeah, the header magic is supposed to be changed every time the rustc version needs to be decoded in a different way. IMO it is ok.
Change:
borrow_after_mut_borrow_nested(); mut_borrow_after_borrow_nested(); } <ins> fn use_mut<T>(_: &mut T) { } fn use_imm<T>(_: &T) { } </ins>

Discussion:
The revision system lets encode different sets of errors for different invocations of the compiler. and normally attempts to catch cases where you left out expected error messages by saying "if you have any annotation in your file, then the set of such annotations needs to match the same set of errors that are actually emitted. However, if you combine these features, then for each revision (call it ) in the revisions list, at least one of your errors currently need to be written with the revision system in mind, e.g. If none of the error annotations include a revision (i.e., if they are all ), then thinks that the test has no error annotations, and thus treats it as a case where the compiler's error output is blindly accepted. That seems bad.
cc
This is surely no longer the case, because and annotations are now mandatory?
With annotation for warnings and errors being mandatory , and additionally annotations applying to all revisions , this should be non-issue.
Change:
<ins> error[E0004]: non-exhaustive patterns: `Opcode(0_u8)` and `Opcode(2_u8..=u8::MAX)` not covered --> $DIR/issue-88331.rs:11:20 | LL | pub struct Opcode(pub u8); | -------------------------- `Opcode` defined here ... LL |     move |i| match msg_type { |                    ^^^^^^^^ patterns `Opcode(0_u8)` and `Opcode(2_u8..=u8::MAX)` not covered | = help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms = note: the matched value is of type `Opcode` error[E0004]: non-exhaustive patterns: `Opcode2(Opcode(0_u8))` and `Opcode2(Opcode(2_u8..=u8::MAX))` not covered --> $DIR/issue-88331.rs:27:20 | LL | pub struct Opcode2(Opcode); | --------------------------- `Opcode2` defined here ... LL |     move |i| match msg_type { |                    ^^^^^^^^ patterns `Opcode2(Opcode(0_u8))` and `Opcode2(Opcode(2_u8..=u8::MAX))` not covered | = help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms = note: the matched value is of type `Opcode2` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0004`. </ins>

Discussion:
The following ICE was found migrating . cc which was very similar, but has been fixed. Also found in: - https://crater- <!-- 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<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim
Change:
`unsafe` function"; tcx.sess.span_err(attr.span, msg); } <del> from_target_feature(tcx, attr, &whitelist, &mut trans_fn_attrs.target_features); </del> <ins> from_target_feature(tcx, id, attr, &whitelist, &mut trans_fn_attrs.target_features); </ins> } else if attr.check_name("linkage") { if let Some(val) = attr.value_str() { trans_fn_attrs.linkage = Some(linkage_by_name(tcx, id, &val.as_str()));

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:
{% endfor %} ></script> {# #} {% endif %} <del> <div id="rustdoc-vars" {#+ #} </del> <ins> <meta name="rustdoc-vars" {#+ #} </ins> data-root-path="{{page.root_path|safe}}" {#+ #} data-static-root-path="{{static_root_path|safe}}" {#+ #} data-current-crate="{{layout.krate}}" {#+ #}

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. --The generated page HTML contains , which is not valid as per the (which only allows ). This has been the case since , which moved this div from the body to the header. I believe browsers will open the body if an invalid tag is encountered in the header (which you can see in inspect elements, where every item in between are inside of ), or something like that. This causes at least one bug: the attribute, which expands into a , is not displayed on Chrome and Chromium-based browsers. You can see this in the  crate on Chrome ! Firefox ! Generated HTML: vs : Manually moving the tag to the header correctly displays the favicon: ! !
label A-rustdoc-ui T-rustdoc
Thanks for the detailed report! Fixing it tomorrow.
Change:
} } <del> /// Maybe add libLLVM.so to the given destination lib-dir. It will only have /// been built if LLVM tools are linked dynamically. </del> <ins> /// Maybe add LLVM object files to the given destination lib-dir. Allows either static or dynamic linking. </ins> /// <del> /// Note: This function does not yet support Windows, but we also don't support ///       linking LLVM tools dynamically on Windows yet. fn maybe_install_llvm(builder: &Builder<'_>, target: TargetSelection, dst_libdir: &Path) { if !builder.config.llvm_link_shared { // We do not need to copy LLVM files into the sysroot if it is not // dynamically linked; it is already included into librustc_llvm // statically. return; } </del> <ins> /// Returns whether the files were actually copied. fn maybe_install_llvm(builder: &Builder<'_>, target: TargetSelection, dst_libdir: &Path) -> bool { </ins> if let Some(config) = builder.config.target_config.get(&target) { if config.llvm_config.is_some() && !builder.config.llvm_from_ci { // If the LLVM was externally provided, then we don't currently copy

Discussion:
From Switching to static linking would preclude any of the improvements from , so it would be better to use dynamic linking instead which would allow any contributor to get started without building LLVM from source or using system LLVM. That said, it sounds like dynamic linking will be very hard to do on other platforms. cc
Cc - do we know what the right way to bring the issues (bugs?) I found to LLVM developers? Are there active maintainers of LLVMs build system?
LLVM’s bugzilla is pretty much the only place for bug reports. If its something less defined than a precise bug report, talking it out on the mailing lists is the way to go.
In which way is static linking making downloaded LLVM impossible?
I don't think it's impossible to download/ship the statically linked LLVM, it's something I want to explore. That said, we want to move to dynamically linking LLVM because we ideally want to be applying ThinLTO to LLVM everywhere, not just on x86_64-unknown-linux-gnu, and since LTO happens at link-time, we want that to happen once, not on the multiple LLVM links occurring during CI.
Change:
#[inline] #[stable(feature = "atomic_access", since = "1.15.0")] pub fn into_inner(self) -> *mut T { <del> unsafe { self.p.into_inner() } </del> <ins> self.p.into_inner() </ins> } /// Loads a value from the pointer.

Discussion:
It's been unsafe since 2014 when it was called . Nobody thought about it, I guess, but it shouldn't be unsafe.
For reference the PR which it is
Someone thought about it enough to : Has something changed to make this consideration unnecessary or do you have an explanation of why the reasoning is faulty?
Because the function takes so by definition it must be the owner of the value so there can be no other viewers, either from this thread or another thread.
Although this isn't backwards-compatible there is some prior art of going unsafe -safe: (although, that was pre-1.0)
That's weird, it seems like you ought to be able to assign a safe fn to an unsafe fn pointer. , Nicole Mazzuca wrote:
We removed the subtyping relation at some point; it does seem like a coercion would be (probably) ok, but that would still not be (strictly) backwards compatible.
(I tend to agree that could be safe, though, and I highly doubt any existing crates would actually break due to this change.)
We could always do a crater run just to be absolutely sure nobody is turning into a function pointer.
HI ! Any news on this one ?
No change that I know of.
FWIW the relevant coercion was in
This change is breaking my crate. If I add the then it will work for older compilers. If I remove the then it will work for newer compilers. Is there a conditional compilation attribute for compiler version? I can't find one.
Use
Yeah, that's what I'm doing for now. It seems kind of lame, though. But it does work.
Change:
} } <ins> fn increment_outstanding_references(&mut self, is_public: bool) { self.outstanding_references += 1; if is_public { self.pub_outstanding_references += 1; } } fn decrement_outstanding_references(&mut self, is_public: bool) { let decrement_references = |count: &mut _| { assert!(*count > 0); *count -= 1; }; decrement_references(&mut self.outstanding_references); if is_public { decrement_references(&mut self.pub_outstanding_references); } } </ins> fn report_conflicts<F: FnMut(&NameBinding, &NameBinding)>(&self, mut report: F) { let binding = match self.binding { Some(binding) => binding,

Discussion:
Unfortunately, I can't reproduce this at a smaller scale. This issue occurs with as of commit . Rust version is Currently the tests (run from the directory with ) pass. However, applying the following patch: causes the following compiler error: which is claiming that an import conflicts with itself. I have pushed up the branch with that change applied for easy reproduction. Again, I'm sorry that I cannot provide a report on a smaller scale, but this appears to be some edge case blowing up. I have no clue why adding a module with a few imports and nothing else would be causing this issue.
Bisecting to find the nightly which caused this
I can confirm that this issue does not occur on . Unfortunately, there was a bug that prevented us from compiling on that wasn't fixed until , so I cannot provide anything more specific than that.
cc
Thanks for the report! This bug was introduced in . I diagnosed the issue and will fix it ASAP.
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. struct X { x: i32 } fn main() { let mut b: Vec<X> = vec![]; b.sort(); //~^ ERROR the trait `core::cmp::Ord` is not implemented for the type `X` } </ins>

Discussion:
Code: Error: The compiler should tell us, struct doesn't implements , at least.
This is fixed (after changing the type of to ):
Needs test?
Change:
<ins> // Check that dropping a trait object without a principal trait succeeds //@ needs-sanitizer-cfi // FIXME(#122848) Remove only-linux once OSX CFI binaries works //@ only-linux //@ compile-flags: --crate-type=bin -Cprefer-dynamic=off -Clto -Zsanitizer=cfi //@ compile-flags: -C target-feature=-crt-static -C codegen-units=1 -C opt-level=0 // FIXME(#118761) Should be run-pass once the labels on drop are compatible. // This test is being landed ahead of that to test that the compiler doesn't ICE while labeling the // callsite for a drop, but the vtable doesn't have the correct label yet. //@ build-pass struct CustomDrop; impl Drop for CustomDrop { fn drop(&mut self) {} } fn main() { let _ = Box::new(CustomDrop) as Box<dyn Send>; } </ins>

Discussion:
<!-- [31mICE[0m: Rustc '-Zsanitizer=cfi -Ccodegen-units=1 -Clto -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0'', 'thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0'' File: --original: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I believe this happens since cc
seems to also cause problems
The core problem here is the encoding of the receiver on a object that has no principal. There's a fix for this in the larger patch stack I was breaking down to land piecewise. I'll upload it in a moment. claim
Change:
#![feature(bool_to_option)] #![feature(box_patterns)] #![feature(box_syntax)] <ins> #![feature(cmp_min_max_by)] </ins> #![feature(const_fn)] #![feature(const_panic)] #![feature(const_fn_transmute)]

Discussion:
This prints the values in comments: Note that contains strictly more opportunities for optimization, but it's optimized worse. That's because it uses a "niche-filling" layout (using in the field of for ), but the "tag" layout wouldn't be any larger, because it has enough space in bytes to fit the (byte-sized) tag, and . uses the tagged layout since it has no other choice, and ends up with free values in the byte-sized tag, but "jumps the gun" on using a pre-existing niche.
Change:
} } <ins> /// Consumes the list into an iterator yielding elements by value. #[unstable = "matches collection reform specification, waiting for dust to settle"] pub fn into_iter(self) -> MoveItems<T> { MoveItems { inner: self, } } </ins> /// Returns the number of elements in the `RingBuf`. /// /// # Example

Discussion:
There's currently no method on . This might have been missed during collections reform, or was never implemented.
Change:
<ins> error[E0596]: cannot borrow `bar` as mutable, as it is not declared as mutable --> $DIR/issue-81700-mut-borrow.rs:3:5 | LL |     let bar = || { foo(x); }; |         ---            - calling `bar` requires mutable binding due to mutable borrow of `x` |         | |         help: consider changing this to be mutable: `mut bar` LL |     bar(); |     ^^^ cannot borrow as mutable error: aborting due to previous error For more information about this error, try `rustc --explain E0596`. </ins>

Discussion:
Compiled with gives:
This was caused by prioritize edit: in beta, this gives the following error: `
Assigning as discussed as part of the and removing .
Looks likely that is the cause. cc
Re-prioritizing as and removing as in the prioritization working group. label: +regression-from-stable-to-nightly +P-high -P-medium -I-prioritize
Change:
stride * field } layout::FieldPlacement::Union(count) => { <del> // This is a narrow bug-fix for rust-lang/rust#69191: if we are // trying to access absent field of uninhabited variant, then // signal UB (but don't ICE the compiler). // FIXME temporary hack to work around incoherence between // layout computation and MIR building if field >= count as u64 && base.layout.abi == layout::Abi::Uninhabited { throw_ub!(Unreachable); } </del> assert!( field < count as u64, "Tried to access field {} of union {:#?} with {} fields",

Discussion:
cc I suspect (but have not verified) that this would be fixed by a backport of
was merged in October, I don't think it's related
Does this need an mcve?
Yeah, but I think at this point a bisection might be more helpful since we're not yet sure what caused this.
Here's a somewhat small-ish MCVE: Haven't managed to remove mio yet, but that's just a matter of time ;) Note, that this doesn't depend on the feature. You can use as well.
Here's a "M"CVE without any dependencies: regression in nightly-2020-01-11 <details<summaryBacktrace</summary</details modify labels: -E-needs-bisection -E-needs-mcve
searched nightlies: from nightly-2019-11-01 to nightly-2020-02-16 regressed nightly: nightly-2020-01-11 searched commits: from to regressed commit: source code: Reproduce bisection with: <details<summaryCOLLAPSIBLE ERROR STACKTRACE</summary<p</p</details<details<summaryERROR BEFORE ICE REGRESSION</summary<p</p</details
It would be good to continue the bisection into the rollup PR, among the following PRs: (Point at opaque and closure type definitions in type errors) (Reduce special treatment for zsts) (Parse the syntax described in RFC 2632) (rustcastlowering: misc cleanup & rustc dep reductions) (Extend support of in type parameters) (expect after / )
triage: P-high, removing nomination, assigning to self.
Given the backtrace, I think it's probably (Reduce special treatment for zsts)
I can indeed reproduce the ICE at , seems to be the culprit. cc <details<summaryBacktrace</summary</details
Here is a more minimal MCVE: /me needs to invest some time in tools like rust-reduce or creduce...
Okay so now we have two different PR's to fix this. PR is almost certainly the right call for nightly itself. My only Question is whether we should also land PR and also then backport that to beta. My argument for why is that it is "obviously" less risky, which is important because the beta is going to be imminently promoted to stable.
Change:
[] GetPanicStrategy(CrateNum), [] IsNoBuiltins(CrateNum), [] ImplDefaultness(DefId), <ins> [] CheckItemWellFormed(DefId), [] CheckTraitItemWellFormed(DefId), [] CheckImplItemWellFormed(DefId), </ins> [] ReachableNonGenerics(CrateNum), [] NativeLibraries(CrateNum), [] PluginRegistrarFn(CrateNum),

Discussion:
At the moment WF checking is not done via a query. As a consequence, we cannot cache it during incremental compilation. Seems like an easy optimization. cc
I'm working on this.
Change:
} }); for param in generics.params { <del> if param.span == cause.span && sized_pred { </del> <ins> if param.span == cause_span && sized_pred { </ins> let (sp, sugg) = match param.colon_span { Some(sp) => (sp.shrink_to_hi(), " ?Sized +"), None => (param.span.shrink_to_hi(), ": ?Sized"),

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 --
Minimized via  and some manual item deletion: I can take a quick look into this one I guess. claim
Change:
.count(); let mut type_substs = types_provided; <ins> check_type_argument_count(this.tcx(), span, supplied_ty_param_count, required_ty_param_count, formal_ty_param_count); </ins> if supplied_ty_param_count < required_ty_param_count { <del> let expected = if required_ty_param_count < formal_ty_param_count { "expected at least" } else { "expected" }; span_err!(this.tcx().sess, span, E0243, "wrong number of type arguments: {} {}, found {}", expected, required_ty_param_count, supplied_ty_param_count); </del> while type_substs.len() < required_ty_param_count { type_substs.push(tcx.types.err); } } else if supplied_ty_param_count > formal_ty_param_count { <del> let expected = if required_ty_param_count < formal_ty_param_count { "expected at most" } else { "expected" }; span_err!(this.tcx().sess, span, E0244, "wrong number of type arguments: {} {}, found {}", expected, formal_ty_param_count, supplied_ty_param_count); </del> type_substs.truncate(formal_ty_param_count); } assert!(type_substs.len() >= required_ty_param_count &&

Discussion:
Example: I left a FIXME at the relevant part of the code.
Nominating for something.
I can mentor...
I'm willing to have a look if the mentor offer stands
I already have a proposed fix, I just need to clean it up and add a test.
thanks for volunteering. The offer is still up but has been working on it. I'm happy to help with other bugs too.