jiebi/CodeConvo huggingface dataset:
Change:
ErrorHandled::TooGeneric(span) } err_inval!(AlreadyReported(guar)) => ErrorHandled::Reported(guar, span), <del> err_inval!(Layout(LayoutError::ReferencesError(guar))) => { ErrorHandled::Reported(guar.into(), span) } </del> <ins> err_inval!(Layout(LayoutError::ReferencesError(guar))) => ErrorHandled::Reported( ReportedErrorInfo::tainted_by_errors(guar), span, ), </ins> // Report remaining errors. _ => { let (our_span, frames) = get_span_and_frames();

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: interpret const eval failure of Unevaluated(UnevaluatedConst { def: DefId(0:11 ~ ice[ec8e]::EEKZERO), args: [], promoted: Some(promoted[0]) }, &'{erased} [Eek; 0usize]) which is not in requiredconsts', 'error: internal compiler error: interpret const eval failure of Unevaluated(UnevaluatedConst { def: DefId(0:11 ~ ice[ec8e]::EEKZERO), args: [], promoted: Some(promoted[0]) }, &'{erased} [Eek; 0usize]) which is not in requiredconsts' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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: 6 | const EEKZERO: &[Eek] = &[]; [evaltoallocationraw] const-evaluating + checking [evaltoconstvalueraw] simplifying constant for the type system [analysis] running analysis passes on this crate --
cc
Caused by running the interpreter on code that doesn't even pass name resolution. Not sure where to fix this, but probably not in the interpreter.^^ Cc
this is a promoted failing to compile because it gets the layout of this broken type, which gives us back an . I'm certain we can prevent const eval from running by checking such layouts earlier in the MIR pipeline, but the fix isn't clear to me yet.
The issue is that in the sanity check we only know it's an , we don't know whether it was a typeck error on a const-eval error. So we can't really distinguish these cases. If this is a , we could probably fix it by tweaking the error handling . But there probably are similar cases where a promoted fails to evaluate due to a SizeOverflow and then we have to report the error somewhere.

The only option I see right now is to add another variant to (or a flag in ) to track whether this was a failure inside the constant itself or a failure in something the constant referenced. But this distinction isn't always very clear anyway... it would basically have to be "is this an error that can occur even for supposedly infallible operations like ", i.e., match exactly the usecase of the const-eval / promoted sanity check. Which is not great.
We already got the flag that we can reuse for that
Change:
<del> #!/usr/bin/env rustx // run-pass pub fn main() { println!("Hello World"); } </del>

Discussion:
We fail to parse this (admittedly questionable) code as of beta: This broke one repository (not crate) in the beta crater run: https://crater-
cc I personally suspect that we may want to ask T-lang if we're good accepting this as expected breakage. Alternatively I guess we can adjust the shebang detection to not require a non-empty shebang.
Assigning .
For reference, here's the code responsible for parsing shebang in Linux kernel - (Fully whitespace (including empty) line isn't considered a shebang.)
I am inclined to close as won't fix; let's cc as the author of that repository as well. I'm going to go ahead and nominate this so that we can get a :+1: (or not) at the T-compiler meeting confirming won't fix status.
I made a fix in , which also has a benefit of simplifying the rules slightly.
Thanks guys, was more of a spelling mistake/leftover from previous version than unclear explanation of how to use shebang with rust as your previous explanation on how to use it worked fine in something else I was playing around with. But thank you very much for letting me know. Sent with Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
Change:
<ins> error[E0391]: cycle detected when processing `Foo` --> $DIR/existential-types-with-cycle-error2.rs:7:1 | LL | existential type Foo: Bar<Foo, Item = Foo>; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | note: ...which requires processing `crash`... --> $DIR/existential-types-with-cycle-error2.rs:10:25 | LL |   fn crash(x: Foo) -> Foo { |  _________________________^ LL | |     x LL | | } | |_^ = note: ...which again requires processing `Foo`, completing the cycle note: cycle used when collecting item types in top-level module --> $DIR/existential-types-with-cycle-error2.rs:1:1 | LL | / #![feature(existential_type)] LL | | LL | | pub trait Bar<T> { LL | |     type Item; ...  | LL | | LL | | } | |_^ error: aborting due to previous error For more information about this error, try `rustc --explain E0391`. </ins>

Discussion:
Playing with the nighly's existential types, I stumbled upon a compiler stack overflow: Error message:
A better example might be this: removing the from the existential type decleration just compiles fine
Can you try running the compiler inside gdb and produce a backtrace?
<details<summaryBacktrace:</summary</details
It's recursing in Ideally this should cause cycle errors. But I'm assuming Manually computes this without a query. Maybe we should just make a query? This would solve both the FIXME and this issue.
Both examples now produce a cycle error. So we just need to add the two examples to (if there aren't already tests for these situations)
Change:
link_resolver.resolver.resolve_rustdoc_path(extern_name, TypeNS, parent_scope); } <ins> link_resolver.process_extern_impls(); </ins> ResolverCaches { markdown_links: Some(link_resolver.markdown_links), doc_link_resolutions: link_resolver.doc_link_resolutions,

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
cc
Rustdoc assumes that there is always a module for every primitive type referred to by a doc link, which is not the case in the code example above or any "minimal core" example not containing the primitive documentation modules.
Fixed in
Change:
} } <ins> impl From<c_int> for ExitStatus { fn from(a: c_int) -> ExitStatus { ExitStatus(a) } } </ins> impl fmt::Display for ExitStatus { fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { if let Some(code) = self.code() {

Discussion:
Because has a private field it is impossible to create one in user code, one must actually execute a process. This prevents testing/mocking. My use case is that I have some function which runs a process and generates data, however, for testing I want to mock the test run and just return a success exit status and some data. I can't do that because I can't create my own objects. At the least there should be a way to create a success . Preferably, there would be a way to create various fail statuses too.
Should the constructor just take an ?
I've also wanted a basically "raw constructor" in the past. I'd be fine adding some extensions which allow construction from a or ( and )
+1 I’d like to extend , but I cannot reuse for return value because I can’t construct . :(
I've opened a PR for this over at
Great, thanks! :+1:
This would help n00bs like me who start out by copying the example code and tweaking it: This example is a special case that only happens to work if the contains a or something else that immediately exits. Otherwise you need to create your own struct to return which is currently impossible.
This issue is now entering a cycle-long final comment period for stabilization
Discussed recently, the libs team decided to stabilize.
Change:
// HACK(eddyb) Emulate a bit of dataflow analysis, // conservatively, that drop elaboration will do. let needs_drop = if let Place::Local(local) = *place { <del> self.local_needs_drop[local] </del> <ins> if self.temp_qualif[local].map_or(true, |q| q.intersects(Qualif::NEEDS_DROP)) { Some(self.mir.local_decls[local].source_info.span) } else { None } </ins> } else { <del> None </del> <ins> Some(self.span) </ins> }; if let Some(span) = needs_drop {

Discussion:
These currently compile, even if they can be used from compile-time code to trigger a drop: cc
Change:
<del> //@ known-bug: #121126 fn main() { let _n = 1i64 >> [64][4_294_967_295]; } </del>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: value <= 0xFFFFFF00'', 'thread 'rustc' panicked at 'assertion failed: value <= 0xFFFFFF00'' 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: [mirdropselaboratedandconst_checked] elaborating drops for [analysis] running analysis passes on this crate --
cc
I cannot reproduce this with a local stage 1 build nightly and beta show this tho...
maybe this is a rustc miscompile? cc
I can reproduce this on aarch64-apple-darwin, and on beta.
The calls to seem bogus because index is potentially out of range (the valid range is restricted further in comparison to u32):
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
<ins> warning: unused macro definition --> $DIR/issue-70041.rs:4:1 | LL | / macro_rules! regex { LL | | LL | |     () => {}; LL | | } | |_^ | = note: `#[warn(unused_macros)]` on by default warning: unused import: `regex` --> $DIR/issue-70041.rs:10:5 | LL | use regex; |     ^^^^^ | = note: `#[warn(unused_imports)]` on by default </ins>

Discussion:
As of rustc 1.43.0-nightly ( 2020-03-15) the Travis CI builds of are failing due to rustc crashing. The crash happens when building the crate, which is a dependency of one of quiche's subcrates. Unfortunately I wasn't able to reproduce this locally, so I can't try the latest master or try to prepare a minimal reproducer, but I can reproduce this realiably on Travis CI, see e.g. https://travis- https://travis- https://travis- https://travis- Could this have something to do with Travis CI specifically? As per above, I don't have specific code that reproduces this. I can only reproduce when building the crate as part of quiche on Travis CI. : <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
FTR, the docopt crate was last updated almost a year ago, so this is not due to some new code there
Let's see if we can shrink the input to something suitable for a regression test. ping cleanup Also cc
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
This seems to be an issue with It could be we're calling with something that isn't an HIR owner, in which case it should be changed to return instead of panicking. It's odd that it can't be reproduced though.
I can reproduce it by on
I just realized I wasn't actually using rust nightly when I tried to reproduce locally :man_facepalming: so that explains that...
Minimized:
assign
Change:
<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. trait Expr : PartialEq<Self::Item> { //~^ ERROR: unsupported cyclic reference between types/traits detected type Item = Expr; } fn main() {} </ins>

Discussion:
On rustc 1.0.0-nightly ( 2015-02-21) (built 2015-02-21) the follow causes an ICE: Full backtrace: 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 'assertion failed: != ast::LOCALCRATE', /Users/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc- stack backtrace: 1: 0x10b7aebe3 - sys::backtrace::write::hc8e3cee73e646c590nC 2: 0x10b7dcbe5 - panicking::onpanic::h00b47941f5bc8a02HOL 3: 0x10b706418 - rt::unwind::beginunwindinner::h539538ef7f909326UvL 4: 0x108472895 - rt::unwind::beginunwind::h7610573592537740396 5: 0x1087eb7dc - middle::ty::lookuptraitdef::h00103e323589b59cNla 6: 0x108812687 - middle::ty::predicatesfortraitref::h59dd4f8104908ae1Vna 7: 0x10880c125 - middle::traits::util::Elaborator<'cx, 'tcx.Iterator::next::h9dd8ee47ae7ea8d3QkV 8: 0x108811fd1 - middle::traits::util::Supertraits<'cx, 'tcx.Iterator::next::h2583ba3461accfb9rnV 9: 0x108109246 - astconv::asttytoty::closure.

10: 0x1080a36cb - astconv::asttytoty::hb64a583bfbbc7b64Ncw 11: 0x1080ff44d - astconv::asttyargtoty::h51a53c78e1218ba4sbw 12: 0x1080feff0 - vec::Vec<T.FromIterator<T::fromiter::h8575313848639105278 13: 0x1080fc2e0 - astconv::convertanglebracketedparameters::h9209f0db8109fac9biv 14: 0x108101457 - astconv::astpathtotraitref::h2a3b7b2e77e3fde5Vvv 15: 0x1080af1fb - astconv::instantiatetraitref::h65c5bb030d486323Csv 16: 0x1081007ea - astconv::instantiatepolytraitref::hb7df5c75231f22c61qv 17: 0x10813049f - collect::computebounds::h0eb0cb5207e10f2ccTy 18: 0x10811270f - collect::traitdefofitem::hb48744a94bcef339Q2x 19: 0x108110c0f - collect::CollectTraitDefVisitor<'a, '<'v::visititem::h4c7bef27b106e20cS8w 20: 0x10815d07f - checkcrate::closure.

21: 0x10815b02e - checkcrate::hbe2eb4aab434ad7cVjC 22: 0x107ac68db - driver::phase3runanalysispasses::h50728865d3ffa6b2gHa 23: 0x107aabb9d - driver::compileinput::h349b039ebe75c13eGba 24: 0x107b84857 - runcompiler::h1e4d87c6044fbf6dZbc 25: 0x107b81cd1 - thunk::F.Invoke<A, R::invoke::h2059937391804860278 26: 0x107b80930 - rt::unwind::try::tryfn::h11862807381821880905 27: 0x10b8567e9 - rusttryinner 28: 0x10b8567d6 - rusttry 29: 0x107b81095 - thunk::F.Invoke<A, R::invoke::h6573516661401600357 30: 0x10b7c5ac3 - sys::thread::threadstart::h9e3555425c6999b2e4G 31: 0x7fff8fd0d268 - pthreadbody 32: 0x7fff8fd0d1e5 - pthreadbody
This is basically . And on top of , correctly declares there's an illegal recursive type:
Tests in .
Can this be closed?
Change:
} fn document_type_layout(w: &mut Buffer, cx: &Context<'_>, ty_def_id: DefId) { <ins> fn write_size_of_layout(w: &mut Buffer, layout: &Layout, tag_size: u64) { if layout.abi.is_unsized() { write!(w, "(unsized)"); } else { let bytes = layout.size.bytes() - tag_size; write!(w, "{size} byte{pl}", size = bytes, pl = if bytes == 1 { "" } else { "s" },); } } </ins> if !cx.shared.show_type_layout { return; }

Discussion:
introduced a basic section on layout information, with only one piece of information: the total size of the type. I think one useful but easy extension to this is reporting the size of each variant for an enum. cc The "Layout" section is rendered in The variable is a .In that case we have access to an . The part will give us the size of the variant To get the name of the variant, we'll need the stored in , which we can hopefully get from . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think we could just look up the to find the name (there's probably a function for that). Also, it might be worth showing the sizes of each union field.
claim
Change:
for line in script_file: command = line.strip() <ins> if command == "run" or command == "r" or re.match("^processs+launch.*", command): # Before starting to run the program, let the thread sleep a bit, so all # breakpoint added events can be processed time.sleep(0.5) </ins> if command != '': execute_command(command_interpreter, command)

Discussion:
From time to time the LLDB test suite hangs on the build bots, which leads to the whole pipeline being blocked for an hour. One way to make this problem a bit less severe is to add a time-out to the LLDB test runner which just kills tests that take longer than a few seconds. This should at least reduce the time until the tests can be restarted. cc
cc
Change:
<ins> # only-windows # needs-rust-lld -include ../../run-make-fulldeps/tools.mk # Ensure that LLD can link all: $(RUSTC) -C linker=rust-lld foo.rs </ins>

Discussion:
I tried this code: Build with With recent nighties it fails to link: This issue does not occur with or . searched nightlies: from nightly-2022-04-24 to nightly-2022-04-28 regressed nightly: nightly-2022-04-26 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details
cc This may potentially be reproducible with too. UPD: It does reproduce on , even on hello-world, if LLD is used as a linker instead of UPD2: needs to have one additional "feature-enabling" symbol on these targets, see in LLD sources.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Thanks for the quick fix!
Change:
let ident_span = path.last().map_or(span, |ident| ident.ident.span); let typo_sugg = self.lookup_typo_candidate(path, following_seg, source.namespace(), is_expected); <del> let is_in_same_file = &|sp1, sp2| { let source_map = self.r.tcx.sess.source_map(); let file1 = source_map.span_to_filename(sp1); let file2 = source_map.span_to_filename(sp2); file1 == file2 }; // print 'you might have meant' if the candidate is (1) is a shadowed name with // accessible definition and (2) either defined in the same crate as the typo // (could be in a different file) or introduced in the same file as the typo // (could belong to a different crate) if let TypoCandidate::Shadowed(res, Some(sugg_span)) = typo_sugg && res.opt_def_id().is_some_and(|id| id.is_local() || is_in_same_file(span, sugg_span)) { err.span_label( sugg_span, format!("you might have meant to refer to this {}", res.descr()), ); return true; } </del> let mut fallback = false; let typo_sugg = typo_sugg.to_opt_suggestion(); if !self.r.add_typo_suggestion(err, typo_sugg, ident_span) {

Discussion:
(A better title would be appreciated) I like this part: It could have a suggestion like , especially because are very close to each other on a US keyboard and could very well be a typo. Applying the suggestion will result in a compile error. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think the label might be fitting as well.
Error: Parsing assign command in failed: ...' claim' ' +D-invali'... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
Change:
/// } /// assert_eq!(buf, [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]); /// ``` <del> #[unstable(feature = "vecdeque_rotate", issue = "56686")] </del> <ins> #[stable(feature = "vecdeque_rotate", since = "1.36.0")] </ins> pub fn rotate_left(&mut self, mid: usize) { assert!(mid <= self.len()); let k = self.len() - mid;

Discussion:
Currently if you want to rotate a VecDeque n elements to the left or right, you'd have to write something like this: I wonder if it would be possible to add 2 functions: rotateleft(mid: usize) rotateright(mid: usize) You then only have to write: This would be equal to slice's and . It could probably be implemented on a lower level than with pop's and pushes for a little more efficiency.
Ooh, I like this -- is a circular buffer internally, so it should be doable with at most two . EDIT: PR
PR is r+'d, so I turned this into a tracking issue.
I've since the feature replaced any code that used the pop - push technique with the rotate methods. This was fairly easy to do. It's been a few months now, are there any issue's preventing this from landing stable?
fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [ ] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
Is "left" or "right" the word we want to use here? Previously we have deprecated () of in favor of and so that we do not assume the string is laid out from left to right. Here we seem to assume is to while is to ? Are we able to use some words that express the and without assuming a left-to-right layout?
As discussed here, we have to use those names to stay consistent with the slice rotate_{left |right} methods
, sorry I missed that. That makes sense.
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
Change:
<ins> error[E0282]: type annotations needed --> $DIR/opaque-cast-field-access-in-future.rs:22:17 | LL | fn run() -> Foo<impl Future<Output = ()>> { |                 ^^^^^^^^^^^^^^^^^^^^^^^^ cannot infer type error: aborting due to previous error For more information about this error, try `rustc --explain E0282`. </ins>

Discussion:
https://crater- https://crater- https://crater-
Might be related to
I've tried the first 2 crates (bonedaddy.ellidri and edu-sync), they compile on the current stable fail to compile on beta and nightly. Provisionally assigning P-high waiting for more investigation (). label -I-prioritize +P-high +T-compiler
bisected to commit , where in this commit originates the issue: Regression in i.e. rollup PR (Implement proposed API for ) (Simplify computation of killed borrows) (More nits) (add note for non-exhaustive matches with guards) (Fix invalid HTML DIV tag used in HEAD) (add myself to review for t-types stuff) label -e-needs-bisection
Bisection probably leads to cc TIL to look at the results, they help getting more context. They told me tha PR is actually commit
I'll take a look at this after RustConf.
Is it possible the bisection contained an error? I'm not seeing any possible connection. The errors seem unrelated, is not used anywhere in my PR, and is not even present in any of the three linked logs.
Ok, I give up on reproducing using the crate (in the latest nightlies the error changed, I can't track the original error anymore). So I've started again using the crate I now have a stable reproducible. I am now a bit more confident the regression is in (specifically ) cc (I see in that patch some code that is in the stacktraces). sorry for the ping and thanks for pointing me into the right direction :)
No worries! Someone mentioned that it may have been incorrect at RustConf, but I wanted to have a chance to look into it myself before saying anything. I'll be unsubscribing from this issue; please ping if something needs my attention :)
small, but not yet minimal repro. Should be good enough for the test suite. I'm looking into a fix now.
I reverted all changes from and it does not appear to change behaviour. trying a local bisect on the minimal repro. edit: hmm weird, it also points to that PR. Trying again edit2: ok now it works, weird