jiebi/CodeConvo huggingface dataset:
Change:
| LL | fn f_copy<T: Copy>(t: T) {} |              ^^^^ required by this bound in `f_copy` <ins> help: consider removing this method call, as the receiver has type `&'static str` and `&'static str: Copy` trivially holds | LL -     f_copy("".to_string()); LL +     f_copy(""); | </ins> error[E0277]: the trait bound `S: Clone` is not satisfied --> $DIR/issue-84973-blacklist.rs:16:13

Discussion:
When calling in a fn that expects we currently emit: We should check whether and suggest the removal of the call. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
feel free to reach out either on this ticket or on a PR, but be warned that this has the potential to be quite involved. It is a great introduction to how some parts of fit together though.
I've been looking into this for a while now, and my idea was to: Check if there a .into() call, check if the type of self was T and finally check if the argument of the function was Into<T. However I cannot figure how to get the type of Self. As far as my understanding goes, rustc hasn't yet inferred the type.
You can query the in-progress type table with the for the expression. You're gonna have an with a . From the first argument in that variant you can take the first element and get the expression for in . Then you can use the for that expression to do I do not know if we will have populated 's type by then, but if we have, then that will give you the type of . Then, if you're in an you can use to see if the inferred type for can be coerced to in the original example. I know this is a bit vague, but for this is inherently exploratory work :)
Hi, are you still working on this issue
No, feel free to claim it if you want
release-assignment
Change:
}; } <del> let filtered_out = tests_len - filtered.tests.len(); </del> <ins> let filtered_out = tests_len - filtered.total_len(); </ins> let event = TestEvent::TeFilteredOut(filtered_out); notify_about_test_event(event)?; let shuffle_seed = get_shuffle_seed(opts); <del> let event = TestEvent::TeFiltered(filtered.tests.len(), shuffle_seed); </del> <ins> let event = TestEvent::TeFiltered(filtered.total_len(), shuffle_seed); </ins> notify_about_test_event(event)?; let concurrency = opts.test_threads.unwrap_or_else(get_concurrency);

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 running benchmarks with current nightly rust: Running with the previous nightly works: Also, note the difference in the line . This happens for the benchmarks in both the and crates. looks to be related ( <!-- 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<summaryBacktrace</summary<p</p</details
Ouch. I guess libtest needs better tests. I might be able to get to this in 12 hours or so, if anyone else sees this please do take care of it.
Oof, missed that started as the full list of tests+benches before getting shadowed as only the tests. Not a fan of the way TestEvent is used to manage state (haven't ever been a fan of it, TBH), but I'll have to think a bit about how to fix it without undoing the perf wins we just got here.
Confirm the bug as well: started to fail after changing the toolset to the current nighly.
Yeah, should be fixed by . Hopefully will be in the next nightly, if we're lucky.
Change:
}; if let Some(path) = path <del> && let Ok(mut out) = crate::fs::File::options().create(true).write(true).open(&path) </del> <ins> && let Ok(mut out) = crate::fs::File::options().create(true).append(true).open(&path) </ins> { write(&mut out, BacktraceStyle::full()); }

Discussion:
Sometimes when rustc dumps an ICE backtrace to disk, the file only contains I have yet to find what actual file/ice causes this, its a bit tricky since there is no mapping from ice file to the actual .rs that was used to cause the ICE. cc
Is this from a test case in the suite that's ICEing? I would like to try and reproduce this.
It looks like this is related to panics that happen during panics: With that file and the listed flags, you will get 3 stacktraces in stderr, but only one in the file:
The original finding was from one of the files in :sweat_smile:
That actually makes sense to me, I'll have to dig into it, but it sounds like it might be straightforward to fix. Edit: wait, re your last comment, did this new machinery regressed a previously fixed ICE, or is it an expected ICE that the new machinery didn't handle gracefully?
nono, not that I know, the directory is just full of files where plain does not crash anymore, but icemaker can use spicy -Z flags or different executables like rustdoc, rustfmt, clippy, miri, kani, cranelift that cause ices even in the directory :)
This happens exclusively for because they have their own machinery to print their own (more useful) backtrace. Looking into it.
Hm, I also just noticed, when for example clippy panics (you can force that with a delayspanbug attr), we also generate an empty file :/ ` repro
I believe that fixes the situation for all cases detected, both delayed span bugs and panic during panic.
Change:
<del> // issue: 113981 pub fn main() {} </del>

Discussion:
Running on my checkout with the current master commit fails with tons of errors. here's the last few screens of messages:
Is the check looking for in the full path? My rustc checkout is in a directory called (it's my 2nd of 3 checkouts), and I suspect tidy gets confused by that.
It does CC
That code should probably use .
Oops, I will try to fix this ASAP
Submitted a fix for this at .
Change:
extern crate test; #[cfg(test)] #[rustc_test_marker = "z_test"] <ins> #[doc(hidden)] </ins> pub const z_test: test::TestDescAndFn = test::TestDescAndFn { desc: test::TestDesc {

Discussion:
I tried this code: I expected to see this happen: no errors Instead, this happened: : Very likely to be related
Looks like allowed missing docs on the generated function, but didn't test having any actual s. cc
Attempt fix in
Change:
<ins> // build-pass #![crate_type = "lib"] #![allow(unconditional_panic)] struct S(u8); pub fn ice() { S([][0]); } </ins>

Discussion:
When compiling () with the command I receive the following ICE: reports:
The error reproduces on Travis: https://travis-
Minimal changes needed to trigger / prevent ICE: (no ICE) (ICE)
It would be great if someone could test this on a recent rustc and if it still fails, try to minimize it
I had to to make it "compile" again, but I still get an ICE with a recent :
Awesome! thanks for the quick work.
Do you think you could reduce this further?
I just tried to reproduce this once more with and instead of an ICE it now produces multiple compilation errors, such as: This pretty much seems to "prevent" how I could previously ICE it, enabling or disabling macro invocations with an empty array that then got accessed: Seems like this got fixed. On a side note, I'm positively surprised it detects this will panic at runtime, although one could make the argument that maybe I wanted that macro expansion to panic inside a unit test, and therefore emitting a compilation error is too strong. (Update) Hm, strangely enough, the error generation is only triggered when running , not when running (even if I move the invalid array access into the main library). It still doesn't ICE, but it also doesn't produce the errors.
Cool; ideally, if we could create a minimal example that we could add as a regression test that would be great, and if not, then I guess we'll close the issue as it no longer ICEs.
Alright, here is the MVP that would do it: When I run this with on it would ICE as above; with the latest it just gives an error.
Thanks, cc
Change:
} } ty::Error(_) => ControlFlow::Break(OrphanCheckEarlyExit::LocalTy(ty)), <del> ty::Opaque(..) | ty::Closure(..) | ty::Generator(..) | ty::GeneratorWitness(..) => { </del> <ins> ty::Closure(..) | ty::Generator(..) | ty::GeneratorWitness(..) => { </ins> self.tcx.sess.delay_span_bug( DUMMY_SP, format!("ty_is_local invoked on closure or generator: {:?}", ty), ); ControlFlow::Break(OrphanCheckEarlyExit::LocalTy(ty)) } <ins> ty::Opaque(..) => { // This merits some explanation. // Normally, opaque types are not involved when performing // coherence checking, since it is illegal to directly // implement a trait on an opaque type. However, we might // end up looking at an opaque type during coherence checking // if an opaque type gets used within another type (e.g. as // the type of a field) when checking for auto trait or `Sized` // impls. This requires us to decide whether or not an opaque // type should be considered 'local' or not. // // We choose to treat all opaque types as non-local, even // those that appear within the same crate. This seems // somewhat surprising at first, but makes sense when // you consider that opaque types are supposed to hide // the underlying type *within the same crate*. When an // opaque type is used from outside the module // where it is declared, it should be impossible to observe // anything about it other than the traits that it implements. // // The alternative would be to look at the underlying type // to determine whether or not the opaque type itself should // be considered local. However, this could make it a breaking change // to switch the underlying ('defining') type from a local type // to a remote type. This would violate the rule that opaque // types should be completely opaque apart from the traits // that they implement, so we don't use this behavior. self.found_non_local_ty(ty) } </ins> }; // A bit of a hack, the `OrphanChecker` is only used to visit a `TraitRef`, so // the first type we visit is always the self type.

Discussion:
The full log is available from this link: From the aforementioned link:
Do you have a more concise way of reproducing this? I can't seem to get it to ICE when I run with , no matter if I use , etc.
nvm, should be using ..
This is actually reproducible even with . It seems to only ICE with feature. Command for reproduction: <details<summary<strongBacktrace</strong</summary<p</p</detailsWe don't use feature much, so it should be easy, to make a MRE, I'll try.
I found an MRE. I'll put up a fix in a second.
I found a MRE too :(
+1, I basically reproduced that in the UI test but manually expanding the part of the macro that causes the ICE.
Change:
builder.ensure(RustbookSrc { target, name: INTERNER.intern_string(format!("book/{}", edition)), <del> src: INTERNER.intern_path(builder.src.join(&relative_path).join(edition)), </del> <ins> src: INTERNER.intern_path(absolute_path.join(edition)), </ins> // There should only be one book that is marked as the parent for each target, so // treat the other editions as not having a parent. parent: Option::<Self>::None,

Discussion:
This might not be a valid request (I have to tell it what to test), but surely it shouldn't just result in such an obscure panic. Cc
you don't have dir ?
it doesn't exists until fetching the submodule
Seems like I don't have that submodule checked out; I don't work on the book so it's not needed (and I keep the checked-out submodules to a minimum to avoid having to update them all the time).
I reproduced it in local, without in and don't update submodule manually, will fail like this.
I can fix it tomorrow, feel free to work on it if you want to fix it earlier.
by the way, do you know why we use those for here?
Not particularly, I am not so familiar with the compiletest code. Probably we panic there so the compiletest runner process can handle(being able to understand compiletest was failed) that.
The fix shouldn't make any changes on the compiletest side. We just need to avoid using submodules(if doesn't exists) instead of assuming that they exist.
Yes, that's another issue, I just met it today.
Change:
match self.token { token::SEMI => { self.bump(); <ins> let span_with_semi = Span { lo: stmt.span.lo, hi: self.last_span.hi, expn_info: stmt.span.expn_info, }; </ins> stmts.push(@codemap::Spanned { node: StmtSemi(e, stmt_id), <del> span: stmt.span, </del> <ins> span: span_with_semi, </ins> }); } token::RBRACE => {

Discussion:
Code: Compilation attempt: It should be pointing at the semi-colon on the next line, not the comma on this line.
The note message was introduced in . It doesn't seem to handle this situation properly.
Change:
} if let Some(BranchProtection { bti, pac_ret }) = sess.opts.unstable_opts.branch_protection { <ins> let behavior = if llvm_version >= (15, 0, 0) { llvm::LLVMModFlagBehavior::Min } else { llvm::LLVMModFlagBehavior::Error }; </ins> if sess.target.arch == "aarch64" { llvm::LLVMRustAddModuleFlag( llmod, <del> llvm::LLVMModFlagBehavior::Error, </del> <ins> behavior, </ins> "branch-target-enforcement0".as_ptr().cast(), bti.into(), ); llvm::LLVMRustAddModuleFlag( llmod, <del> llvm::LLVMModFlagBehavior::Error, </del> <ins> behavior, </ins> "sign-return-address0".as_ptr().cast(), pac_ret.is_some().into(), ); let pac_opts = pac_ret.unwrap_or(PacRet { leaf: false, key: PAuthKey::A }); llvm::LLVMRustAddModuleFlag( llmod, <del> llvm::LLVMModFlagBehavior::Error, </del> <ins> behavior, </ins> "sign-return-address-all0".as_ptr().cast(), pac_opts.leaf.into(), ); llvm::LLVMRustAddModuleFlag( llmod, <del> llvm::LLVMModFlagBehavior::Error, </del> <ins> behavior, </ins> "sign-return-address-with-bkey0".as_ptr().cast(), u32::from(pac_opts.key == PAuthKey::B), );

Discussion:
Enabling on rustc (nightly-2022-08-14) doesn't generate staticlibraries or cdylib anymore. This happens after the LLVM 14 to LLVM 15 change as bisected below where LLVM-15 sets the flag only for the module being compiled. Even with this build fails as there is a module without a name that doesn't have set. Earlier in BTI works even without requiring the The way I'm reproducing this (patch attached to make this easier) is by: in : This issue persists even in the latest build <details<summary<strongBacktrace</strong</summary<p</p</details are folders generated in the and folders searched nightlies: from nightly-2022-08-12 to nightly-2022-08-14 regressed nightly: nightly-2022-08-13 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Error: Label P-high can only be set by Rust team members Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
Looks like commit is the start of this bug. Bug not reproduced by running: Other commits reverted for conflict reasons. On the project branch Commit base:
This bug only happens for release mode builds with the same which leads me to believe this unnamed module is release mode specific or this occurs due to some llvm-ir merging/optimization that doesn't happen for debug builds.
Change:
0u32 as char; // error: only `u8` can be cast as `char`, not `u32` ``` <del> As the error message indicates, only `u8` can be cast into `char`. Example: </del> <ins> `char` is a Unicode Scalar Value, an integer value from 0 to 0xD7FF and 0xE000 to 0x10FFFF. (The gap is for surrogate pairs.) Only `u8` always fits in those ranges so only `u8` may be cast to `char`. To allow larger values, use `char::from_u32`, which checks the value is valid. </ins> ``` <del> let c = 86u8 as char; // ok! assert_eq!(c, 'V'); </del> <ins> assert_eq!(86u8 as char, 'V'); // ok! assert_eq!(char::from_u32(0x3B1), Some('α')); // ok! assert_eq!(char::from_u32(0xD800), None); // not a USV. </ins> ``` For more information about casts, take a look at the Type cast section in

Discussion:
Given the following code: The current output is: This is not very clear. There are two pieces of background information the user needs here: s are Unicode scalar values, which are any integer value from 0 to 0xD7FF and 0xE000 to 0x10FFFF. Only u8 can be statically guaranteed to meet this requirement so only u8 can be cast to char. is probably what the user wants, if they are interested in non-ASCII values. The user is directed to further information available at and , neither of which explains either of those two points. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think a good improvement would be to a) Add more detail about this to b) Add a to this error that suggests are you interested in working on one or both of those? :)
claim
While I was reading the docs I noticed a minor error in : This isn't true; a USV is a Code Point within either of two ranges, not one. It's also a bit cagey about what the ranges are numerically; I don't know if this is intentional. Personally I would re-write it to the below: Would I put that in the same PR (as they're both documentation) or a new issue?
A new PR would be better.
Change:
.any(|span_label| span_label.label.is_some() && span_label.span == span) && local_visitor.found_arg_pattern.is_none() { <ins> let (kind_str, const_value) = match arg.unpack() { GenericArgKind::Type(_) => ("type", None), GenericArgKind::Const(_) => ("the value", Some(())), GenericArgKind::Lifetime(_) => bug!("unexpected lifetime"), }; // FIXME(const_generics): we would like to handle const arguments // as part of the normal diagnostics flow below, but there appear to // be subtleties in doing so, so for now we special-case const args // here. if let Some(suggestion) = const_value .and_then(|_| arg_data.parent_name.as_ref()) .map(|parent| format!("{}::<{}>", parent, arg_data.name)) { err.span_suggestion_verbose( span, "consider specifying the const argument", suggestion, Applicability::MaybeIncorrect, ); } </ins> // Avoid multiple labels pointing at `span`. err.span_label( span,

Discussion:
At the moment, we simply emit errors like: It would be good to suggest to the user how to fix this, like with uninferred type arguments.
cc
Stu over has picked this issue up.
Change:
} fn make_run(run: RunConfig<'_>) { <ins> if needs_codegen_config(&run) { return; } </ins> for &backend in &run.builder.config.rust_codegen_backends { if backend == "llvm" { continue; // Already built as part of rustc

Discussion:
I tried this code: I expected this to happen: Bootstrap builds cranelift, since I named it explicitly. Instead, this happened: Nothing, since I didn't have cranelift configured in : At a minimum, I would expect this to give an error or warning that I need to configure codegen-backends. It would be even nicer if we could treat as only controlling the defaults, instead of as a hard-off switch, like how works. That should be possible to do by looking at the we're passed. cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
The first element in codegen-backends is used as default backend. In addition even if the CodegenBackend step were to directly use the passed in paths, assembling the toolchain did still only add the backends in codegen-backends to the sysroot. Having path specifiers for one step affect another step doesn't feel right. For check builds I do agree this is an improvement. Although I personally actually use this behavior to have build all backends, not just cranelift (by enabling all in codegen-backends) It did be nice to have a replacement for this. In addition for at the very least a warning makes sense.
Does it make sense to separate cgclif and cggcc into different steps in that case? cc
That doesn't have any effect on if specifying a backend as path will add it to the sysroot.
Change:
Static(hir::Mutability), Constant, Promoted, <del> ConstProp, </del> } /// Intern `ret` and everything it references.

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 from ./src/test/ui/consts/constconstructor/const-construct- <!-- 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. --rustc @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Might be caused by That should have reduced the number of ICEs, not increased it, but who knows.^^

<!-- 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. --core reduced 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. --: repo is @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This does not reproduce with though, so it's a very recent regression.
` produces the same error it seems.
Change:
<ins> //@ run-pass //@ compile-flags: -Zmir-opt-level=5 -Zvalidate-mir #![feature(ptr_metadata)] // Regression for <https://github.com/rust-lang/rust/issues/125506>, // which failed because of SRoA would project into `DynMetadata`. trait Foo {} struct Bar; impl Foo for Bar {} fn main() { let a: *mut dyn Foo = &mut Bar; let _d = a.to_raw_parts().0 as usize; } </ins>

Discussion:
<!-- [31mICE[0m: Rustc '-Zmir-opt-level=5 -Zvalidate-mir -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'broken MIR in Item(DefId(0:8 ~ [c6e7]::main)) (after pass ScalarReplacementOfAggregates) at bb3[12]:'', 'thread 'rustc' panicked at 'broken MIR in Item(DefId(0:8 ~ [c6e7]::main)) (after pass ScalarReplacementOfAggregates) at bb3[12]:'' 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: [optimizedmir] optimizing MIR for [collectandpartitionmonoitems] collectandpartitionmonoitems -- label +F-ptrmetadata
cc
Thanks! I have a fix for this in -- I didn't know it was possible without that change. I'll pull it out to a separate PR.
Change:
<ins> pub fn f1<T>(x: T::A) {} //~^ ERROR //~^^ ERROR </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --code 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
MCVE: Assigning P-low by the same rationale as , but I expect this to be much easier to fix than the other ICEs that are outside of rustdoc proper.
No longer crashing