jiebi/CodeConvo huggingface dataset:
Change:
<del> // Copyright 2012-2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. </del> <ins> // The Computer Language Benchmarks Game // http://benchmarksgame.alioth.debian.org/ </ins> // <del> // 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. </del> <ins> // contributed by the Rust Project Developers // Copyright (c) 2012-2014 The Rust Project Developers // // All rights reserved. // // Redistribution and use in source and binary forms, with or without // modification, are permitted provided that the following conditions // are met: // // - Redistributions of source code must retain the above copyright //   notice, this list of conditions and the following disclaimer. // // - Redistributions in binary form must reproduce the above copyright //   notice, this list of conditions and the following disclaimer in //   the documentation and/or other materials provided with the //   distribution. // // - Neither the name of "The Computer Language Benchmarks Game" nor //   the name of "The Computer Language Shootout Benchmarks" nor the //   names of its contributors may be used to endorse or promote //   products derived from this software without specific prior //   written permission. // // THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS // "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT // LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS // FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE // COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, // INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES // (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR // SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) // HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, // STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) // ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED // OF THE POSSIBILITY OF SUCH DAMAGE. </ins> // no-pretty-expanded

Discussion:
See I propose to change the license of Non trivial contributors: OK OK Contributors appearing in git blame that are trivial (except artifacts as empty lines): OK OK OK OK OK (MoCo employee) OK OK OK OK (MoCo employee) OK OK 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 my contributions to the benchmarks under src/test/bench/ (including shootout-chameneos-) according to the terms of the Computer Language Benchmarks Game license ().
I believe that was a MoCo employee at the time of all his contributions to this benchmark, so we're probably good on that front.
Change:
cx.span_lint(PRIVATE_NO_MANGLE_FNS, it.span, msg.as_slice()); } }, <ins> ast::ItemStatic(..) => { if attr::contains_name(it.attrs.as_slice(), "no_mangle") && !cx.exported_items.contains(&it.id) { let msg = format!("static {} is marked #[no_mangle], but not exported", it.ident); cx.span_lint(PRIVATE_NO_MANGLE_STATICS, it.span, msg.as_slice()); } }, ast::ItemConst(..) => { if attr::contains_name(it.attrs.as_slice(), "no_mangle") { // Const items do not refer to a particular location in memory, and therefore // don't have anything to attach a symbol to let msg = "const items should never be #[no_mangle], consider instead using  `pub static`"; cx.span_lint(NO_MANGLE_CONST_ITEMS, it.span, msg); } } </ins> _ => {}, } }

Discussion:
Will not actually be exported in the resulting object. There are two obvious fixes, the first being to expand on my pub-not-exported lint to warn you that this will not work, the second being to fix the compiler to export the symbol with the appropriate value (Without altering the existing inlining behaviour, although it may give a more reasonable option for cases like trying to take the address of a item). Happy to work on either, although I would need a mentor for the second part.
I'm not sure what you mean by it not being exported. It might not be visible as a symbol (if you're linking with some C code or something), but you can certainly reference that item from another Rust crate.
Sorry for not being clear. That's exactly what I meant, the symbol is not visible in the resulting object. This is pretty confusing (I've been doing a lot of C(++) <-Rust lately and I'm trying to make the compiler warn people about all the things that have tripped me up)
I think the right option is to expand the lint. The whole difference between and is that the former isn't guaranteed to have a location in memory. To a C programmer it's like a variable.
Sounds totally reasonable. I'll expand the lint.
Ah, I see now. I didn't know there was a lint for on items that don't export a symbol. That explains a lot!
Change:
.iter() .enumerate() .map(|(i, ty)| Argument { <del> name: name_from_pat(&body.params[i].pat), </del> <ins> name: Symbol::intern(&rustc_hir_pretty::param_to_string(&body.params[i])), </ins> type_: ty.clean(cx), }) .collect(),

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. --code is from <!-- 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
label -T-compiler +T-rustdoc
The playground's nightly compiler doesn't ICE on this example. Are you able to confirm this with the latest nightly?
rustdoc is crashing, not the compiler itself. Playground doesn't have a button for running rustdoc.
MCVE: Marking as P-medium since this happens on valid code.

<!-- 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. --Hi, I hit a strange build failure in CI where fails to build for . Here's a reduced reproducer: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --I'm using current nightly, but this is a regression from stable () to beta (). : points to (in ), but this feels like an LLVM bug. I can't trigger it via and though. The LLVM version matches, but I'm probably not reproducing 's interactions with LLVM faithfully.. Sorry for the noise with obscure target architectures, but I'm reporting the issue here because I don't know how to reproduce it on LLVM's side :slightlysmilingface:
It's fine. We may not offer the best support for them due to technical and resource constraints, but we still want people to have the option to run Rust code on their OpenWRT router or their PlayStation or whatever.
i hit the same problem. build failed for
May be caused by a trigger for
FYI, this can be worked around by enabling optimization. The same workaround works for error from when using build-std in the latest nightly. (, , , )
Maybe its relocation is too far then that has been truncated?
This issue should be fixed by . Initially, the cause of the issue and the solution are explained in , but more elegant solution is just to remove derived isBlockOnlyReachableByFallthrough for Mips architecture.
label llvm-fixed-upstream
Can someone confirm that this is fixed on nightly?
Yep. My initial reproducer fails with but compiles on . :chartwithupwards_trend:
Change:
} self.structurally_resolved_type(autoderef.span(), autoderef.final_ty(false)); <del> if let Some((adjustments, did, field_ty)) = private_candidate { </del> <ins> if let Some((adjustments, did)) = private_candidate { </ins> // (#90483) apply adjustments to avoid ExprUseVisitor from // creating erroneous projection. self.apply_adjustments(base, adjustments); self.ban_private_field_access(expr, base_ty, field, did); <del> return field_ty; </del> <ins> return self.tcx().ty_error(); </ins> } if field.name == kw::Empty {

Discussion:
The code below yields two errors: field is private error in if expression because type is instead of This means a user can observe the type of a private field of a dependency in their error messages. It doesn't mean they can actually use that information, but it seems weird at least. Is this actually an issue? If you don't consider it one, feel free to close this. - - (originally seen )
I won't close the ticket as this deserves a conversation to be had, but I personally don't consider it to be a big problem. Parsing x.len as when we suggest that would be nice, but in this case it would lead to confusing errors if we don't annotate the compiler state with something along the lines of
Hi Do any of you have opinions on this matter? I lean towards closing as "wontfix" because I feel the current behavior is acceptable.
I agree, like you mentioned , there are some improvements we could make, but I think the current behaviour is fine.
Change:
let mut multi_span: MultiSpan = trait_span.into(); multi_span.push_span_label(trait_span, format!("this is the trait that is needed")); let descr = self.tcx.associated_item(item_def_id).descr(); <ins> let rcvr_ty = rcvr_ty.map(|t| format!("`{t}`")).unwrap_or_else(|| "the receiver".to_string()); </ins> multi_span <del> .push_span_label(item_span, format!("the {descr} is available for `{rcvr_ty}` here")); </del> <ins> .push_span_label(item_span, format!("the {descr} is available for {rcvr_ty} here")); </ins> for (def_id, import_def_id) in candidates { if let Some(import_def_id) = import_def_id { multi_span.push_span_label(

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: unexpected non-type Node::GenericParam: Type { default: None, synthetic: false }', 'error: internal compiler error: unexpected non-type Node::GenericParam: Type { default: None, synthetic: false }' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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: [typeof] computing type of [typeck] type-checking --
mvce:
:thinking: cc
I'm gonna assume that it is this line that needs additional logic:
Change:
} impl rustc_serialize::Encodable for AttrId { <del> fn encode<S: Encoder>(&self, _: &mut S) -> Result<(), S::Error> { Ok(()) </del> <ins> fn encode<S: Encoder>(&self, s: &mut S) -> Result<(), S::Error> { s.emit_unit() </ins> } } impl rustc_serialize::Decodable for AttrId { <del> fn decode<D: Decoder>(_: &mut D) -> Result<AttrId, D::Error> { Ok(crate::attr::mk_attr_id()) </del> <ins> fn decode<D: Decoder>(d: &mut D) -> Result<AttrId, D::Error> { d.read_nil().map(|_| crate::attr::mk_attr_id()) </ins> } }

Discussion:
The JSON for is broken because the for attributes serializes to nothing. An empty library produces the following: The important bit which is clearly not valid JSON. It looks like the  serialization was removed in . I'm not sure what a solution is here. I'm guessing AST serialization is used elsewhere, where this field isn't needed. I'm not too familiar with , so I'm not sure if it has something equivalent to . cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Looks like the encoding/decoding change from needs to be reverted. Reverting should be ok because and don't do anything anyway (at least when inlined) during metadata encoding and decoding. The change is trivial, so marking this as E-easy, but if it's not done until the weekend I'll submit the PR myself.
claim
Change:
to `/WHOLEARCHIVE` for `link.exe`, and to `-force_load` for `ld64`. The modifier does nothing for linkers that don't support it. <del> The default for this modifier is `-whole-archive`.  NOTE: The default may currently be different in some cases for backward compatibility, but it is not guaranteed. If you need whole archive semantics use `+whole-archive` explicitly. </del> <ins> The default for this modifier is `-whole-archive`. </ins> ### Linking modifiers: `bundle`

Discussion:
Originally reported as , but the actual bug affects every libraries and platforms. generates the linker command . Without it correctly doesn't link whole archive. It is expected to link whole archive only if passing modifier.
or whoever wants to look at linkage troubles today
Looks like it is a back compat hack:
Not sure to understand why tests are special, but it's intentional from indeed. Feels like a bad workaround for missing +whole-archive modifiers in some projects?
My reading from the code comment is that you can't aren't allowed to use for tests of rlib crates at all, not that some projects are missing it.
Why is that not allowed? That would be the root issue then?
It seems like and are not compatible with each other for rlibs. Someone else may know better why this is the case. It's been a while since I last looked at this code.
The combination was recently stabilized in so it may be possible to remove this hack now. We'll just need to run crater, send fixes to affected crates, and all that stuff.
Fixed in
Change:
pub fn prepare_vtable_segments<'tcx, T>( tcx: TyCtxt<'tcx>, trait_ref: ty::PolyTraitRef<'tcx>, <del> mut segment_visitor: impl FnMut(VtblSegment<'tcx>) -> ControlFlow<T>, </del> <ins> segment_visitor: impl FnMut(VtblSegment<'tcx>) -> ControlFlow<T>, </ins> ) -> Option<T> { <ins> prepare_vtable_segments_inner(tcx, trait_ref, segment_visitor).break_value() } /// Helper for [`prepare_vtable_segments`] that returns `ControlFlow`, /// such that we can use `?` in the body. fn prepare_vtable_segments_inner<'tcx, T>( tcx: TyCtxt<'tcx>, trait_ref: ty::PolyTraitRef<'tcx>, mut segment_visitor: impl FnMut(VtblSegment<'tcx>) -> ControlFlow<T>, ) -> ControlFlow<T> { </ins> // The following constraints holds for the final arrangement. // 1. The whole virtual table of the first direct super trait is included as the //    the prefix. If this trait doesn't have any super traits, then this step

Discussion:
While working on I think I found a bug. Given this program: rustc outputs the following vtable layout: Which is surprising, because is unnecessary — does not have any methods, so vtable can be inlined... I think we should be smarter here: (for the record, I'm pretty sure this happens in practice, I've found this with ) Originally posted by in
cc
sorry been slow a little recently... This is a nice improvement.
Change:
let variable_type = node_id_type(bcx, node_id); let scope_metadata = bcx.fcx.debug_context.get_ref(cx, span).fn_metadata; <del> let llvm_env_data_type = type_of::type_of(cx, env_data_type); </del> <ins> // env_pointer is the alloca containing the pointer to the environment, // so it's type is **EnvironmentType. In order to find out the type of // the environment we have to "dereference" two times. let llvm_env_data_type = val_ty(env_pointer).element_type().element_type(); </ins> let byte_offset_of_var_in_env = machine::llelement_offset(cx, llvm_env_data_type, env_index);

Discussion:
So, this code raises an assertion in llvm when compiling with -g. Without -g it works fine. Raised assertion is Edit: reduced code more
Duplicate of ? (there are some comments with unboxed closures and /)
It worked with the rustc versions from around last week. Especially the rustup versions. A friend just tested it with his "old" version from 11/26, and it still works there. So either it's new or it's a regression bug.
cc
I'll look into it.
I suspect the culprit is makereturnslotpointer in librustctrans::trans::builder
Change:
<ins> error[E0275]: overflow evaluating the requirement `Runtime<RootDatabase>: RefUnwindSafe` | = help: consider increasing the recursion limit by adding a `#![recursion_limit = "256"]` attribute to your crate (`cycle_via_builtin_auto_trait_impl`) note: required because it appears within the type `RootDatabase` --> $DIR/cycle-via-builtin-auto-trait-impl.rs:13:8 | LL | struct RootDatabase { |        ^^^^^^^^^^^^ note: required for `RootDatabase` to implement `Database` --> $DIR/cycle-via-builtin-auto-trait-impl.rs:17:24 | LL | impl<T: RefUnwindSafe> Database for T { |         -------------  ^^^^^^^^     ^ |         | |         unsatisfied trait bound introduced here note: required because it appears within the type `Runtime<RootDatabase>` --> $DIR/cycle-via-builtin-auto-trait-impl.rs:24:8 | LL | struct Runtime<DB: Database> { |        ^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0275`. </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: This is modification of with the difference being ` Rust OOM'd here after eating at least 20 gb of memory :sweat_smile: I expected to see this happen: explanation NO OOM, maybe an error Instead, this happened: explanation OOM <!-- 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. --:
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
// we must create two defs. let coroutine_def = self.create_def(coroutine_kind.closure_id(), kw::Empty, DefKind::Closure, span); <del> self.with_parent(coroutine_def, |this| visit::walk_expr(this, body)); </del> <ins> self.with_parent(coroutine_def, |this| this.visit_expr(body)); </ins> } _ => visit::walk_fn(self, fn_kind), }

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 --
cc
I found the bug claim
Change:
<ins> // Copyright 2017 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(rustc_attrs)] #![allow(warnings)] trait Mirror { type It; } impl<T> Mirror for T { type It = Self; } #[rustc_error] fn main() { //~ ERROR compilation successful let c: <u32 as Mirror>::It = 5; const CCCC: <u32 as Mirror>::It = 5; } </ins>

Discussion:
I was trying to compile the following code: And got the following compiler error: Version info:
Still ICEs.
Minimal:
Triage: tracked by glacier
No longer ICEs today. E-needstest. I'm somewhat concerned though because this is the second glacier-tracked ICE that I've seen "fixed."
This was only broken because of the old code.
Change:
} } } <ins> #[test] fn test_from_zero_sized_vec() { let v = vec![(); 100]; let queue = VecDeque::from(v); assert_eq!(queue.len(), 100); } </ins>

Discussion:
This code panics under Miri, and also when I compile to WASM, though not when running normally. The overflow is here:
I can reproduce when using Miri, but it works fine for me with WASM: (Same with nightly toolchain.)
panics with it always fails here because is greater than so underflows.
Why is this specific to ZSTs?
does not allocate for and starts out with capacity which overflows when converting to a deque which does not expect this
Assigning and removing as in the prioritization working group.
Currently on playground it seems to work fine both under Miri and regular rustc? Indeed something would be very wrong if it only panicked on Miri... version panics both with rustc and Miri. Maybe the example in the OP should be updated.
Yes, though at time of posting it did fail under miri (and only under miri) on the playground. Sorry if I was unclear; I meant that I got the same panic when running the built WASM.
My guess is that something in libstd changed to fix the panic for your case (but not for and when you tested this, Miri was broken in the latest toolchain so playground had an older version of Miri. When this happens again, please note down the exact versions of every component involved, so we can make sure this is comparing Miri and rustc for the same toolchain, not two different versions of Rust.
The originally reported panic is an overflow check and one of those that is not inherited cross-crate. To observe it the standard library must be built with overflow checks. It's still an issue right now.
Ah, so this stopped to fail in Miri when we recently stopped building libstd with debug assertions.