jiebi/CodeConvo huggingface dataset:
Change:
Some(t) => t, None => diag.bug(&msg()), } <del> } </del>  No newline at end of file <ins> } </ins>

Discussion:
This code is wrong, but the error message is confusing: Because I used accidentally as a type name when not using the right syntax ... this is pretty confusing:
One solution would be to add detail after the expected/found lines if primitive shadowing has come into play. This would not change the language, but make the error look like:
Change:
.zip(std::iter::repeat(1usize)) .map(|(a, b)| a + b) .map_while(Option::Some) <del> .peekable() </del> .skip(1) .map(|e| if e != usize::MAX { Ok(std::num::NonZeroUsize::new(e)) } else { Err(()) }); assert_in_place_trait(&iter);

Discussion:
This code leads to an out of bounds write, makes the assert fail and triggers miri: The problem is that after cloning a the inner iterator can no longer be considered advanced, but the may still yield the peeked element without advancing it, thus breaking the contract of .
This can be fixed by either removing from or by changing the impl of to clone the exact state of rather than allocating a smaller one. The latter may be unnecessarily costly when cloning a mostly-exhausted iterator, but on the other hand it would preserve the optimization. So I'd try the first one first and do a perf run to see what the impact is (when it was introduced it mostly helped rustdoc) and try the latter if there's a significant regression.
It may also be possible to fix this by specializing on to look into its (if available) and do a custom clone of its source. I'll see if specialization is powerful enough to pull that off.
Hrm, I think it would be possible to do that but it would require some additional helper traits or methods tailored to just this use-case since doesn't know about . That's probably too much hackery for this optimization.
This also effects stable modify labels: regression-from-stable-to-stable
Is it a regression though? Marking as according to the . modify labels -I-prioritize +P-critical
Technically when was merged it broke any crate that used code like this (which is not that unexpected like exploting panics and stuff like that). In fact I found this bug due to a project written in only safe rust code that was segfaulting
Change:
<ins> // Regression test for #72819: ICE due to failure in resolving the const generic in `Arr`'s type // bounds. #![feature(const_generics)] #![allow(incomplete_features)] struct Arr<const N: usize> where Assert::<{N < usize::max_value() / 2}>: IsTrue, //~^ ERROR constant expression depends on a generic parameter { } enum Assert<const CHECK: bool> {} trait IsTrue {} impl IsTrue for Assert<true> {} fn main() { let x: Arr<{usize::max_value()}> = Arr {}; } </ins>

Discussion:
Amusingly the following ICEs while has a compiler error that hints at the const generic actually getting resolved. () Errors:
Also happens on stable without the feature gate
Triage: This is no longer ICE and emits an error correctly by . Marking as E-needs-test.
Change:
let adt_ty_hint = self.expected_inputs_for_expected_output(span, expected, adt_ty, &[adt_ty]) <del> .get(0).cloned().unwrap_or(adt_ty); </del> <ins> .get(0).cloned().unwrap_or(adt_ty); // re-link the regions that EIfEO can erase. self.demand_eqtype(span, adt_ty_hint, adt_ty); </ins> <del> let (substs, hint_substs, adt_kind, kind_name) = match (&adt_ty.sty, &adt_ty_hint.sty) { (&ty::TyAdt(adt, substs), &ty::TyAdt(_, hint_substs)) => { (substs, hint_substs, adt.adt_kind(), adt.variant_descr()) </del> <ins> let (substs, adt_kind, kind_name) = match &adt_ty.sty{ &ty::TyAdt(adt, substs) => { (substs, adt.adt_kind(), adt.variant_descr()) </ins> } _ => span_bug!(span, "non-ADT passed to check_expr_struct_fields") };

Discussion:
fails to type check, while succeeds.
This coercion is important when using byte string literals.
The tuple struct case is actually the function call "expected type" propagation, which would have to be adapted to struct literals as well.
Yes.
Coercion already happens in non-generic struct literals:
Yes, but the field types are taken from the struct and not combined with the overall expected type for the struct literal.
I just discovered this bug/unexpected behavior today (). I would like to see some movement on it because it's surprising that these two don't work the same way. Here's a workaround I found; it's ugly as hell but I'm using it in a generated file that no human would want to look through anyway: I tried type ascription but it seems to not cue coercion, it just moves the type error: It seems that forcing a concrete type on the struct literal works as well (I didn't expect this syntax to work, honestly): Unfortunately this won't work for me because I'm using too and I can't add this extra syntax myself.
Any news on this?
Is anyone working on it?
It seems like implemented a partial fix in but suggests that there are backwards incompatibility issues to be considered that preventing him from going further. I'm not quite sure what he had in mind there, perhaps he can elaborate.
Making sure we remember to look at this.
What I did is I computed a "light hint" (which becomes "strong hint", i.e. forcing coercion, if it reaches a block, and it's enough to help integer inference for ). This is a common problem with coercion hints, in that unless there's enough type information to prevent them from triggering, they will trigger early even if that breaks later on. The thing to try here is to replace with the simpler: doesn't even need to be computed if that works, since is at least as specific - AFAICT, we already have that "specificity" with function calls, but since it hasn't been used with struct literals before, crater/cargobomb might reveal regressions.
ok, I was mostly wondering if you encountered actual regressions in practice, or just theorize that this might lead to problems.
I don't think I got the chance to do a crater run and then I lost track of it.
will open a PR and we can try a crater run at least.

There is still a similar problem with the type inference of temporaries when you have an array that should be interpreted as a slice buried in a tuple inside an outer slice.
Change:
impl CStore { pub fn new(metadata_loader: Box<MetadataLoader>) -> CStore { CStore { <del> metas: RefCell::new(FxHashMap()), </del> <ins> metas: RefCell::new(IndexVec::new()), </ins> extern_mod_crate_map: RefCell::new(FxHashMap()), metadata_loader, }

Discussion:
While investigating the root cause(s) of and discussing (in the IRC chat room) the use of a hashmap mapping crate-numbers to crate-metadata, "why is that not an ?" One word: Legacy. Big time: the field has been a hashmap ever since was introduced, 6.5 years ago in () It should be a useful (and hopefully simple?) exercise to replace the hashmap that is with an .
So is it just replacing the type with? If sow what is the equivalent for insert?
Should be as simple as that
The only way I am seeing to add to an IndexVec is to push to the end at index == len But the hashmap uses the ability to insert at an arbitrary index: So I don't quite see how to make the conversion.
from my quick skimming, is only called from one place: , here: The in that context is always the steadily incremented . So I would suggest removing entirely, and replacing it with a some method that indeed pushes to the end at index == len, as you state, since it seems that will have the same end effect.
BTW if one really did need to support overwriting for arbitrary s, that is easy too, as long as they already exist in the , since supports the method that underlying : ; but I don't think we will need that in this case.
Maybe you want an ?
That's not 100% correct. Crate numbers are assigned in preorder - if a crate (say ) has a dependency (say ), then will get the earlier crate number, then will be loaded, and only then will the metadata for be assigned. But it's ok to use an to handle this.
You are right. I overlooked the fact that we 1. first increment the crate num (reserving the number, like for in your example), then 2. call (which may recursively re-enter ), before finally 3. calling at the end.
Ok, what is the best incantation to test this locally? In the meantime I will open a pr.
Change:
<ins> //! This is a regression test to avoid an ICE in diagnostics code. //! A typo in the compiler used to get the DefId of FnOnce, and //! use it where an associated item was expected. fn frob() -> impl Fn<P, Output = T> + '_ {} //~^ ERROR missing lifetime specifier //~| ERROR cannot find type `P` //~| ERROR cannot find type `T` //~| ERROR `Fn`-family traits' type parameters is subject to change fn open_parent<'path>() { todo!() } fn main() { let old_path = frob("hello"); //~^ ERROR function takes 0 arguments open_parent(&old_path) //~^ ERROR function takes 0 arguments } </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: cannot get associated-item of ', 'error: internal compiler error: cannot get associated-item of ' File: --another one caused by auto-reduced (treereduce-rust): 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: [associated_item] computing associated item data for [typeck] type-checking [analysis] running analysis passes on this crate --
fyi
not caused by that, only exposed by it. The issue is a typo using instead of in diagnostic code, getting the wrong and then attempting to treat as an associated item
Change:
<ins> // 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. // // 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. // Tests that compiling for a target which is not installed will result in a helpful // error message. // compile-flags: --target=s390x-unknown-linux-gnu // ignore s390x // error-pattern:target may not be installed fn main() { } </ins>

Discussion:
Today when you compile for a target that does not exist rustc gives the standard message for failing to find a crate, for . We can and should be more explicit about what this means. Actually what is almost certainly happening is that you don't have that target installed: It could instead say: A reasonable heuristic for printing this might be if the crate is named or and the sysroot is not overridden.
When I run on I get the error:
I would like to try my hand at this if no one else has picked it up already. I am fairly new to rust, so I might need some assistance getting the pull request into a something resembling a reasonable state.
Change:
} fn main() { <del> assert_eq!(1028, std::mem::size_of_val(&single())); assert_eq!(1032, std::mem::size_of_val(&single_with_noop())); assert_eq!(3084, std::mem::size_of_val(&joined())); assert_eq!(3084, std::mem::size_of_val(&joined_with_noop())); assert_eq!(7188, std::mem::size_of_val(&mixed_sizes())); </del> <ins> assert_eq!(1025, std::mem::size_of_val(&single())); assert_eq!(1026, std::mem::size_of_val(&single_with_noop())); assert_eq!(3078, std::mem::size_of_val(&joined())); assert_eq!(3079, std::mem::size_of_val(&joined_with_noop())); assert_eq!(7181, std::mem::size_of_val(&mixed_sizes())); </ins> }

Discussion:
Currently they use a hardcoded discriminant, which is quite a lot of room considering that generators don't typically have billions of states. They should be able to use the smallest unsigned integer type that fits all states instead (so in the vast majority of cases).
The discriminant is also never marked with a valid range, meaning that it never provides any niches that could be used to store other values. Not sure if doing that has any drawbacks, but it seems like a somewhat easy size optimization on first glance.
Fixing this was way easier than I expected, but I'd appreciate help with benchmarking the runtime impact of the fix in . So if anyone knows any async/await benchmarks that are not I/O heavy (so that they mostly test CPU overhead of async/await), I'd be happy to run them.
Change:
// Now, we just overwrite the fields we've explicity specified for &(i, ref e) in fields.iter() { <del> let dest = adt::trans_field_ptr(bcx, repr, addr, discr, i); </del> <ins> let dest = adt::trans_field_ptr(bcx, &*repr, addr, discr, i); </ins> let e_ty = expr_ty_adjusted(bcx, &**e); bcx = trans_into(bcx, &**e, SaveIn(dest)); let scope = cleanup::CustomScope(custom_cleanup_scope);

Discussion:
The current translation for struct update in the case of ignore looks incorrect. It should only move those fields that are not specified manually. This can mean the difference between moving the base as a whole and not. Probably the easiest thing to do is to create an alloca, use the same code as the normal path, and just drop the alloca afterwards.
See FIXME.
visiting for triage. nominating for production ready.
Accepted for production-ready
visting for triage, still relevant. FYI, the module in question is
Change:
ncpus=$(nproc) fi <del> make -j $ncpus tidy make -j $ncpus if [ ! -z "$XPY_CHECK" ]; then exec python2.7 $SRC/x.py $XPY_CHECK </del> <ins> if [ ! -z "$XPY_RUN" ]; then exec python2.7 $SRC/x.py $XPY_RUN </ins> else <del> exec make $RUST_CHECK_TARGET -j $ncpus </del> <ins> make -j $ncpus tidy make -j $ncpus if [ ! -z "$XPY_CHECK" ]; then exec python2.7 $SRC/x.py $XPY_CHECK else exec make $RUST_CHECK_TARGET -j $ncpus fi </ins> fi

Discussion:
The process of creating the tarballs doesn't include .gitignore files from src/vendor. This results in a missmatched hash failure when building with vendoring enabled. Hoping to switch to rustbuild with the next rust release! FYI: I'd be happy with the vendoring happening during the create tarball process, having enormous vendoring commits in the git history is ugly... !
Needs to be fixed for 1.15.
cc
Seems like the vendoring process should include a sanity check that the vendored sources hash correctly.
Fixed in
Things move fast around here. Awesome thanks!
Change:
// self by value, has no type parameters and does not use the `Self` type, except // in self position. pub fn check_object_safety<'tcx>(tcx: &ty::ctxt<'tcx>, <del> object_trait: &ty::TyTrait<'tcx>, </del> <ins> object_trait: &ty::TraitRef<'tcx>, span: Span) { let mut object = object_trait.clone(); if object.substs.types.len(SelfSpace) == 0 { object.substs.types.push(SelfSpace, ty::mk_err()); } let object = Rc::new(object); for tr in traits::supertraits(tcx, object) { check_object_safety_inner(tcx, &*tr, span); } } fn check_object_safety_inner<'tcx>(tcx: &ty::ctxt<'tcx>, object_trait: &ty::TraitRef<'tcx>, </ins> span: Span) { // Skip the fn_once lang item trait since only the compiler should call // `call_once` which is the method which takes self by value. What could go // wrong? match tcx.lang_items.fn_once_trait() { <del> Some(def_id) if def_id == object_trait.principal.def_id => return, </del> <ins> Some(def_id) if def_id == object_trait.def_id => return, </ins> _ => {} } <del> let trait_items = ty::trait_items(tcx, object_trait.principal.def_id); </del> <ins> let trait_items = ty::trait_items(tcx, object_trait.def_id); </ins> let mut errors = Vec::new(); for item in trait_items.iter() {

Discussion:
The following code either aborts or segfaults for me, depending on if I'm in gdb or not, on Linux: With optimizations, becomes Which means we're doing something very bad when translating this code.
Still reducing...
FWIW, I can confirm that behaviour on Windows.
cc me
Reduced: And that makes it clear the issue is not broken codegen, but rather that is mistakenly treated as object-safe (while it inherits from the non-object-safe ).
nice. cc
P-backcompat-lang, 1.0.
Hint: iterate with
takes/creates s but needs a . I'm not sure how to make these agree.
checkobjectsafety should use to enumerate the trait_ref, I think. Annoyingly this does require a right now (harder to fix than you might think).
On I get , which is an unwrap in in the supertraits iterator.
Change:
//  N, N-vptr, O // emit dsa segment first. <del> if let ControlFlow::Break(v) = (segment_visitor)(VtblSegment::MetadataDSA) { return Some(v); } </del> <ins> segment_visitor(VtblSegment::MetadataDSA)?; </ins> let mut emit_vptr_on_new_entry = false; let mut visited = PredicateSet::new(tcx); let predicate = trait_ref.without_const().to_predicate(tcx); let mut stack: SmallVec<[(ty::PolyTraitRef<'tcx>, _, _); 5]> = <del> smallvec![(trait_ref, emit_vptr_on_new_entry, None)]; </del> <ins> smallvec![(trait_ref, emit_vptr_on_new_entry, maybe_iter(None))]; </ins> visited.insert(predicate); // the main traversal loop: // basically we want to cut the inheritance directed graph into a few non-overlapping slices of nodes <del> // that each node is emitted after all its descendents have been emitted. </del> <ins> // such that each node is emitted after all its descendants have been emitted. </ins> // so we convert the directed graph into a tree by skipping all previously visited nodes using a visited set. // this is done on the fly. // Each loop run emits a slice - it starts by find a "childless" unvisited node, backtracking upwards, and it

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:
<ins> const fn cmp(x: fn(&'static ()), y: for<'a> fn(&'a ())) -> bool { x == y //~^ ERROR pointers cannot be reliably compared during const eval } fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'assertion failed ' left: Binder(fn(), [])' ' right: Binder(fn(), [Region(BrNamed(DefId(0:4 ~ 9CACA62BEBDE508A04F27A9C164063CBF2C6A046198481389A0AC4A29C2578C3[3bbd]::cmp::'a), 'a))])'', 'assertion failed ' left: Binder(fn(), [])' ' right: Binder(fn(), [Region(BrNamed(DefId(0:4 ~ 9CACA62BEBDE508A04F27A9C164063CBF2C6A046198481389A0AC4A29C2578C3[3bbd]::cmp::'a), 'a))])'' File: --auto-reduced (treereduce-rust): 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: [mirconstqualif] const checking [mirpromoted] promoting constants in MIR for [mirborrowck] borrow-checking [analysis] running analysis passes on this crate --
Regression in cc
that seems off :sweat_smile: this PR should not result in behavior differences
ah yes my bad :D I left in by accident from a previous bisection and that was the pr that the flag :laughing:
should exist since pretty much forever :grin: 1.48
Regression in nightly-2023-04-20 fetching (via remote github) commits from max(, 2023-04-17) to ending github query because we found starting sha: getcommitsbetween returning commits, len: 10 commit[0] 2023-04-18: Auto merge of - petrochenkov:slimchild, r=cjgillot commit[1] 2023-04-18: Auto merge of - saethlin:encode-hashes-as-bytes, r=cjgillot commit[2] 2023-04-19: Auto merge of - jyn514:download-rustc-tests,

r=albertlarsan68 commit[3] 2023-04-19: Auto merge of - miguelraz:canoodling2-electric-boogaloo, r=compiler-errors commit[4] 2023-04-19: Auto merge of - matthiaskrgr:rollup-9m7rw3u, r=matthiaskrgr commit[5] 2023-04-19: Auto merge of - Nilstrieb:fluent-macro, r=davidtwco commit[6] 2023-04-19: Auto merge of - fee1-dead-contrib:rm-const-traits, r=oli-obk commit[7] 2023-04-19: Auto merge of - WaffleLapkin:‍sound, r=compiler-errors commit[8] 2023-04-19: Auto merge of - matthiaskrgr:rollup-346kik6, r=matthiaskrgr commit[9] 2023-04-19: Auto merge of - ecnelises:big_archive, r=bjorn3
This might be related to cc one nightly before this errors with so maybe const-related
the cause is that the assert mentioned in is wrong. COmparing pointers with different bound vars is ok. This should either use actual semantic equality or just yeet the assert
Change:
[[package]] name = "compiletest_rs" <del> version = "0.2.10" </del> <ins> version = "0.3.1" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ <ins> "diff 0.1.10 (registry+https://github.com/rust-lang/crates.io-index)", "filetime 0.1.14 (registry+https://github.com/rust-lang/crates.io-index)", "getopts 0.2.15 (registry+https://github.com/rust-lang/crates.io-index)", "libc 0.2.33 (registry+https://github.com/rust-lang/crates.io-index)", </ins> "log 0.3.8 (registry+https://github.com/rust-lang/crates.io-index)", "rustc-serialize 0.3.24 (registry+https://github.com/rust-lang/crates.io-index)", ]

Discussion:
branch: master Compiling cargometadata v0.2.3 Compiling clippylints v0.0.166 (file:///home/ryan/git/rust/src/tools/clippy/clippylints) error: :vis fragment specifier is experimental and subject to change (see issue ) --<declarelint macros:1:3 | 1 | ( NAME : ident , desc : expr ) =( | ^^^^^^^^^^^ | = help: add #![feature(macrovismatcher)] to the crate attributes to enable error: :vis fragment specifier is experimental and subject to change (see issue ) --<declarelint macros:1:3 | 1 | ( NAME : ident , desc : expr ) =( | ^^^^^^^^^^^ | = help: add #![feature(macrovismatcher)] to the crate attributes to enable error: aborting due to previous error error: aborting due to previous error error: Could not compile . warning: build failed, waiting for other jobs to finish... error: Could not compile . warning: build failed, waiting for other jobs to finish... error: build failed This failure is expected (see ) Build completed successfully in 1:46:49
Everything is actually fine, as you can see by the last two lines of the log. I hope to remove the error log if the failure is expected in the future, but not sure yet how best to do that.
Is it related to rust-lang-nursery/rust-clippy?
Change:
|                        ~~~~~~~~~ error: called `.get().unwrap()` on a slice <del> --> tests/ui/get_unwrap.rs:80:18 </del> <ins> --> tests/ui/get_unwrap.rs:81:18 </ins> | LL |         let _x = f.get(1 + 2).unwrap().to_string(); |                  ^^^^^^^^^^^^^^^^^^^^^

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: Instead, this happened: Apparently, taking a shared reference of will suppress the lint. This seems like a false negative. While false negatives can't be avoided entirely, this case seems to be avoidable as taking a shared reference shouldn't change the type of (which is ) or modify any data in this example. Note that will trigger the lint properly. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
See also .
claim
Note this is a problem because which is supposed to fail to compile but this bug makes it fail at runtime instead
In case no one has dug into it yet, the error is suppressed in but not in and before:
label +regression-from-stable-to-stable
WG-prioritization assigning priority (). label -I-prioritize +P-medium
This is caused by . It only ever worked because the lint ran after optimizations. I made a fix . It specializes the length of arrays as constant, even if the array isn't. I'm going to open a PR when I have time, probably tomorrow. In the long term, I'd like to implement some more extensive tracking of "what parts of a value are constant". For example, the compiler currently assumes that anything that had its reference taken can change, but actually, this can only happen inside (as I understand it).
Labels from the closed duplicate , label A-diagnostics, A-lint, A-mir-opt, T-compiler.
Fixed on stable label E-needs-test
I claim the add test part
This lint only appears on full builds (not check), but this will be fixed once lands.
Reopening because I feel this is not yet solved, see on . As per the , should nail down this issue?
MRE: Also, duplicate of
Another variant of this same issue: