jiebi/CodeConvo huggingface dataset:
Change:
checksum = "d29ab0c6d3fc0ee92fe66e2d99f700eab17a8d57d1c1d3b748380fb20baa78cd" [[package]] <ins> name = "security-framework" version = "2.0.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "c1759c2e3c8580017a484a7ac56d3abc5a6c1feadf88db2f3633f12ae4268c69" dependencies = [ "bitflags", "core-foundation", "core-foundation-sys", "libc", "security-framework-sys", ] [[package]] name = "security-framework-sys" version = "2.0.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "f99b9d5e26d2a71633cc4f2ebae7cc9f874044e0c351a27e17892d76dce5678b" dependencies = [ "core-foundation-sys", "libc", ] [[package]] </ins> name = "semver" version = "0.9.0" source = "registry+https://github.com/rust-lang/crates.io-index"

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 steps to reproduce the bug. --(The actual target doesn't seem to matter, the feature just requires that we pass a argument.) The following error occurs: I think this issue occurs because already landed, while the cargo-side revert in did not. So this issue will likely go away after the next cargo update. I still decided to open this issue in case other people encounter the same problem. <!-- 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. --:
Cc for
This will be fixed by .
Change:
} // This module has a very short name because it's used a lot. <ins> #[allow(rustc::default_hash_types)] </ins> pub mod sym { use super::Symbol; use std::convert::TryInto;

Discussion:
Filing this since had the idea and so that we don't forget. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
It should be as easy (unless I'm overlooking something) as adding to all declaretool_lint invocations and then fixing the fallout (changing imports as described by the lint)
I'd like to handle this claim
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. #![feature(const_fn)] const fn f() -> usize { 5 } struct A { field: usize, } fn main() { let _ = [0; f()]; } </ins>

Discussion:
at the current version of error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'internal error: entered unreachable code', playpen: application terminated with error code 101
The reason this is happening is because the code thinks is an enum variant or a tuple struct. The code around this is somewhat redundant and would probably better be solved by making enum variants const evaluable and adding a function that translates s to

This code wrongly states "expected constant integer for repeat count, but non-constant path in constant expression" This one works
accidentally fixed in
Change:
} else if Some(did) == cx.lang_items.no_share_bound() { tc | TC::ReachesNoShare } else if Some(did) == cx.lang_items.unsafe_type() { <del> tc | TC::InteriorUnsafe </del> <ins> // FIXME(#13231): This shouldn't be needed after // opt-in built-in bounds are implemented. (tc | TC::InteriorUnsafe) - TC::Nonsharable </ins> } else { tc }

Discussion:
I think it's sound? It seems like a straightforward solution would be to add a attribute. We could also add an marker type, but I think that'd be a bit strange since unlike the other markers, this one would remove_ a restriction on the type, not add one. The current situation requires some gross workarounds like this:
In an opt-in kind world, this would probably be an attribute that would work like .
There is still an issue if the wrapped type is not safe to access from a different thread than the one it was created on. EDIT: mentioned on IRC, which would solve the issue I thought of.
I talked with about this . He thinks that can be special (it's already a lang item), and will be regardless of whether is share. This would fix the inference problem. Assuming an opt-in world, everything would look like: Today's compiler would reject this code because it does not think that is . If the compiler thought that were indeed , then the type would be
Methods on are only implemented for so that shouldn't be an issue.
could be special cased now too. However, given the fact that opt-in kinds are coming, I don't it'd be worth it. I'll make sure to do this as part of the opt-in work.
FWIW, I've updated the RFC to include text about this.
With the removal of (which previously handled this scenario for us - making something that is not into ), this issue is currently blocking Servo's current Rust upgrade, because we cannot simply replace previous uses of with . cc
As mentioned in my previous comment, with few changes could be made always now too. It'll be a couple of weeks before the opt-in work is done. This is probably worth discussing in the next meeting. The issue is already assigned to me, I'm happy to tackle it asap if needed.
Thanks!

I think the biggest things we're hoping for are: 1) a workaround that we can use for now until the Right Thing lands that isn't as ugly as copying over all of the old sync crate 2) making sure that this gets fixed at some point in the future I appreciate the offer, but don't need to you drop everything you're doing and work on this, especially since it sounds invasive enough that we probably couldn't cherry-pick it and we would like to finish off this Rust upgrade before we start in on yet another.
if you can pay for an extra allocation, I've worked around this issue for now by representing an as an and casting between and as needed. It's a bit hacky, and you'll need to make sure that there's a destructor that can clean up after it, but it's not too horrible.
Thanks! That seems totally reasonable. We'll just have to make sure to clean it up when the fix lands, which we don't always do :-/
Change:
<ins> include ../../run-make-fulldeps/tools.mk OUTPUT_DIR := "$(TMPDIR)/rustdoc" TMP_OUTPUT_DIR := "$(TMPDIR)/tmp-rustdoc" all: # Generate html docs $(RUSTDOC) src/lib.rs --crate-name foobar --crate-type lib --out-dir $(OUTPUT_DIR) # Copy first output for to check if it's exactly same after second compilation cp -R $(OUTPUT_DIR) $(TMP_OUTPUT_DIR) # Generate html docs once again on same output $(RUSTDOC) src/lib.rs --crate-name foobar --crate-type lib --out-dir $(OUTPUT_DIR) # Check if everything exactly same $(DIFF) -r -q $(OUTPUT_DIR) $(TMP_OUTPUT_DIR) # Generate json doc on the same output $(RUSTDOC) src/lib.rs --crate-name foobar --crate-type lib --out-dir $(OUTPUT_DIR) -Z unstable-options --output-format json # Check if expected json file is generated [ -e $(OUTPUT_DIR)/foobar.json ] # TODO # We should re-generate json doc once again and compare the diff with previously # generated one. Because layout of json docs changes in each compilation, we can't # do that currently. # # See https://github.com/rust-lang/rust/issues/103785#issuecomment-1307425590 for details. # remove generated json doc rm $(OUTPUT_DIR)/foobar.json # Check if json doc compilation broke any of the html files generated previously $(DIFF) -r -q $(OUTPUT_DIR) $(TMP_OUTPUT_DIR) </ins>

Discussion:
I tried this: I expected to see this happen: The second invocation takes essentially no time. Instead, this happened: The docs were completely rebuilt. The problem is that we remove the docs between each invocation: this is a regression from - do you think you'll have time to follow up? I think we can either add a stamp file to avoid rebuilding, or find some other way to avoid removing the whole directory - maybe we can only remove/copy the files, rather than everything? <!-- 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. --HEAD is branched from . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Ok, I confirmed that rustdoc only creates JSON files with --output-format json: So it should be enough to only copy .json files when passed --json, and only non-json files when it's not passed. We should also add a test that produces the same output in json-doc as , to avoid a regression if rustdoc starts emitting JSON files in the default HTML format.
I can't jump on it immediately, but I should be able to follow up in a couple of weeks
claim
We can do this validation for dir, but I am not sure if this is possible for dir since each time json output changes. The layout of json context is getting change even if you don't change anyhing on the source code. I print sha2 sums below to demonstrate the situation. 1st attempt: 2nd attempt right after the first attempt The demonstration is from
thanks for investigating; sounds like we should report that as a separate bug in rustdoc. But for now it's ok if the files don't match exactly as long as the file names are the same between runs.
Change:
} } <ins> impl From<hir::PrimTy> for PrimitiveType { fn from(prim_ty: hir::PrimTy) -> PrimitiveType { match prim_ty { hir::PrimTy::Int(int_ty) => int_ty.into(), hir::PrimTy::Uint(uint_ty) => uint_ty.into(), hir::PrimTy::Float(float_ty) => float_ty.into(), hir::PrimTy::Str => PrimitiveType::Str, hir::PrimTy::Bool => PrimitiveType::Bool, hir::PrimTy::Char => PrimitiveType::Char, } } } </ins> #[derive(Clone, PartialEq, Eq, Debug)] pub enum Visibility { Public,

Discussion:
When re-exporting a primitive type, rustdoc ICEs. This was found when creating . Rustdoc also fails to link the re-export to the primitive docs. Reproduction: commands: Backtrace:
I plan on investigating this issue tomorrow, as it is likely a blocker for
-- this is blocking , and I was unable to come up with a simple patch to fix this. Is this a known-hard problem, or should I try to keep digging? contains my initial patch, but it fails tests (e.g., auto impls for primitives, among other problems).
I'll try to take a look shortly. And no, never heard of it before you opened this issue. Don't hesitate to ping me if I forget.
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. // Don't fail if we encounter a NonZero<*T> where T is an unsized type #![feature(unique)] use std::ptr::Unique; fn main() { let mut a = [0u8; 5]; let b: Option<Unique<[u8]>> = unsafe { Some(Unique::new(&mut a)) }; match b { Some(_) => println!("Got `Some`"), None => panic!("Unexpected `None`"), } } </ins>

Discussion:
Given the following code: Rustc bails out on an LLVM assertion: Here's the stack: And here's the vitals: Playpen link that also fails on 2015-03-16:
/cc
Change:
use std::process::Command; use test::ColorConfig; use util::logv; <ins> use walkdir::WalkDir; </ins> use self::header::{EarlyProps, Ignore};

Discussion:
If I modify a file in the rustc source code (), is smart enough to rerun all tests. However, if I modify something in , then still ignores the tests that completed successfully in the previous run. Steps to reproduce: tests: . For example, replace the function in  with: tests again: Expected output: some tests fail. Actual output:
I would be interested in fixing this issue myself if someone could give me some guidance on how to do that. The main thing that I do not understand is how understands that was changed. It seems that it does not use files for this because they include only the hash of the configuration options which do not include version. cc
The most likely culprit (that ignores the test files) is in module. It is called from and will set the flag for the test depending on its output.
That being said, I find it hard to see how to adjust compiletest itself to take the dependencies into account. rustbuild should probably have some sort of dependency edge and delete the stamp files if/when stuff like compiletest changes.
Compiletest source code has only 9 files. Would it be acceptable to check that their timestamps are newer than the timestamp of the stamp file? PR:
Change:
Applicability::MaybeIncorrect, )), ) <del> } else if !ident.is_reserved() { (format!("maybe a missing crate `{}`?", ident), None) </del> } else { <del> // the parser will already have complained about the keyword being used return PathResult::NonModule(PartialRes::new(Res::Err)); </del> <ins> (format!("maybe a missing crate `{}`?", ident), None) </ins> } } else if i == 0 { (format!("use of undeclared type or module `{}`", ident), None)

Discussion:
Example: Found by crater run (https://crater-) when visibility resolution switched to a different algorithm (early resolution), which doesn't have this problem.
This is a regression from Rust 1.33.
Diagnostic improvements strike again:
Fixed in
Change:
mut bx: Bx, ) { if self.fn_ty.c_variadic { <del> if let Some(va_list) = self.va_list_ref { bx.va_end(va_list.llval); </del> <ins> match self.va_list_ref { Some(va_list) => { bx.va_end(va_list.llval); } None => { bug!("C-variadic function must have a `va_list_ref`"); } </ins> } } let llval = match self.fn_ty.ret.mode {

Discussion:
This example prints when compiled and run in debug mode: Compiling and running in release mode causes a segfault in  because is nul. Enabling debug info in release mode via makes the segfault go away.
thanks for reporting this. The example should probably look more like the following. The example still segfaults (even in debug mode). If is used in the function the issue does not happen. Essentially we're optimizing to the following Note the missing and . I think this is happening because we're hitting . I'll do some more investigation shortly.
the code I list in the above example should work after is merged.
Change:
let id = id.expect_local(); let tables = tcx.typeck(id); let hir_id = tcx.hir().local_def_id_to_hir_id(id); <del> let (span, place) = &tables.closure_kind_origins()[hir_id]; let reason = if let PlaceBase::Upvar(upvar_id) = place.base { let upvar = ty::place_to_string_for_capture(tcx, place); match tables.upvar_capture(upvar_id) { ty::UpvarCapture::ByRef(ty::UpvarBorrow { kind: ty::BorrowKind::MutBorrow | ty::BorrowKind::UniqueImmBorrow, .. }) => { format!("mutable borrow of `{}`", upvar) } ty::UpvarCapture::ByValue(_) => { format!("possible mutation of `{}`", upvar) </del> <ins> if let Some((span, place)) = tables.closure_kind_origins().get(hir_id) { let reason = if let PlaceBase::Upvar(upvar_id) = place.base { let upvar = ty::place_to_string_for_capture(tcx, place); match tables.upvar_capture(upvar_id) { ty::UpvarCapture::ByRef(ty::UpvarBorrow { kind: ty::BorrowKind::MutBorrow | ty::BorrowKind::UniqueImmBorrow, .. }) => { format!("mutable borrow of `{}`", upvar) } ty::UpvarCapture::ByValue(_) => { format!("possible mutation of `{}`", upvar) } val => bug!("upvar `{}` borrowed, but not mutably: {:?}", upvar, val), </ins> } <del> val => bug!("upvar `{}` borrowed, but not mutably: {:?}", upvar, val), } } else { bug!("not an upvar") }; err.span_label( *span, format!( "calling `{}` requires mutable binding due to {}", self.describe_place(the_place_err).unwrap(), reason ), ); </del> <ins> } else { bug!("not an upvar") }; err.span_label( *span, format!( "calling `{}` requires mutable binding due to {}", self.describe_place(the_place_err).unwrap(), reason ), ); } </ins> } // Attempt to search similar mutable associated items for suggestion.

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
This regressed in 1.51 according to the playground
searched nightlies: from nightly-2020-12-15 to nightly-2021-02-01 regressed nightly: nightly-2021-01-30 searched commits: from to regressed commit: Regressed in
Most likely due to , cc
Assigning and removing as in the prioritization working group.
Change:
let param_env = tcx.param_env(def.did); let last_field = def.variants[v].fields.last().unwrap(); let always_sized = tcx.type_of(last_field.did) <del> .is_sized(tcx, param_env, DUMMY_SP); </del> <ins> .is_sized(tcx.at(DUMMY_SP), param_env); </ins> if !always_sized { StructKind::MaybeUnsized } else { StructKind::AlwaysSized } };

Discussion:
One example is the method on . Internally it creates a , when it could simply be taking exactly that as an argument. In miri I had to write which just feels a little riddiculous (taking apart the , just to have the method construct it back). There's probably many other similar methods and functions that should be taking a
Can I take this one if no one is working on that ?
it's all yours!
Change:
warning: variable does not need to be mutable --> $DIR/suggestions.rs:59:13 | <del> LL |         let mut a = (1); |             ----^ </del> <ins> LL |         let mut registry_no = (format!("NX-{}", 74205)); |             ----^^^^^^^^^^^ </ins> |             | |             help: remove this `mut` |

Discussion:
This code snippet () results in the following lint output: The should contain the literal string , not the expanded macro that it repreesnts.
Ah, I think this is because we should be using (to get the code the user actually wrote) (to render the AST); I could PR this tonight.
Change:
LL |     x.push(y); //~ ERROR explicit lifetime required |            ^ <del> error[E0282]: type annotations needed --> $DIR/ex2a-push-one-existing-name-early-bound.rs:20:9 </del> <ins> error[E0621]: explicit lifetime required in the type of `y` --> $DIR/ex2a-push-one-existing-name-early-bound.rs:17:5 </ins> | <del> LL | let x = baz; |     -   ^^^ cannot infer type for `T` |     | |     consider giving `x` a type </del> <ins> LL | fn baz<'a, 'b, T>(x: &mut Vec<&'a T>, y: &T) |                                          -- help: add explicit lifetime `'a` to the type of `y`: `&'a T` ... LL |     x.push(y); //~ ERROR explicit lifetime required |     ^^^^^^^^^ lifetime `'a` required </ins> error: aborting due to previous error <del> For more information about this error, try `rustc --explain E0282`. </del> <ins> For more information about this error, try `rustc --explain E0621`. </ins>

Discussion:
Look at its expected error output is () but under NLL it yields (): The latter is amazingly different from the former.
Hmm. We actually do try to give the nicer errors, but for whatever reason the heuristics we use to decide what is the "main error" to report are failing here. Seems like an interesting case to dig into a bit.
But I'll mark it as a sub-issue of
OK so -- the problem here I think is the TEST. In particular, the line serves no purpose. It does however cause typeck to fail and hence we never get to MIR borrowck. If you remove that line and enable , we get the same error message.
Change:
<ins> // Copyright 2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. use std::mem; struct Foo<T: ?Sized> { a: i64, b: bool, c: T, } fn main() { let foo: &Foo<i32> = &Foo { a: 1, b: false, c: 2i32 }; let foo_unsized: &Foo<Send> = foo; assert_eq!(mem::size_of_val(foo), mem::size_of_val(foo_unsized)); } </ins>

Discussion:
On stable, beta, and nightly, the follow code prints followed by : CC
This is probably for drop flags, in which case it should get fixed by
Reduced:
where would there be a drop flag here?
My point isn't that there is, but that the code assumes all trait objects have drop flags. I could be wrong though, it might be a bug in the alignment logic.
Not fixed by , will have to investigate further.
Uhhhh, the computation starts with: Which is completely wrong, because you want no trailing padding, i.e. should be . EDIT: getting a field pointer might also be broken, needs looking into. EDIT2: to handle the "minimum size" needed to compute the field offset, so that works.
Change:
let ccx = bcx.ccx(); let ty = Type::at_box(ccx, type_of(ccx, body_t)); let boxptr = PointerCast(bcx, boxptr, ty.ptr_to()); <del> GEPi(bcx, boxptr, &[0u, abi::box_field_body]) </del> <ins> GEPi(bcx, boxptr, &[0u, abi::BOX_FIELD_BODY]) </ins> } fn require_alloc_fn<'blk, 'tcx>(bcx: Block<'blk, 'tcx>,

Discussion:
There are three versions of these layouts for functions, traits, and slices, but the compiler relies on these being the same. We should replace them with a single layout: and or something. While we're at it, we should probably find uses of len/length names in the DST code and replace it with something more generic.
I merged the constants. Could you elaborate on the length names? Are there more constants like these?
What still needs to be done here, if anything?
Looks done.
Change:
<ins> // revisions: rpass1 rpass2 // edition:2021 // See https://github.com/rust-lang/rust/issues/98890 #![allow(unused)] struct Foo; impl Foo { async fn f(&self, _: &&()) -> &() { &() } } #[cfg(rpass2)] enum Bar {} fn main() {} </ins>

Discussion:
The following diff: if done in between s, makes the second check fail with: Aside: that error is printed twice, which is also curious. To reproduce, the following snippet fails on the Playground: I've reported it over to avoid defining a duplicate issue, but now that I've noticed it's a regression, I prefer to risk it being a dup than it going unnoticed. I've also mentioned this over: https://rust- This is causing major breakage with users of who have switched to Rust or up, as showcased by: modify labels: +regression-from-stable-to-stable -regression-untriaged
The bug also reproduces when the is above the impl, but only when that does not change the spans of the impl. It also reproduces when the is add in a different file, or when a or an is instead. This suggests to me that this is somehow related to the overall set of DefIds changing. It does not reproduce when the function is non-async. any ideas? Where there any big refactorings during that time frame that could be the cause of this?
Maybe something related to generators / async functions generates numeric IDs based raw DefIndex values which are then not hashed in a stable way?
Bisection seems to point to
That does sound related. might have an idea.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Let's keep this open until the backporting situation of the fix is clarified.
was backported to 1.63.0-beta in -- ready to close?
Is this worth a stable backport? The experience of developing async code with this issue isn’t great.
I tried a stable backport locally just to see, but it's non-trivial -- builds on changes from and at least, but that's as far as I investigated before giving up. Maybe a more targeted fix for 1.62.0 could be developed though.
Backported to stable.