jiebi/CodeConvo huggingface dataset:
Change:
# Is any part of this thing production-ready? <del> No. Feel free to play around, but don't expect completeness or stability yet. Expect incompleteness and breakage. </del> <ins> Yes! </ins> # Is this a completely Mozilla-planned and orchestrated thing?

Discussion:
The above link states that rust is not production ready. Is this a mistake?
I wonder how many people read this FAQ after 1.0 :fearful:
Well, we're hoping to re-do the FAQ: (I'll send a PR to fix this in the meantime though, nice catch!)
I see that this was merged. But, the website still says the same thing, that Rust isn't production-ready. I think the issue should be re-opened until the website is actually updated. This is an important issue as far as advocacy and community-building goes.
They've already made their way to beta, and so will be part of stable as of the next release. The docs are part of the release, we'd have to cut a 1.5.1 to update this.
OK, thanks for clarifying that. I think it's reasonable to let it ride until 1.5 is released.
Change:
/// There may be multiple cycles involved in a deadlock, so this searches /// all active queries for cycles before finally resuming all the waiters at once. #[cfg(parallel_compiler)] <del> pub fn deadlock(query_map: QueryMap, registry: &rayon_core::Registry) { let on_panic = defer(|| { eprintln!("deadlock handler panicked, aborting process"); process::abort(); }); </del> <ins> pub fn break_query_cycles(query_map: QueryMap, registry: &rayon_core::Registry) { </ins> let mut wakelist = Vec::new(); let mut jobs: Vec<QueryJobId> = query_map.keys().cloned().collect();

Discussion:
I noticed that when parallel rustc panics due to deadlock, it would say instead of . Is this intended?
Hm, I did recently land but I'm not sure if it would cause this issue. It should only affect threads that Rust doesn't create itself and in any case it switches the default name from (which gets rendered as ) to the OS thread name (if available). So if anything I'd have thought it would have the opposite effect. Though maybe there's something about parallel's deadlocks I'm missing.
I think you're good since the problem is older than your pr :D
Oh good! I mean bad, but I was dreading a very long debugging session
well, if you feel bored or something.... :upsidedownface:
Serial rustc creates a single thread called rustc. I assume parallel rustc just doesn't name its rayon threads, no debugging session ahead.
We create a new thread to look for query cycles, it's unnamed at the moment and that's where the panic happens.
Change:
<ins> // Regression test for issue #89485. // run-pass #[derive(Debug, Eq, PartialEq)] pub enum Type { A = 1, B = 2, } pub fn encode(v: Type) -> Type { match v { Type::A => Type::B, _ => v, } } fn main() { assert_eq!(Type::B, encode(Type::A)); } </ins>

Discussion:
Originally found by when experimenting with discriminants starting from 1 in modify labels: +regression-from-stable-to-stable +I-unsound
After a quick it appears that the regression appear with Rust 1.48.0
A bisection seems to lead to , nightly 2020-09-26 from to
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
Looks like it is mostly likely caused by which is supposed to cc
Change:
<ins> error[E0424]: expected value, found module `self` --> $DIR/missing-self-diag.rs:10:9 | LL |           self.bar(); |           ^^^^ `self` value is a keyword only available in methods with a `self` parameter ... LL | /     pub fn foo(&self) { LL | |         call_bar!(); | |         ------------ in this macro invocation LL | |     } | |_____- this function has a `self` parameter, but a macro invocation can only access identifiers it receives from parameters | = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to previous error For more information about this error, try `rustc --explain E0424`. </ins>

Discussion:
Hi, ... returns: () Message says , even though it does have a parameter, which is kinda confusing. This happens only on beta and nightly, since current stable doesn't provide that hint at all. Thanks, Patryk.
This happened to me on an old nightly (I believe 1.38.0 when it was still nightly, I may be wrong)
Running into this issue on latest stable as well. What is the actual problem?
I just ran into what appears to be the same issue on , in the context of a trait method.
Change:
&mut this.cx.borrowck_context.constraints.outlives_constraints, &mut constraints, ); <ins> mem::swap(&mut this.cx.borrowck_context.constraints.type_tests, &mut type_tests); </ins> mem::swap( &mut this.cx.borrowck_context.constraints.closure_bounds_mapping, &mut closure_bounds,

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. --: (latest nightly as of today) </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label: +F-inline_const
Note the missing bound. requires , and should throw a lifetime bounds error, but I think the inline const block is tripping something up. It works fine if you require or without the inline const block.
claim
Change:
fn bar(self) -> Arc<String> { Arc::new(String::new()) } } <ins> fn generic(f: impl Foo) { let x = &*f.bar(); } </ins> fn main() { // Witness an RPITIT from another crate. let &() = Foreign.bar();

Discussion:
I tried this code: Compiled fine with , but gives the following error with : My initial attempt at minimizing the case shown that the single-crate equivalent: compiles just fine. : EDIT: Reduced reproduction code. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
(This is a issue that is fixed under and ). cc a nice test case to add.
Why do you think this is a limitation of the current lowering? This should definitely work with the current lowering and ideally shouldn't be dependent on . This is just a plain bug claim
The reason: incorrect eyeballing + complete ignorance of the subject matter, AKA saying stupid things . Even better it it's fixable without requiring the new lowering.
This regressed in , cc I will fix this, but I hope that PR doesn't also regress other things, like the last time the encoding for certain items was reduced without sufficient tests :/
Change:
python3 "$X_PY" test --stage 2 src/tools/rustfmt python3 "$X_PY" test --stage 2 src/tools/miri # We natively run this script on x86_64-unknown-linux-gnu and x86_64-pc-windows-msvc. <del> # Also cover some other targets (on both of these hosts) via cross-testing. </del> <ins> # Also cover some other targets via cross-testing, in particular all tier 1 targets. </ins> export BOOTSTRAP_SKIP_TARGET_SANITY=1 # we don't need `cc` for these targets <del> python3 "$X_PY" test --stage 2 src/tools/miri --target i686-pc-windows-msvc python3 "$X_PY" test --stage 2 src/tools/miri --target aarch64-apple-darwin </del> <ins> case $HOST_TARGET in x86_64-unknown-linux-gnu) # Only this branch runs in PR CI. # Fully test all main OSes, including a 32bit target. python3 "$X_PY" test --stage 2 src/tools/miri --target x86_64-apple-darwin python3 "$X_PY" test --stage 2 src/tools/miri --target i686-pc-windows-msvc # Only run "pass" tests for the remaining targets, which is quite a bit faster. python3 "$X_PY" test --stage 2 src/tools/miri --target x86_64-pc-windows-gnu --test-args pass python3 "$X_PY" test --stage 2 src/tools/miri --target i686-unknown-linux-gnu --test-args pass python3 "$X_PY" test --stage 2 src/tools/miri --target aarch64-unknown-linux-gnu --test-args pass python3 "$X_PY" test --stage 2 src/tools/miri --target s390x-unknown-linux-gnu --test-args pass ;; x86_64-pc-windows-msvc) # Strangely, Linux targets do not work here. cargo always says # "error: cannot produce cdylib for ... as the target ... does not support these crate types". # Only run "pass" tests, which is quite a bit faster. python3 "$X_PY" test --stage 2 src/tools/miri --target aarch64-apple-darwin --test-args pass python3 "$X_PY" test --stage 2 src/tools/miri --target i686-pc-windows-gnu --test-args pass ;; *) echo "FATAL: unexpected host $HOST_TARGET" exit 1 ;; esac </ins> unset BOOTSTRAP_SKIP_TARGET_SANITY

Discussion:
We currently run Miri on tests a few select targets: However, that's not all tier 1 targets, so e.g. x8664-apple-darwin is not covered, and today's nightly contains a Miri where some APIs are broken on x8664-apple-darwin. It'd be great if we could run (some) Miri tests on all tier 1 targets. Note that Miri tests can be run on any host so this does not require running on more hosts. However we'd probably not want to test all targets on all hosts, so we need some way in to determine which host we are on, and spread the test jobs across the hosts. Also, depending on how tight our time budget is here, we might want to not run all tests -- just running the "pass" tests should generally be sufficient and can save a bunch of time. Cc -- in particular, (a) how can I check for the host in , and (b) how tight is our time budget for the "tools" builders?
Change:
extern crate serde_json; extern crate test; extern crate rustfix; <ins> extern crate walkdir; </ins> use common::CompareMode; use common::{expected_output_path, output_base_dir, output_relative_path, UI_EXTENSIONS};

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:
<ins> // force-host // no-prefer-dynamic #![crate_type = "proc-macro"] //#![feature(proc_macro_diagnostic, proc_macro_span, proc_macro_def_site)] extern crate proc_macro; use proc_macro::{Delimiter, Group, Ident, Punct, Spacing, Span, TokenStream, TokenTree}; use std::iter::FromIterator; #[proc_macro_attribute] pub fn repro(_args: TokenStream, input: TokenStream) -> TokenStream { let call_site = Span::call_site(); let span = input.into_iter().nth(8).unwrap().span(); //fn f(_: &::std::fmt::Formatter) {} TokenStream::from_iter([ TokenTree::Ident(Ident::new("fn", call_site)), TokenTree::Ident(Ident::new("f", call_site)), TokenTree::Group(Group::new( Delimiter::Parenthesis, TokenStream::from_iter([ TokenTree::Ident(Ident::new("_", call_site)), TokenTree::Punct(punct(':', Spacing::Alone, call_site)), TokenTree::Punct(punct('&', Spacing::Alone, call_site)), TokenTree::Punct(punct(':', Spacing::Joint, span)), TokenTree::Punct(punct(':', Spacing::Alone, span)), TokenTree::Ident(Ident::new("std", span)), TokenTree::Punct(punct(':', Spacing::Joint, span)), TokenTree::Punct(punct(':', Spacing::Alone, span)), TokenTree::Ident(Ident::new("fmt", span)), TokenTree::Punct(punct(':', Spacing::Joint, span)), TokenTree::Punct(punct(':', Spacing::Alone, span)), TokenTree::Ident(Ident::new("Formatter", span)), ]), )), TokenTree::Group(Group::new(Delimiter::Brace, TokenStream::new())), ]) } fn punct(ch: char, spacing: Spacing, span: Span) -> Punct { let mut punct = Punct::new(ch, spacing); punct.set_span(span); punct } </ins>

Discussion:
<details<summary<strongBacktrace</strong</summary<p</p</details
This bisects to &mdash; regressed nightly: nightly-2021-12-03 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
There was an issue with similar ICE that has been fixed recently Does this problem still repro with latest nightly ?
Yes this one still reproduces as of that nightly, which contains .
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Change:
// Be conservative about the returned value of a const fn. let tcx = self.tcx; let ty = dest.ty(self.mir, tcx).to_ty(tcx); <del> self.qualif = Qualif::empty(); </del> <ins> if is_const_fn && !is_promotable_const_fn && self.mode == Mode::Fn { self.qualif = Qualif::NOT_PROMOTABLE; } else { self.qualif = Qualif::empty(); } </ins> self.add_type(ty); } self.assign(dest, location);

Discussion:
: produces cc
Not that this fixes the issue, but and aren't necessarily guaranteed to have the same representation without or on both and .
minified: is this a victim of the backwards algorithm for promotion? Just a hunch, but it might have promoted away the call to and then end up trying to promote the , but it's not in the place where it was expected, because it now lives inside the promoted. So it ends up trying to promote an argument in a basic block that was already promoted away
thanks , I'll update the PR that triggered this - for context
As a workaround until we fix this ICE, you can introduce an intermediate explicit constant for the argument to . Or is this part of a user-exposed API?
This is part of a user-exposed API, but that workaround should allow me to at least get the const tests running.
It won't remove the definition if there's more than one use (unless this is fallout from your changes?)
There's only one use. I don't see how my changes could have caused this, but it seems possible. I'll do a bisection
Oh, I see, is and that's missing a check like:
Fix instructions: Add a which, like the variable, is used to mark blocks whose terminator has been promoted out. skip promoting all such terminators when encountering said block id in a ()
You can use a , although I'm not even sure it's necessary. A promoted call ends up as a , so you could just skip it based on that?
Change:
} /// Ensure that the ABI makes basic sense. <del> fn fn_abi_sanity_check<'tcx>(cx: &LayoutCx<'tcx, TyCtxt<'tcx>>, fn_abi: &FnAbi<'tcx, Ty<'tcx>>) { </del> <ins> fn fn_abi_sanity_check<'tcx>( cx: &LayoutCx<'tcx, TyCtxt<'tcx>>, fn_abi: &FnAbi<'tcx, Ty<'tcx>>, spec_abi: SpecAbi, ) { </ins> fn fn_arg_sanity_check<'tcx>( cx: &LayoutCx<'tcx, TyCtxt<'tcx>>, fn_abi: &FnAbi<'tcx, Ty<'tcx>>, <ins> spec_abi: SpecAbi, </ins> arg: &ArgAbi<'tcx, Ty<'tcx>>, ) { match &arg.mode {

Discussion:
Crate bytecount compilation fails with latest nightly on NanoPC-T6 (RK3588 ARM / aarch64). It worked yesterday. I tried this code: Updating index Adding bytecount v0.6.7 to dependencies. Features: generic-simd htmlreport packedsimd runtime-dispatch-simd Updating index Compiling bytecount v0.6.7 Intrinsic has incorrect return type! ptr in function ZN4core9corearch10armshared4neon9generated11vld1qu8x417hd6e0965b4ff7ff22E LLVM ERROR: Broken function found, compilation aborted! error: could not compile (lib) Compiling bytecount v0.6.7 Compiling bytecounttest v0.1.0 (/home/pi/bytecounttest) Finished dev [unoptimized + debuginfo] target(s) in 0.90s Linux NanoPC-T6 5.10.160 SMP Thu Jul 20 15:53:55 CST 2023 aarch64 aarch64 aarch64 GNU/Linux PRETTYNAME="Ubuntu 22.04.3 LTS" NAME="Ubuntu" VERSIONID="22.04" VERSION="22.04.3 LTS (Jammy Jellyfish)" VERSIONCODENAME=jammy ID=ubuntu IDLIKE=debian HOMEURL="" SUPPORTURL="" BUGREPORTURL="" PRIVACYPOLICYURL="" UBUNTUCODENAME=jammy I expected to see this happen: Finished dev [unoptimized + debuginfo] target(s) in 1.32s Instead, this happened: LLVM ERROR: Broken function found, compilation aborted!
searched nightlies: from nightly-2023-11-19 to nightly-2023-11-20 regressed nightly: nightly-2023-11-20 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: aarch64-unknown-linux-gnu Reproduce with: </detailslooks like something in that PR changed ABI behavior and now LLVM and rustc disagree. Don't know who's wrong.
Hm, I don't know how that "unadjusted" ABI stuff works...
should fix this. I am not sure how to add a test.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Change:
LL |     let _: for<'a> fn(<() as Foo<T>>::Type<'a>, &'a T) = |_, _| (); |                                                          ^^^^^^^^^ <ins> error[E0310]: the parameter type `T` may not live long enough --> $DIR/issue-91139.rs:16:58 | LL |     let _: for<'a> fn(<() as Foo<T>>::Type<'a>, &'a T) = |_, _| (); |                                                          ^^^^^^^^^ ...so that the type `T` will meet its required lifetime bounds | help: consider adding an explicit lifetime bound... | LL | fn foo<T: 'static>() { |         +++++++++ </ins> error: `T` does not live long enough --> $DIR/issue-91139.rs:16:58 |

Discussion:
This code compiles after although it shouldn't: () This is similar to in that we're not taking into account placeholder regions when "promoting" type-tests from the closure to its caller: label T-types regression-from-stable-to-beta C-bug A-NLL I-unsound <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I guess it would be an easy fix claim
The unsoundness exploitation in can easily be adapted for this issue, so it is in fact a soundness issue:
issue touched in today's T-compiler meeting, . Will also be discussed tomorrow during the T-types meeting.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Change:
sub: Region, sup: Region) -> Option<FreeRegionsFromSameFn> { <ins> debug!("free_regions_from_same_fn(sub={:?}, sup={:?})", sub, sup); </ins> let (scope_id, fr1, fr2) = match (sub, sup) { (ReFree(fr1), ReFree(fr2)) => { if fr1.scope_id != fr2.scope_id {

Discussion:
For the input file below, the two distinct invocations of (but with identical arguments) are non-deterministically deciding whether or not to prompt with the "consider using an explicit lifetime parameter" hint. Input file (): Transcript: (See also for a problem with the suggestion actually provided by when it chooses to actually provide one.)
I tested it a bit, and the issue seems to be is fed slightly different information each time. In the first case we have a and in the second . In the constraint graph for some node we are trying to infer, there are multiple incoming edges and outgoing edges to and from . From my understanding the compiler only picks one node from these incoming edges and one node from these outgoing edges, and it doesn't pick the same pair each time (what I don't understand is why I didn't see the and variations).
I'm getting a non-deterministic error message using the latest nightlies: It's non-deterministic on my Fedora 20 machine but not my OSX machine.
Change:
use iter::{self, Iterator, ExactSizeIterator, IntoIterator, IteratorExt, FromIterator, Extend, Map}; use marker::Sized; use mem::{self, replace}; <del> use ops::{Deref, FnMut, Index, IndexMut}; </del> <ins> use ops::{Deref, FnMut, Index}; </ins> use option::Option::{self, Some, None}; use rand::{self, Rng}; use result::Result::{self, Ok, Err};

Discussion:
I believe we intend to eventually extend the index traits with the ability to override the syntax specifically using a trait like . This would allow hashmaps to be used like and have that insert the key, unlike today where will panic if is not already present. To pave the way, the simplest thing is to remove the operator from those collections where we would anticipate growing on demand. I believe that would be , , and possible and . Thoughts? cc
triage: P-backcompat-libs I-needs-decision (1.0 beta)
triage: P-backcompat-libs (1.0 beta)
I was just starting to prep a PR to resolve this by removing the impl, as you suggested. :)
Don't we want to keep the implementation on for example to do something like ?
Depending on the exact way that is done, it may not be possible to provide both modes of use. That is, we want to be able to write -- which we cannot today -- but it's not clear that you can do that and also support examples like the one you gave. In particular, that involves adjusting inference to determine whether or not a deref is in play. For now, removing these impls will give us the most freedom when we do incorporate .
It seems weird to have this and insert -- insert has a return value, though. This would be a super-annoying ergonomic regression in the interim. What's the expected timeline for something like IndexSet? 1.1?
Oh actually upon reflection most usages I know are Index, not IndexMut. Not as awful a regression.
It should be possible to move in, out, and take references with the operator. If that's not possible with the current design then the current design has to be changed instead of committing to yet another subpar design until 2.0.
sounds powerful and interesting, is there any RFC for it now?
It feels odd that does not support . I don't buy the argument that would be confused with - no other container supports insertion via the syntax. Now if you would add some hypothetical and support insertion into a via , then someone would just get confused that they can't use to insert into a .. (doesn't really makes sense, but what if entries are default constructible!) Not even talking about the pandora box of accidentally inserting elements into the container. Imho we should keep consistent as an accessor to get references to data already existing in the container.
Change:
}); } <ins> #[instrument(level = "debug", skip(self, infcx, errors_buffer))] </ins> fn check_member_constraints( &self, infcx: &InferCtxt<'tcx>,

Discussion:
This code should pass but it doesn't: This is resurrected. Cc label F-typealiasimpl_trait C-bug T-compiler T-types
Oh heh, I fixed the situation for registering the hidden type but didn't allow implying anything from that.
Change:
"f32" }; match expr.node { <del> hir::ExprLit(_) => {  // numeric literal let snippet = tcx.sess.codemap().span_to_snippet(expr.span) </del> <ins> hir::ExprLit(ref lit) => {  // numeric literal let snippet = tcx.sess.codemap().span_to_snippet(lit.span) </ins> .unwrap_or("<numeric literal>".to_string()); <del> // FIXME: use the literal for missing snippet err.span_suggestion(expr.span, </del> <ins> err.span_suggestion(lit.span, </ins> &format!("you must specify a concrete type for  this numeric value, like `{}`", concrete_type),

Discussion:
Please note the
The literal's span should point inside the parenthesis. Probably needs a change to in .
I'm interested in working on this.
feel free to reach out for any help you might need! I believe that you should verify if changing the span being used in the AST for literals changes the suggestion output. If it doesn't, it means that the problem is not at the parser level, but when lowering to HIR. If that is the case, we need to dig deeper, but I'll be here to help you with that.