jiebi/CodeConvo huggingface dataset:
Change:
<ins> error[E0277]: the trait bound `&str: X` is not satisfied --> $DIR/issue-86530.rs:16:7 | LL |     z(" "); |       ^^^ the trait `X` is not implemented for `&str` | note: required by a bound in `z` --> $DIR/issue-86530.rs:10:8 | LL | fn z<T>(t: T) |    - required by a bound in this LL | where LL |     T: X, |        ^ required by this bound in `z` error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
: <details<summaryerror output</summary</details
Rust playground:
Have you been able to reproduce this ICE with the latest nightly?
Playground link is not failing, I guess it's a good sign.
No longer ICEs since

The code below will trigger an ICE on the latest nightly build This is as small as i could make it while still triggering the error <!-- 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
Also occurs on stable! Regression from 1.50 to 1.51 modify labels: -requires-nightly +regression-from-stable-to-stable
Bisected: searched nightlies: from nightly-2020-01-01 to nightly-2021-04-29 regressed nightly: nightly-2021-01-18 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsRegressed PR is , cc
See and
just because something is gated doesn't mean it can't crash on stable ;) Use the above code and try to build it on the playground or compile it with a stable compiler, it will ICE.
We briefly discussed this on . I'd revert some labels here because we think this is a nightly-only issue due to the unstable feature. The fact that it compiles and reproduces on stable is kind of misleading because it's the that allows that. Makes sense? modify labels: +requires-nightly -regression-from-stable-to-stable +P-medium
sure enough ;) but just to be clear, even without this results in an ICE on stable
Okay so this is a bit complicated. Because while this does has , is still ICEs on stable. That said, not including the feature gate doesn't ICE. Given that, I think the current labels are appropriate, except maybe . It is technically a stable to stable regression, but it requires a feature to ICE, and I'm not sure that's the spirit of what that label is intended to track.
agreed on the labels, I've got the context partially wrong here. modify labels: -requires-nightly
With this also doesn't ICE
No longer ICEs since as far as I could tell with various combinations of the new feature gates
Change:
if cx.tcx.hir().attrs(hir_id).lists(sym::doc).has_word(sym::hidden) || inherits_doc_hidden(cx.tcx, hir_id) <ins> || cx.tcx.hir().span(hir_id).in_derive_expansion() </ins> { return false; }

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: /// let f = Foo; /// I expected to see this happen: succeeds. Instead, this happened: <!-- 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. --:
searched nightlies: from nightly-2020-09-30 to nightly-2020-11-30 regressed nightly: nightly-2020-11-12 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsso probably
What is the correct option here ? Ignoring derived traits or putting default examples on the derive for those types ? The first seems hard to do but I'm maybe missing knowledge to see it done. The second means the examples won't be very relevant to the type on which they are derived. For this is not much of a problem, but for thing like I can see it confusing people.
I think rustdoc shouldn't require examples for derived traits. A possible fix is to only call in render, and use the macro span everywhere else for the purpose of lints.
Change:
self.add_outlives(r1_vid, r2_vid); } <del> GenericArgKind::Type(t1) => { </del> <ins> GenericArgKind::Type(mut t1) => { </ins> // we don't actually use this for anything, but // the `TypeOutlives` code needs an origin. let origin = infer::RelateParamBound(DUMMY_SP, t1, None); <ins> // Placeholder regions need to be converted now because it may // create new region variables, which can't be done later when // verifying these bounds. if t1.has_placeholders() { t1 = tcx.fold_regions(&t1, &mut false, |r, _| match *r { ty::RegionKind::RePlaceholder(placeholder) => { self.constraints.placeholder_region(self.infcx, placeholder) } _ => r, }); } </ins> TypeOutlives::new( &mut *self, tcx,

Discussion:
Hello, I am getting an ICE while "playing" with  MCVE can be found here: <details<summaryOriginal</summary</details<!-- 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. --: (from Playground) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
A project maintainer might want to add the label.
Reduced, no nightly features: Output on stable: ICEs on beta and nightly.
Adding a bound as suggested gives this ICE on stable: <details<summaryBacktrace</summary</detailsWhich looks like . It still gives the original ICE on beta and stable, and it looks like 's code now produces the original ICE of this issue on beta and stable. Does that make this a duplicate?
:
modify labels: -F-unboxed_closures -requires-nightly per
This is now reproducing on stable. This feels like more of a "guts of the borrow checker" kind of issue than async/await-specific, so I'm tagging with .
Assigning as and removing .
Another repro from :
Change:
let section = file.add_section( file.segment_name(StandardSegment::Data).to_vec(), b".rustc".to_vec(), <del> SectionKind::Data, </del> <ins> SectionKind::ReadOnlyData, </ins> ); <ins> match file.format() { BinaryFormat::Elf => { // Explicitly set no flags to avoid SHF_ALLOC default for data section. file.section_mut(section).flags = SectionFlags::Elf { sh_flags: 0 }; } _ => {} }; </ins> let offset = file.append_section_data(section, &compressed, 1); // For MachO and probably PE this is necessary to prevent the linker from throwing away the

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --The fuchsia nightly toolchain rolls caught a binary size regression due to commit Limiting to just binary changes in the rust repo, following the instructions here: , we can see that on average the standard library is 3.5 times larger: <details<summaryClick to expand</summary</detailsI'm currently assuming that our setting of in the config of fuchsia rust builds is what causes this to be so noticeable. The effect on fuchsia is very noticeable: The binary size increases on our debug builds are large enough to prevent the binaries from fitting on the devices we're debugging. CC modify labels: +regression-from-stable-to-nightly -regression-untriaged
The regression comes from the inclusion of the section in the dylib for the fuchsia target. This section is quite large (3.4 MB, more than twice the size of the original binary). I'm actually confused about how this was working before. Clearly we need rustc metadata to compile against libstd or any other crate. The old DSO doesn't appear to have a section for metadata, but was compiling fine. Was this being shoved in another section (and somehow much smaller)? Or was rustc finding metadata from another libstd file, perhaps the rlib? cc
The section should not be getting included in dylibs (those should use with compressed metadata). This patch wasn't supposed to change handling of at all. I must have broken something while refactoring, though I don't immediately spot what.
Or did you mean above? I just checked the from a local (non-fuchsia) build and I see a section, but not an section.
Though I see now that is marked as rather than , that's not right.
Okay, that's because the section is created with , which assigns default flags: Probably it should use a debug section like does.
Thanks for the fix! and sorry yes, I did mean .
Change:
arg: expr.to_ref(), }, }; <del> ExprKind::Cast { source: expr.to_ref() } </del> <ins> let cast_expr = Expr { temp_lifetime, ty: adjustment.target, span, kind: ExprKind::Cast { source: expr.to_ref() } }; // To ensure that both implicit and explicit coercions are // handled the same way, we insert an extra layer of indirection here. // For explicit casts (e.g. 'foo as *const T'), the source of the 'Use' // will be an ExprKind::Hair with the appropriate cast expression. Here, // we make our Use source the generated Cast from the original coercion. // // In both cases, this outer 'Use' ensures that the inner 'Cast' is handled by // as_operand, not by as_rvalue - causing the cast result to be stored in a temporary. // Ordinary, this is identical to using the cast directly as an rvalue. However, if the // source of the cast was previously borrowed as mutable, storing the cast in a // temporary gives the source a chance to expire before the cast is used. For // structs with a self-referential *mut ptr, this allows assignment to work as // expected. // // For example, consider the type 'struct Foo { field: *mut Foo }', // The method 'fn bar(&mut self) { self.field = self }' // triggers a coercion from '&mut self' to '*mut self'. In order // for the assignment to be valid, the implicit borrow // of 'self' involved in the coercion needs to end before the local // containing the '*mut T' is assigned to 'self.field' - otherwise, // we end up trying to assign to 'self.field' while we have another mutable borrow // active. // // We only need to worry about this kind of thing for coercions from refs to ptrs, // since they get rid of a borrow implicitly. ExprKind::Use { source: cast_expr.to_ref() } </ins> } Adjust::Unsize => { ExprKind::Unsize { source: expr.to_ref() }

Discussion:
In , reported several NLL errors in dependencies of the servo crate. later minimized one of those errors into : which yields: Removing feature(nll) makes the code work, so probably this is an NLL bug.
I'd like to take a look at this.
Explicitly casting to fixes the issue: My guess is that there's an issue with the automatic coercion from to . I'll investigate further.
It turns out you can remove one layer of indirection and still get the same error:
Change:
} } <del> // See https://github.com/rust-lang/rust/issues/86633 </del> <ins> struct X; trait Hey { fn from_iter(_: i32) -> Self; } impl Hey for X { fn from_iter(_: i32) -> Self { X } } struct Y<T>(T); impl Hey for Y<i32> { fn from_iter(_: i32) -> Self { Y(0) } } struct Z<T>(T); impl Hey for Z<i32> { fn from_iter(_: i32) -> Self { Z(0) } } impl std::iter::FromIterator<u32> for Z<u32> { fn from_iter<T: IntoIterator<Item = u32>>(_: T) -> Self { todo!() } } </ins> fn main() { <ins> // See https://github.com/rust-lang/rust/issues/86633 </ins> let s = S; let s2 = s.try_into(); <ins> // Check that we do not issue suggestions for types that do not implement `FromIter`. // // See https://github.com/rust-lang/rust/issues/86902 X::from_iter(1); Y::from_iter(1); Y::<i32>::from_iter(1); Z::<i32>::from_iter(1); </ins> }

Discussion:
(As I mentioned :) I tried out the migration lints on some of my own code, and ran into one false positive: A struct being used with This doesn't actually become ambiguous when FromIterator is imported, because Opt doesn't implement that. Niko :
(If we don't end up doing this, we should at least change the wording to say instead of .)
Which exact function on which type do you mean? Do you have some pointers here?
Maybe Niko meant evaluate-obligation ?
Okay I have an implementation that uh.. compiles. And seems to work, maybe? (:
Change:
<ins> error: literal out of range for `u8` --> $DIR/range-pattern-out-of-bounds-issue-68972.rs:5:14 | LL |         251..257 => {} |              ^^^ this value doesn't fit in `u8` whose maximum value is `255` error: literal out of range for `u8` --> $DIR/range-pattern-out-of-bounds-issue-68972.rs:8:15 | LL |         251..=256 => {} |               ^^^ this value doesn't fit in `u8` whose maximum value is `255` error: literal out of range for `u8` --> $DIR/range-pattern-out-of-bounds-issue-68972.rs:5:14 | LL |         251..257 => {} |              ^^^ this value doesn't fit in `u8` whose maximum value is `255` error: literal out of range for `u8` --> $DIR/range-pattern-out-of-bounds-issue-68972.rs:8:15 | LL |         251..=256 => {} |               ^^^ this value doesn't fit in `u8` whose maximum value is `255` error: aborting due to 4 previous errors </ins>

Discussion:
For a match where I'm matching on a , I put on accident, and then rather than saying that 256 is out of range for , it decided to wrap 256 to 0 and then error that 251 is lower than the end of the range: Clearly this is not a good situation. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'd like to fix this claim
Triage: I'm going to release assignment due to inactivity. If you're still interested in this, feel free to re-claim. release-assignment
Explanation on how to solve this in
Change:
#[test] #[should_fail] fn test_ascii_fail_char_slice() { 'λ'.to_ascii(); } <ins> #[test] </ins> fn test_opt() { assert_eq!(65u8.to_ascii_opt(), Some(Ascii { chr: 65u8 })); assert_eq!(255u8.to_ascii_opt(), None);

Discussion:
Former-XXXes say "is this right?"
Clearing milestone because it's not obviously blocking anything. -- what test case(s) would answer the question you asked in a comment ("is this right?")?
Visiting for triage; FIXMEs are still there.

We should add some sort of special comment like . Here is the hashcode of the current snapshot. The build system can then issue warnings if such a comment exists and is not still the current snapshot.
do you still feel that this would be useful?
Still seems useful to me.
Still very useful.
(bug triage) This would be nice, but is not a blocker.
Change:
<del> // run-pass #![allow(unused_must_use)] #![feature(unwind_attributes)] // Since we mark some ABIs as "nounwind" to LLVM, we must make sure that // we never unwind through them. // ignore-cloudabi no env and process // ignore-emscripten no processes // ignore-sgx no processes use std::{env, panic}; use std::io::prelude::*; use std::io; use std::process::{Command, Stdio}; #[unwind(aborts)] // FIXME(#58794) extern "C" fn panic_in_ffi() { panic!("Test"); } fn test() { let _ = panic::catch_unwind(|| { panic_in_ffi(); }); // The process should have aborted by now. io::stdout().write(b"This should never be printed.n"); let _ = io::stdout().flush(); } fn main() { let args: Vec<String> = env::args().collect(); if args.len() > 1 && args[1] == "test" { return test(); } let mut p = Command::new(&args[0]) .stdout(Stdio::piped()) .stdin(Stdio::piped()) .arg("test").spawn().unwrap(); assert!(!p.wait().unwrap().success()); } </del>

Discussion:
I would expect the following code to abort, and never print : But instead, the attribute . Cc
That looks like a bug. cc
is just , and having in the testcase may create the wrong impression (i.e. this bug has nothing to do with FFI). Still, the attribute should either work and cause an abort or error as unapplicable.
I deliberately made it explicit, but sure, I can adjust the example.
Agreed that this just looks like a bug that needs to be fixed.
Change:
} /// Different kinds of files which can be identified by a call to stat <del> #[deriving(PartialEq, Show, Hash)] </del> <ins> #[deriving(PartialEq, Show, Hash, Clone)] </ins> pub enum FileType { /// This is a normal file, corresponding to `S_IFREG` TypeFile,

Discussion:
Hi guys! Is there any reasons, why () can't be cloned? It is the only non-clonable part of , which makes the entire struct non-clonable either.
Looks like an oversight. CC
Hey! If this is confirmed as oversight, can I add trait to FileType and address this issue? Or should this be addressed as part of
Go for it! isn't something that'll be fixed in one commit, it's an ongoing effort.
Change:
} } } <ins> #[instrument(skip(tcx), level = "debug")] fn try_instance_mir<'tcx>( tcx: TyCtxt<'tcx>, instance: InstanceDef<'tcx>, ) -> Result<&'tcx Body<'tcx>, &'static str> { match instance { ty::InstanceDef::DropGlue(_, Some(ty)) => match ty.kind() { ty::Adt(def, substs) => { let fields = def.all_fields(); for field in fields { let field_ty = field.ty(tcx, substs); if field_ty.has_param() && field_ty.has_projections() { return Err("cannot build drop shim for polymorphic type"); } } Ok(tcx.instance_mir(instance)) } _ => Ok(tcx.instance_mir(instance)), }, _ => Ok(tcx.instance_mir(instance)), } } </ins>

Discussion:
I found this ICE while compiling in release mode. : <details<summary<strongBacktrace</strong</summary<p</p</detailsbisect command: bisect result: Regression in
uuh cc
For repro:
You're right that this ICEs after my PR but not before, but this looks like an issue related to type system code or , not MIR inlining itself, so I don't think I can't help here.
Ah so it would have iced before if we had forced inlining before?
Yes, with enough application of this code should ICE before that PR. I couldn't tell you where to apply the attribute though, just squinting at the ICE message it looks like this is significant, though I don't know enough to track down where that closure is.
Is there some rustc flag I can use to force inlining of like ~ everything ~ for testing purposes? :eyes: edit: -Zinline-mir-threshold=0 or something like that? :D
You need to set both thresholds, and I don't think we have a magic value for "always", just use a big number. The defaults are 50 and 100 I think. Also just FYI there's also an inlining depth limit that's not configurable, but it shouldn't be relevant for this PR. But if you see unexpected missed inlinings even with passing those flags, that threshold might be why.
Oh, those flags won't help you before the PR in question, because functions without are simply not considered for inlining at all, no matter their size. Fixing this odd ignoring of size was the whole point of that PR. You can pass to lift that "must have " requirement, but of course that turns on other passes, but the check you're trying to dodge is an explicit check for the MIR opt level inside the Inline pass so... yeah just you might also hit other bugs. You could try turning off the passes that are enabled at mir-opt-level=3 but that would be messy.

The mir opt level is cranked up already anyway Maybe I can find some snippet that somehow reassembles what we are seeing here :) I'll be able to report back in an hour or so I guess ^^
Meh besides a couple more "hangs" (process timeouts) nothing new in the standard rustc test set :/
This is a dupe of I believe
Another reproducer (possibly large): Run in , with rustc 1.71.0-nightly ( 2023-04-29) running on x86_64-unknown-linux-gnu. Failing CI log:
I've been getting this too since about a month ago: I can do a bisect.
Change:
let done_stamp = out_dir.join("llvm-finished-building"); if done_stamp.exists() { <ins> if builder.config.llvm_skip_rebuild { builder.info( "Warning:  Using a potentially stale build of LLVM;  This may not behave well.", ); return build_llvm_config; } </ins> if let Some(llvm_commit) = llvm_info.sha() { let done_contents = t!(fs::read(&done_stamp));

Discussion:
The compiler LLVM is rebuilt whenever the built version of LLVM doesn't have the right hash. (Previously it was rebuilt based on a special marker file, which was easier to work around.) However, most of the time, having the latest LLVM version is not necessary, but makes rebuilding rustc after rebasing take significantly longer, which is a pain. It would be good to be able to disable this as an option in for convenience. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
To fix this, you'll want to add another option: you should be able to look at the logic for something like .
It would be good if this could be changed in the config file so you don't have to pass in the option all the time.
if it's a config file option, then there should be an option to rebuild it if necessary. I.e. it shouldn't be necessarily to temporarily change the to rebuild.
sure that seems good, although they can be implemented separately.
The line you would need to change is near this one: (line 735 of ) It would probably be much easier to add a check against a key in the config, than to add a new flag.
claim
Error: Parsing assign command in failed: claim ... Please let know if you're having trouble with this bot.
, my bad! claim EDIT: oh dear, I'm making it worse
are you still working on this? I wouldn't mind picking it up if not. (Sorry - not really sure what the etiquette is re: dormant tickets!)
Just saw that PR () lapsed. I'm gonna claim this, if that's okay. Will work on something based on the existing comments there. claim
Thank you for picking this up! Getting things fixed is the important thing, and I'm sure I'll find something else to fix in the near future when I have more time
Change:
let mut fuel = self.optimization_fuel.lock(); ret = fuel.remaining != 0; if fuel.remaining == 0 && !fuel.out_of_fuel { <del> self.warn(&format!("optimization-fuel-exhausted: {}", msg())); </del> <ins> if self.diagnostic().can_emit_warnings() { // We only call `msg` in case we can actually emit warnings. // Otherwise, this could cause a `delay_good_path_bug` to // trigger (issue #79546). self.warn(&format!("optimization-fuel-exhausted: {}", msg())); } </ins> fuel.out_of_fuel = true; } else if fuel.remaining > 0 { fuel.remaining -= 1;

Discussion:
Building with leads to . <!-- 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. --: From bisecting previous nightlies, this is a regression between 2020-09-03 and 2020-09-04 . Within ..., it looks like is related. Cc <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
is a workaround.
Minimal reproduction without Cargo: <details<summaryFull output</summary</details
I am also seeing this panic, though perhaps unrelated because I don't have those flags. I don't have a minimal example yet. Here's my trace. Let me know if I should make another bug.
I found a minimal example and opened a new issue, . Same error message, very different example. Seems unrelated.