jiebi/CodeConvo huggingface dataset:
Change:
`unused_attributes`, and `dead_code`. Small examples often trigger these lints. 3. If the example does not contain `extern crate`, then `extern crate <del> <mycrate>;` is inserted. 2. Finally, if the example does not contain `fn main`, the remainder of the text is wrapped in `fn main() { your_code }` Sometimes, this isn't enough, though. For example, all of these code samples </del> <ins> <mycrate>;` is inserted (note the lack of `#[macro_use]`). 4. Finally, if the example does not contain `fn main`, the remainder of the text is wrapped in `fn main() { your_code }`. This generated `fn main` can be a problem! If you have `extern crate` or a `mod` statements in the example code that are referred to by `use` statements, they will fail to resolve unless you include at least `fn main() {}` to inhibit step 4. `#[macro_use] extern crate` also does not work except at the crate root, so when testing macros an explicit `main` is always required. It doesn't have to clutter up your docs, though -- keep reading! Sometimes this algorithm isn't enough, though. For example, all of these code samples </ins> with `///` we've been talking about? The raw text: ```text

Discussion:
When a doctest like this is written: /// /// running the tests will produce an error like: since the test code is wrapped inside a for execution. This is imho not clear in this algorithm description
This seems like a bug somewhere in rustc/cargo, rather than a problem with the docs, because rust /// works fine, but (as was mentioned here) rust /// does not. This seems like wrong behaviour. Also, the suggested rust /// does not work either, I don't know if there is an RFC or issue open about attempting to resolve the names suggested under ... and only showing them if they exist. EDIT: as mentioned below, this is not a bug with rustc or cargo, it's just that there is no way to refer to the current function scope in a use statement if you import a crate into it.
it's not wrong but it is very misleading. The key is that if does not appear in the doc test, then rustdoc encloses the entire test in a main function. This, coupled with the fact that does not really work inside a function, produces the bad situation in which we find ourselves.
Right, it's the 'entire' part that's confusing. I myself find it to be so and I wrote the sentence!
It would be nice if rustdoc used similar heuristics to playbot, where stuff like extern crates and crate attributes get hoisted out of the generated main function.
Why is extern crate even allowed inside of functions? That seems like a horrible misfeature.
It's similar to anything else that brings a name into scope, you can do it in whatever scope you'd like.
I guess the "real" problem is that has no way to refer to a function/expression scope. doesn't work, making the "did you mean" note less than helpful.
Change:
dependencies = [ "itertools 0.8.0", "minifier", <del> "pulldown-cmark 0.7.0", </del> <ins> "pulldown-cmark 0.7.1", </ins> "rustc-rayon", "serde", "serde_json",

Discussion:
If I run cargo doc on the below code, it never finishes. I expected to see it finish. Problem does not exist on stable
cc
Fixed upstream in , but not released yet.
Let's hope next version will be released soon then! :)
Unfortunately this also affects 1.43 beta.
Hm so this will hit stable in less than a week then. Do we consider it high priority enough to try to push through a release ourselves? (e.g. we can temporarily fork or whatever, perhaps only on the beta branch). I personally lean towards no but wouldn't be opposed to doing so if t-rustdoc wanted to.
This issue halted development at our company for a day until we bisected the issue down to the particular line of code (a comment) that was causing to hang indefinitely. Thank you for all of your hard work on Rust. It is my most favourite language. I've been waiting for a suitable replacement for C++, and it has arrived!
Looks like there's movement on a point release, I would be in favor of backporting this to beta, since it's a really painful bug to hit...
0.7.1 has been released.
Yea, PR to update is up at .
Change:
<ins> // Several variants of #64945. // This struct is not important, we just use it to put `T` and `'a` in scope for our associated // consts. struct Generic<'a, T>(std::marker::PhantomData<&'a T>); impl<'a, T: 'static> Generic<'a, T> { const EMPTY_SLICE: &'a [T] = { let x: &'a [T] = &[]; x }; const EMPTY_SLICE_REF: &'a &'static [T] = { let x: &'static [T] = &[]; &x //~^ ERROR `x` does not live long enough }; } static mut INTERIOR_MUT_AND_DROP: &'static [std::cell::RefCell<Vec<i32>>] = { let x: &[_] = &[]; x }; static mut INTERIOR_MUT_AND_DROP_REF: &'static &'static [std::cell::RefCell<Vec<i32>>] = { let x: &[_] = &[]; &x //~^ ERROR `x` does not live long enough }; fn main() {} </ins>

Discussion:
This code: Errors on with this message:
cc
regression in
I'm still building a compiler with graphviz debugging enabled so I can have a closer look, but I have a theory. I believe the problem is that we are too conservative when marking locals as . Because we pessimistically assume that type is , we also assume that type can be mutated through a shared reference. Once a shared reference to it is taken, we assume that all qualifs that could apply to are applied to that local. We should special case zero-sized arrays here, so when the borrow of occurs, it is not marked as indirectly mutable. Perhaps we could assume that zero-sized arrays never actually as well? While this change would solve this particular issue, I believe that this won't solve the problem entirely. What if we take two references to the zero-sized type ()? While the local containing the ZST itself will not be marked as indirectly mutable, the local containing the first borrow will be, which diverges from the old analysis. We may need to base whether a is indirectly mutable on the analysis.
Change:
<ins> #![allow(unused)] #![feature(const_fn_trait_bound, const_trait_impl, inline_const)] const fn f<T: ~const Drop>(x: T) {} struct UnconstDrop; impl Drop for UnconstDrop { fn drop(&mut self) {} } fn main() { const { f(UnconstDrop); //~^ ERROR the trait bound `UnconstDrop: Drop` is not satisfied } } </ins>

Discussion:
Given the following code (): The current output is: Ideally, the output should be the same as when such a call is made in a item: ... which can be improved further with the suggestion given in : modify labels: +A-const-eval +A-traits +D-confusing +D-terse +F-consttraitimpl +F-inlineconst <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Change:
P(self.expr(sp, hir::ExprTup(exprs), ThinVec::new())) } <del> fn expr_std_struct(&mut self, span: Span, components: &[&str], fields: hir::HirVec<hir::Field>, e: Option<P<hir::Expr>>, attrs: ThinVec<Attribute>) -> hir::Expr { let path = self.std_path(span, components, false); let qpath = hir::QPath::Resolved(None, P(path)); self.expr(span, hir::ExprStruct(qpath, fields, e), attrs) } </del> fn expr(&mut self, span: Span, node: hir::Expr_, attrs: ThinVec<Attribute>) -> hir::Expr { hir::Expr { id: self.next_id(),

Discussion:
The following code produces a compiler error (as expected) on stable, but the compiler crashes on nightly. On stable: On nightly:
Also in beta=1.17.
Backtrace:
Change:
<ins> error[E0277]: the trait bound `for<'t> <std::iter::Map<<&'t _ as std::iter::IntoIterator>::IntoIter, _> as std::iter::Iterator>::Item: Foo` is not satisfied --> $DIR/issue-60218.rs:18:5 | LL | pub fn trigger_error<I, F>(iterable: I, functor: F) |        ------------- ... LL | for<'t> <Map<<&'t I as IntoIterator>::IntoIter, F> as Iterator>::Item: Foo, |                                                                        --- required by this bound in `trigger_error` ... LL |     trigger_error(vec![], |x: &u32| x) |     ^^^^^^^^^^^^^ the trait `for<'t> Foo` is not implemented for `<std::iter::Map<<&'t _ as std::iter::IntoIterator>::IntoIter, _> as std::iter::Iterator>::Item` error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
The following code: results in an ICE Tested this on stable and nightly. May be somehow related to .
Backtrace: Happens on stable, beta, nightly
Litte bit simplified:
Bisection show ICE was introduced in , but I'm not sure how related that is, because it's a very very big PR. CC
I will investigate.
ping , any progress here?
I did some investigation. This bugs turns out to have been fixed -- well, more likely it was worked around by I'm going to land a test for it so that when I get around to reversing , I can fix it then.
Change:
cfg_if::cfg_if! { if #[cfg(all(target_vendor = "apple", not(target_os = "watchos"), target_arch = "arm"))] { <del> // 32-bit ARM Apple (except for watchOS) uses SjLj and does not provide // _Unwind_Backtrace() </del> <ins> // 32-bit ARM Apple (except for watchOS armv7k specifically) uses SjLj and // does not provide _Unwind_Backtrace() </ins> extern "C-unwind" { pub fn _Unwind_SjLj_RaiseException(e: *mut _Unwind_Exception) -> _Unwind_Reason_Code; }

Discussion:
Building project using should just work, but instead it fails to link to the and symbols. The exact error is: : This worked with , I'll try to bisect it myself. label O-watchos
Ugh, don't you just love it when the culprit is yourself? It's
Change:
|                        ^ doesn't have a size known at compile-time | = help: the trait `Sized` is not implemented for `[u8]` <del> help: function arguments must have a statically known size, borrowed types always have a known size | LL |     let f: fn([u8]) = |&_| {}; |                        + </del> <ins> = note: all function arguments must have a statically known size </ins> error: aborting due to previous error

Discussion:
Notice how the last 2 suggestions aren't valid in such a closure: The suggestions given in should help me get closer to fixing the error, or at least not have invalid syntax. No response No response Output of :
(if is used in the snippet, comes up again with leaking implementation details)
Change:
"libsync/mpsc_intrusive.rs", # BSD "test/bench/shootout-fannkuch-redux.rs", # BSD "test/bench/shootout-meteor.rs", # BSD <ins> "test/bench/shootout-pidigits.rs", # BSD </ins> "test/bench/shootout-regex-dna.rs", # BSD ]

Discussion:
See I propose to change the license of Non trivial contributors: OK OK Contributors appearing in git blame that are trivial (trivial update due to language changes): OK OK (sent agreement to by email) OK OK Contributors with removed and trivial contributions are not considered. For the persons that are not in "OK" state, please respond to this issue saying: Then, I'll propose the corresponding PR. Thanks.
Yes I am a MoCo employee, you don't have to worry about me for this or future benchmark relicensing issues.
Thanks On Jun 7, 2014 5:06 AM, "TeXitoi" wrote:
Change:
use crate::const_eval::error_to_const_error; use crate::transform::{MirPass, MirSource}; <ins> /// The maximum number of bytes that we'll allocate space for a return value. const MAX_ALLOC_LIMIT: u64 = 1024; </ins> pub struct ConstProp; impl<'tcx> MirPass<'tcx> for ConstProp {

Discussion:
The following ICEs on beta and nightly: () <details<summarygdb backtrace </summary</details
triage: P-high.

A MSVC x8664 bors job has failed on two unrelated PRs (, ) with the : In both cases, attempted to allocate several GB of memory while compiling the crate. One of these failures was in the job, and the other was in . This failure appears to be spurious: a previous version of passed the same job.
I wonder if we could get a backtrace or something from this allocation -- it seems... suspicious that we're only sometimes OOMing. It's also interesting to note that this is almost exactly 4 GB in a single allocation, which is surprising generally ( is not a big crate -- 300 lines or so, with comments etc).
On my PR it was a different (almost) power of two: edit In both cases, the size of the allocation is 8 bytes less than a power of two.
So I minimized this to: on a recent nightly gives: It looks like the compiler is trying to allocate enough space to store a value of the return type. As long as I use a large enough value it reproduces reliably and it isn't specific to Windows: . I bisected this to and I'm guessing (cc is the root cause.
Yes, that seems likely. I will take a look at this tonight.
should we put on hold while this is sorted out?
Yeah, let's do that just to be safe.
triage: P-high. Removing nomination label.
Change:
Change this file to make users of the `download-ci-llvm` configuration download a new version of LLVM from CI, even if the LLVM submodule hasn’t changed. <del> Last change is for: https://github.com/rust-lang/rust/pull/80087 </del> <ins> Last change is for: https://github.com/rust-lang/rust/pull/80932 </ins>

Discussion:
From Switching to static linking would preclude any of the improvements from , so it would be better to use dynamic linking instead which would allow any contributor to get started without building LLVM from source or using system LLVM. That said, it sounds like dynamic linking will be very hard to do on other platforms. cc
Cc - do we know what the right way to bring the issues (bugs?) I found to LLVM developers? Are there active maintainers of LLVMs build system?
LLVM’s bugzilla is pretty much the only place for bug reports. If its something less defined than a precise bug report, talking it out on the mailing lists is the way to go.
In which way is static linking making downloaded LLVM impossible?
I don't think it's impossible to download/ship the statically linked LLVM, it's something I want to explore. That said, we want to move to dynamically linking LLVM because we ideally want to be applying ThinLTO to LLVM everywhere, not just on x86_64-unknown-linux-gnu, and since LTO happens at link-time, we want that to happen once, not on the multiple LLVM links occurring during CI.
Change:
pub fn cmd<S: AsRef<OsStr>>(program: S) -> Command { let mut command = Command::new(program); set_host_rpath(&mut command); <ins> command.env("LC_ALL", "C"); // force english locale </ins> command }

Discussion:
On an non-English system the run-make test fails because it searches a english "needle" but may print it in another language. Putting in my environment variable makes use it's default (English) language. We should probably do that for all the run-make tests.
... good catch. I love C locale.
In the compiler we set and before calling linker because we inspect linker output sometimes. That said, isn't the plan to migrate operations like this from third-party tools to library calls to something like ?
It is. However, my current plan is to prioritize first getting rid of and trimming down external bin tools and deps where possible (some of them are first moved to llvm bintools which are at least batched together with llvm). It's non-trivial to match readelf/readobj etc. when they have various combination of flags, and when reviewing I found out that libraries like have differences in its interpretation of symbols (i.e. they don't match cleanly 1-to-1). Getting rid of first of all means that we can run the run-make tests outside of msys2 msys lol. I'm going to do a second pass after first getting rid of , and revisit things like: External bin tools. Tests that require bootstrap cargo and then internet connection to run the test (the target sanity check tests). TL;DR: yes, eventually.
Change:
<ins> error: cannot find macro `something_later` in this scope --> $DIR/defined-later-issue-121061.rs:2:5 | LL |     something_later!(); |     ^^^^^^^^^^^^^^^ consider moving the definition of `something_later` before this call | note: a macro with the same name exists, but it appears later at here --> $DIR/defined-later-issue-121061.rs:5:14 | LL | macro_rules! something_later { |              ^^^^^^^^^^^^^^^ error: aborting due to 1 previous error </ins>

Discussion:
Often times, the actual error of the attempted call and the warning of the unused macro can be apart and/or soaked in other errors. Due to this, it might be desirable to couple a help message addressing this specific situation of a later definition. This might also be useful advice for beginners who are just starting out with Rust and might not be aware of the horrors of declarative macros using , and as such could appreciate a helping hand by the compiler here. No response_ I tried to keep the suggested output close to the one for similarly named macros/variables, but that might not be applicable here and instead deserve its own section under the code excerpt. Open for bikeshedding. Like all of this, actually. Hmm. (The message is the same on nightly 2024-02-12.)
label +D-terse +D-newcomer-roadblock
Thank you!!
Change:
<ins> // check-pass trait A { type T: B<U<1i32> = ()>; } trait B { type U<const C: i32>; } fn f<T: A>() { let _: <<T as A>::T as B>::U<1i32> = (); } fn main() {} </ins>

Discussion:
The following code produces several ICEs on both beta and nightly (no necessary). <!-- 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. --: <details<summary<strongBacktrace</strong</summary<p</p</details label F-genericassociatedtypes A-const-generics
This regressed in the last day...
Wait wrong issue
As GATs are stable on beta but not on stable, similar to : label regression-from-stable-to-beta
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
ty::UpvarCapture::ByValue(_) => { format!("possible mutation of `{}`", upvar) } <del> _ => bug!("upvar `{}` borrowed, but not mutably", upvar), </del> <ins> val => bug!("upvar `{}` borrowed, but not mutably: {:?}", upvar, val), </ins> } } else { bug!("not an upvar")

Discussion:
Compiled with gives:
This was caused by prioritize edit: in beta, this gives the following error: `
Assigning as discussed as part of the and removing .
Looks likely that is the cause. cc
Re-prioritizing as and removing as in the prioritization working group. label: +regression-from-stable-to-nightly +P-high -P-medium -I-prioritize
Change:
/// Walks the whole crate in DFS order, visiting each item, resolving names as it goes. impl<'a: 'ast, 'ast> Visitor<'ast> for LateResolutionVisitor<'a, '_, 'ast> { <ins> fn visit_attribute(&mut self, _: &'ast Attribute) { // We do not want to resolve expressions that appear in attributes, // as they do not correspond to actual code. } </ins> fn visit_item(&mut self, item: &'ast Item) { let prev = replace(&mut self.diagnostic_metadata.current_item, Some(item)); // Always report errors in items we just entered.

Discussion:
I'm seeing an internal compiler error on the following input, found by : The ICE happens after correctly reporting a few other errors, because the code is nonsense, so low priority. Affected versions: I tried nightly 2021-11-12 and stable 1.56.1 and they both show the same ICE. <details<summary<strongBacktrace</strong</summary<p</p</detailsAlso note how there is one additional error below the backtrace, not sure if that's expected.
Thanks for the bug report, could this be related to the recent HIR map/lowering refactorings?
This issue looks very similar to , but the examples from there don't panic anymore.

<!-- 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. --I got a very large poc file, and reduce it into following code. But after reducing (via a simple delta debugging tech), the code looks kind of confusing. Please let me know if anyone prefers a better-formed but long test-case, and I will try me best to get one. md5: <!-- 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. --The bug is reproduced with nightly and beta versions, but not with stable version. : The output is from nightly. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This can be "solved" by using and create a instead of panicking.
Assigning as discussed as part of the and removing .
A reproduction with fewer errors:
The provided examples do not panic anymore, can this issue be closed or does it need tests?
lets keep it open purely to track adding regression tests for these.
Change:
<ins> error[E0277]: the trait bound `<<Self as TraitC<E>>::TypeC<'a> as TraitB>::TypeB: TraitA` is not satisfied --> $DIR/issue-103573.rs:18:5 | LL |     fn g<'a>(_: &<<Self::TypeC<'a> as TraitB>::TypeB as TraitA>::TypeA); |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `TraitA` is not implemented for `<<Self as TraitC<E>>::TypeC<'a> as TraitB>::TypeB` | help: consider further restricting the associated type | LL |     fn g<'a>(_: &<<Self::TypeC<'a> as TraitB>::TypeB as TraitA>::TypeA) where <<Self as TraitC<E>>::TypeC<'a> as TraitB>::TypeB: TraitA; |                                                                         +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
: Fails on nightly 1.66.0 but not on stable 1.64.0. <details<summary<strongBacktrace</strong</summary<p</p</detailsEdited: minified the code
Also ICEs on beta
stable error -beta ICE I tried moving things around so lifetime is on , but that's fine. This also requires the lifetime .
Going to preemptively assign P-medium, since this code isn't correct anyways. I think this has something to do with our error recovery here, since this valid code is fine, which only changes the trait:
I got a fix here.
Change:
<ins> // check-pass #![allow(unreachable_code, unused)] use std::marker::PhantomData; struct FsmBuilder<TFsm> { _fsm: PhantomData<TFsm>, } impl<TFsm> FsmBuilder<TFsm> { fn state(&mut self) -> FsmStateBuilder<TFsm> { todo!() } } struct FsmStateBuilder<TFsm> { _state: PhantomData<TFsm>, } impl<TFsm> FsmStateBuilder<TFsm> { fn on_entry<TAction: Fn(&mut StateContext<'_, TFsm>)>(&self, _action: TAction) {} } trait Fsm { type Context; } struct StateContext<'a, TFsm: Fsm> { context: &'a mut TFsm::Context, } fn main() { let mut builder: FsmBuilder<usize> = todo!(); builder.state().on_entry(|_| {}); } </ins>

Discussion:
I haven't been able to minimize this yet. The similar, already resolved, bug report doesn't seem to help - changing the 's return signature from to the full definition doesn't help here. The bug is also present in the nightly build (). <details<summary<strongBacktrace</strong</summary<p</p</details
:
Note the error goes away if you add , or if you change to . So I think the bug is that the trait bound is not being checked. cc
Triage: no change
No longe crashes with master toolchain
Crashing again after
This is also a compiles -ice regression
This never should have passed. Removing regression label; this can remain open to track the ICE.
no longer produces an ICE as of rust 1.81.0