jiebi/CodeConvo huggingface dataset:
Change:
<ins> error[E0425]: cannot find value `Foo` in this scope --> $DIR/layout-error.rs:21:17 | LL |         let a = Foo; |                 ^^^ not found in this scope error: aborting due to previous error For more information about this error, try `rustc --explain E0425`. </ins>

Discussion:
See below:
Reduced to only use the task proc-macro: It seems important, that Foo isn't defined, if I define a , the ICE goes away.
searched nightlies: from nightly-2020-06-01 to nightly-2021-01-01 regressed nightly: nightly-2020-10-27 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: </detailsI'm pretty sure that isn't at fault here, but instead it just uncovers the problem.
MCVE:
Panic location:
Change:
/// assert_eq!(x.eq(&y), false); /// ``` /// <del> /// [`Eq`]: Eq </del> /// [`eq`]: PartialEq::eq /// [`ne`]: PartialEq::ne #[lang = "eq"]

Discussion:
In the documentation for [][1], you will find the following: The link on this page is not actually a link to the trait, but a link to the method on the same page. The link is written as [] with an []: PartialEq::eq in the same doc-comment, so I am unsure whether this should be considered an issue in the documentation, or in rustdoc. [1]: [2]: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
}); } }; <del> fragment_kind.expect_from_annotatables(items) </del> <ins> if fragment_kind == AstFragmentKind::Expr && items.is_empty() { let msg = "removing an expression is not supported in this position"; self.cx.span_err(span, msg); fragment_kind.dummy(span) } else { fragment_kind.expect_from_annotatables(items) } </ins> } Err(mut err) => { err.emit();

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
modify labels: +regression-from-stable-to-stable Had to uninstall ~20 gigs of rustc releases again but since this code does not ICE on 1.20 but ices on 1.48.0, this is a stable-to-stable ice.
This started ICE'ing in 1.30.0. Error message in 1.29.0:
This is not supposed to work yet and it gives a good error message saying so -P-low Assigning and removing as in the prioritization working group.
The error message is helpful but it still panics in nightly. Do we want to fix the ICE at least or keep it?
A possible duplicate.
Fixed in
Change:
} #[test] <del> fn test_insert_prev() { let mut m = list_from(&[0, 2, 4, 6, 8]); let len = m.len(); { let mut it = m.iter_mut(); it.insert_next(-2); loop { match it.next() { None => break, Some(elt) => { it.insert_next(*elt + 1); match it.peek_next() { Some(x) => assert_eq!(*x, *elt + 2), None => assert_eq!(8, *elt), } } } } it.insert_next(0); it.insert_next(1); } check_links(&m); assert_eq!(m.len(), 3 + len * 2); assert_eq!(m.into_iter().collect::<Vec<_>>(), [-2, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1]); } #[test] </del> #[cfg_attr(target_os = "emscripten", ignore)] fn test_send() { let n = list_from(&[1, 2, 3]);

Discussion:
This is a tracking issue for the unstable methods in the standard library. cc perhaps you can fill this in some more? The specific methods in question are: -
This is basically a lame version of cursors, which is what we should use instead imo. It's not 1:1 though -- this api lets you have all the elements yielded at once. Classic iterator tradeoff.
Triage: these are still unstable.
There are some ideas for a more complete API in
seems misnamed. Doesn't it do exactly what we call elsewhere?
I'm going to echo thoughts: An iterator conceptually represents a (double-ended) range of elements. The only operation that it supports is popping an element off the end of that range. A cursor on the other hand represents a position in a collection, and can be moved backwards or forwards in the collection. The cursor can be used to insert or remove an element at any given position in the collection. I strongly oppose adding insertion/deleting methods to since they do not fit at all with existing iterator usage patterns ( loops and functional-style methods). As I mentioned in the linked thread, a design based on the types in could be used.
Since we now have cursors, I think these methods should be removed.
Reopening since we only deprecated the methods instead of removing them. I'd say give it about 2 weeks then remove them.
Change:
} /// Extracted collection of all the summary statistics of a sample set. <del> #[derive(Clone, PartialEq)] </del> <ins> #[derive(Clone, PartialEq, Copy)] </ins> #[allow(missing_docs)] pub struct Summary { pub sum: f64,

Discussion:
functions are run multiple times. Some benchmark functions might depend on some runtime initialisation which may fail. For example: Will print “Benchmarks on even hours are forbidden!” a lot of times. If one opts to not report set-up failure, the benchmark function just keeps processor hot for a while without actually benchmarking anything (and reporting 0ns/iter anyway). Would it be sensible to (one of possible solutions): Not run the same function multiple times, since iteration is done by ; Not run the same again if is not called at least once; Provide a method on to cancel all subsequent runs of the function? Or maybe my approach is incorrect?
If one tries to keep benchmarks in separate files and opts for to cancel further runs of the function, the panic will abort the whole benchmark process (i.e. including the benchmarks in other executables).
For , we want to run on the CI infrastructure to ensure all the tests build. However, we don't want to actually benchmark on the CI infrastructure, because the CI infrastructure isn't reliable enough for benchmarking. Thus, doing more than one iteration on the CI infrastructure just wastes time. And, that time, in particular the wall time, negatively affects my other repos, because generally CI services like Travis CI and Appveyor only allow one project to build at a time, for their free open source tiers. Further, even out side of CI infrastructure, we want contributors to run the benchmarks before sending PRs. But, it's not reasonable to expect them to wait through many minutes of perf tests before asking for a PR. Here are two ideas: a that overrides the default targeted benchmark execution time so that we can write to run tests once. a so we can write . I prefer because that also might help with
Never mind. I just learned that will do exactly what I want: run the benchmarks once each.
This was bugging me, so I implemented the first proposed option: As this is my first real rust code, I imagine its pretty bad quality. A fist attempt is here: I'll clean it up a bit, give it some more testing, then send in a pull request unless anyone offers any opinions before I get that far.
Does anyone have an example on how to use this feature ? I'd like to run a benchmark only once.
:frowning_face:
Change:
// //   `(size + (align-1)) & -align` let one = bx.const_usize(1); <del> let addend = bx.sub(align, one); let add = bx.add(size, addend); let neg = bx.neg(align); let size = bx.and(add, neg); </del> <ins> let addend = bx.sub(full_align, one); let add = bx.add(full_size, addend); let neg = bx.neg(full_align); let full_size = bx.and(add, neg); </ins> <del> (size, align) </del> <ins> (full_size, full_align) </ins> } _ => bug!("size_and_align_of_dst: {t} not supported"), }

Discussion:
Execute with Miri: The problem is that and do not take the reduced field alignment into account and calculate the offset as-if the standard alignment was in place.
The labels are incorrect. Neither does this require nightly, nor is it related to const-eval. This is I-unsound on stable.
label I-prioritize (Looks like can't set .)
Error: Label can only be set by Rust team members Please let know if you're having trouble with this bot.
Error: Parsing relabel command in failed: ...'const-eval' ' "I-unsoun'... Please let know if you're having trouble with this bot.
Assigning as discussed as part of the and removing .
label -I-prioritize +P-medium
labels -T-types Discussed in types team on-site -- we think this is a MIR building bug, in any case, not part of T-types. Throwing hot back to compiler team.
It was actually a bug in the codegen backend, introduced when support for was -- the existing code has logic that assumed "if it is packed then alignment is 1", and that was never re-visited.
Ah, scratch that -- there was a different related bug (the sizeofval / alignofval computation for packed structs with tail was wrong), caused by what I said above. This here was caused by the codegen backend just never considering packed types when computing the offset of the unsized field. Almost always this happened to work since the unsized field is a slice/str and so its alignment (and therefore its offset) is dynamically known, but when dyn trait tails are involved this starts to go wrong. This got fixed by ; will add a test.
Change:
pub static V: &u32 = &X; pub static F: fn() = f; <ins> pub static G: fn() = G0; </ins> static X: u32 = 42; <ins> static G0: fn() = g; </ins> pub fn v() -> *const u32 { V } fn f() {} <ins> fn g() {} </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. --Sorry, haven't tried to minimise this yet. The repro steps are here: <!-- 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. --: Also reproduces in <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Hoisting the inline structure initialisation into s makes the ICE go away. That... doesn't make a lot of sense to me. <details<summary<strongDiff</strong</summary<p</p</details
Also reproduces in which is our current MSRV
The implementation here should probably also recurse into :
I can confirm that the ICE goes away with the suggested patch.
Possibly related -- while this made the ICE go away, the code when compiled in mode seems to not link. <details<summary<strongmysterious link error</strong</summary<p</p</detailsNaively -- with no understanding of rustc internals -- it feels like a reachability pass that doesn't find these values won't emit them into the library? Slapping some extra attributes around the place is a workaround.
Change:
<ins> // Copyright 2018 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. // Some unusual code minimized from // https://github.com/sile/handy_async/tree/7b619b762c06544fc67792c8ff8ebc24a88fdb98 pub trait Pattern { type Value; } pub struct Constrain<A, B = A, C = A>(A, B, C); impl<A, B, C> Pattern for Constrain<A, B, C> where A: Pattern, B: Pattern<Value = A::Value>, C: Pattern<Value = A::Value>, { type Value = A::Value; } pub struct Wrapper<T>(T); impl<T> Pattern for Wrapper<T> { type Value = T; } // @has self_referential/struct.WriteAndThen.html // @has - '//*[@id="synthetic-implementations-list"]/*[@class="impl"]//*/code' "impl<P1> Send for  // WriteAndThen<P1>  where  <P1 as Pattern>::Value: Send" pub struct WriteAndThen<P1>(pub P1::Value,pub <Constrain<P1, Wrapper<P1::Value>> as Pattern>::Value) where P1: Pattern; </ins>

Discussion:
When I tried to build docs for , I got a panic. Here is the reduced test case: With the above code, when I run I get this panic: rustc 1.27.0-nightly ( 2018-04-18) binary: rustc commit-hash: commit-date: 2018-04-18 host: x86_64-pc-windows-msvc release: 1.27.0-nightly LLVM version: 6.0
Strange... Will take a look as soon as possible.
So the call is performed . I'll need help from (or anyone in the team who knows about the type) in order to fix this issue.
Reduced further:
I'd like to work on this.
Thank you so much! I verified that with the latest Rust Nightly I no longer get any errors.
Change:
LL |     fn g(&self); |     ---^-------- help: remove these associated items <del> error[E0599]: the method `g` exists for reference `&Self`, but its trait bounds were not satisfied --> $DIR/issue-105732.rs:9:14 </del> <ins> error[E0599]: no method named `g` found for reference `&Self` in the current scope --> $DIR/issue-105732.rs:10:14 </ins> | LL |         self.g(); <del> |              ^ | = note: the following trait bounds were not satisfied: `Self: Foo` which is required by `&Self: Foo` `&Self: Foo` = help: items from traits can only be used if the type parameter is bounded by the trait help: the following trait defines an item `g`, perhaps you need to add a supertrait for it: | LL | trait Bar: Foo { |          +++++ </del> <ins> |              ^ help: there is a method with a similar name: `f` </ins> error: aborting due to 2 previous errors

Discussion:
Given the following The current output is: The second error is not reasonable, since we don't allow associated items in auto trait. Ideally the output should look like: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I spent some time to investigate it, I tried to filter the candidates from auto trait. But seems here have two predicates, and the message for the second error comes from the first : I'm still trying to understand the code.
claim
Change:
|                                   ^ | = note: type arguments must be provided before constant arguments <ins> = help: reorder the arguments: types, then consts: `<T, N>` </ins> error: aborting due to previous error; 1 warning emitted

Discussion:
The current diagnostics are a little ad hoc and rely on counting the number of mismatches (e.g. they will only produce an error for the first mismatch). It would be nice to produce diagnostics like: cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is follow up work for
Please give more context on this. I am not sure the error message of which test should be improved.
This is more of the kind of issue opened to avoid forgetting about finishing some work, sorry for the confusion. That is, this is leaving a TODO to themselves about improving the diagnostics from .
Ok. I see. Thanks for the explanation.
That said, if is too busy to work on this, you could talk to them on Discord or Zulip to see what their plans were, and maybe turn this into a mentored issue.
The idea is essentially this. We currently emit errors telling the user that the generic arguments they provide are in the wrong order: However, what we'd like to do is suggest reordering the parameters, and let rustfix automatically apply the suggestion. I don't have the bandwidth to work on this at the moment, or any time soon, so if anyone is interested in tackling it, I'll be happy to mentor the issue.
would you mind if I take this up?
you're very welcome to! Let me know if you need any guidance in tackling this issue!
claim
Change:
assert!(generics.types.is_empty_in(subst::FnSpace)); assert!(generics.regions.is_empty_in(subst::FnSpace)); <ins> // The type `Foo<T+'a>` is contravariant w/r/t `'a`: let contra = self.contravariant(variance); self.add_constraints_from_region(bounds.region_bound, contra); </ins> self.add_constraints_from_substs( def_id, generics.types.get_slice(subst::TypeSpace),

Discussion:
If you pass an immutable reference through two structs, one of which is a trait, you can take an immutable reference to a variable that will be mutated later, and the compiler will compile. For a proof of concept, see , and if you want to see it in an actual use case, see (look in the main file). I don't know if this is an issue or not, it didn't cause any safety issues when I used it. Is there a rust-ier way of doing the type of thing I did in the second example (allow an immutable reference to a value that will be mutated, in order to see the new value).
The whole thing in one piece: Thanks for filing, these memory safety bugs are very important to catch, however, I think this may be a duplicate of another bug which I cannot find right now (iirc was interacting with those other bugs). I believe the underlying problem here is the function is invalid, the boxing/returning that happens should be disallowed without the having the lifetime too.
FWIW, I’ve reduced the issue a little more ():
Nominating
As I posted on IRC, this is a variance problem - is unsoundly bivariant:
Thanks for cutting it down. I still am not a good Rust programmer, so I was just copying, as close as I could, the original, accidental, version.
cc
P-backcompat-lang, 1.0.
seems to be dup of
I tested and this is indeed fixed by PR . Too bad I didn't look into this bug first rather than , since I see that other people already worked out the variance connection already.
Change:
<ins> error[E0477]: the type `&mut ()` does not fulfill the required lifetime --> $DIR/issue-90014.rs:14:5 | LL |     type Fut<'a> = impl Future<Output = ()>; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | note: type must outlive the lifetime `'a` as defined here --> $DIR/issue-90014.rs:14:14 | LL |     type Fut<'a> = impl Future<Output = ()>; |              ^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0477`. </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. --<!-- 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(F# highlighting looks reasonably nice) </p</details
modify labels +requires-nightly +F-genericassociatedtypes +F-typealiasimpl_trait
GATs issue triage: not blocking. Works on latest nightly; needs test.
label: +E-needs-test
Change:
NO_DEBUG_ASSERTIONS=1 os: osx osx_image: xcode7.3 <del> if: branch = disabled </del> <ins> if: branch = auto </ins> # macOS builders. These are placed near the beginning because they are very # slow to run.

Discussion:
Happened for these PRs so far:
Thanks for the report. This is a Travis CI issue, currently tracked in travis-ci/travis-ci. A temporary workaround that disables all Xcode 7.3 () is currently testing.
Change:
let dirp = cfg.cwd.map(|c| c.with_ref(|p| p)).unwrap_or(ptr::null()); <ins> let cfg = unsafe { mem::transmute::<ProcessConfig,ProcessConfig<'static>>(cfg) }; </ins> with_envp(cfg.env, proc(envp) { with_argv(cfg.program, cfg.args, proc(argv) unsafe { let (mut input, mut output) = try!(pipe());

Discussion:
Example: The last statement is mutably borrowing x but x is already borrowed (or rather should be) by the proc. The result is a program that compiles fine but segfaults when run.
cc Nominating, closure shouldn't be able to capture borrowed variables.
I'm pretty sure the proc "code" needs a thorough review, giving this issue along with all the other similar proc bugs.
cc
P-backcompat-lang, 1.0.
Change:
) } } <del> CodeBlockKind::Indented => LangString::all_false(), </del> <ins> CodeBlockKind::Indented => Default::default(), </ins> }; if !block_info.rust { continue;

Discussion:
is not actually allfalse - will return . It would be nice to rename it to at some point (and maybe add while we're at it). cc Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim I'll either get to it before next week is over or when is merged, whichever comes first
Change:
<ins> warning: unused return value of `f` that must be used --> $DIR/decorate-force-warn.rs:11:5 | LL |     f(); |     ^^^ | = note: requested on the command line with `--force-warn unused-must-use` help: use `let _ = ...` to ignore the resulting value | LL |     let _ = f(); |     +++++++ warning: 1 warning emitted </ins>

Discussion:
Input:
Bisects to Rust 1.55.0, and nightly-2021-07-20. In older stable and nightly releases, this compiles successfully.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
bisection points to rollup If I had to guess, I'd say that looks like the one. It's the only one in the rollup touching diagnostic code. Possibly my reasoning is off (pls correct me).
Something went wrong with your bisect, as is from 2022-02-02, whereas this ICE is present in nightly-2021-07-20. looks the most likely to me.
Either way, this is probably easier to debug from scratch instead of digging around commits. Previous issue with this ICE message should reveal information on how to fix these issues, which arise from eagerly formatting paths in lints instead of only when they're emitted.
Fix for a similar issue :
Change:
let mir_node_id = tcx.hir.as_local_node_id(mir_def_id).expect("non-local mir"); <del> let (return_span, mir_description) = if let hir::ExprKind::Closure(_, _, _, span, gen_move) = tcx.hir.expect_expr(mir_node_id).node { ( tcx.sess.source_map().end_point(span), if gen_move.is_some() { " of generator" } else { " of closure" }, ) } else { // unreachable? (mir.span, "") }; </del> <ins> let (return_span, mir_description) = match tcx.hir.get(mir_node_id) { hir::Node::Expr(hir::Expr { node: hir::ExprKind::Closure(_, _, _, span, gen_move), .. }) => ( tcx.sess.source_map().end_point(*span), if gen_move.is_some() { " of generator" } else { " of closure" }, ), hir::Node::ImplItem(hir::ImplItem { node: hir::ImplItemKind::Method(method_sig, _), .. }) => (method_sig.decl.output.span(), ""), _ => (mir.span, ""), }; </ins> Some(RegionName { // This counter value will already have been used, so this function will increment it

Discussion:
Hi, I'm not sure if this has been reported or is known at all. If it has feel free to close it out. This example: causes an ICE on rustc 1.31.0-nightly ( 2018-10-25) This is the error I'm getting, backtrace included:
Okay, the good news here is that I only see this ICE with ; it does not arise with the NLL migration mode being deployed as part of the 2018 edition. See e.g. this .
The code in question is rejected by AST-borrowck. It looks like it is being rejected by NLL as well, and the problem is that we hit an error when trying to generated our diagnostic. Therefore, I'm going to tag this as NLL-sound (since this seems like a case where we want to reject the code in question) and NLL-diagnostics (since the ICE itself is stemming from diagnostics code). And I think I'm going to make it P-high, because 1. ICE's are super annoying and 2. I bet its not hard to fix. But I'm not going to tag it with the Release milestone, because its not something we need to worry about backporting to the beta channel (because it does not arise with NLL migration mode).
actually I'll remove NLL-sound; this isn't a case where NLL is incorrectly accepting the code. Its just incorrectly behaving while generating the diagnostics.