jiebi/CodeConvo huggingface dataset:
Change:
/// They will be used to determine the correct lifetime for the fn return type. /// The `LifetimeElisionCandidate` is used for diagnostics, to suggest introducing named /// lifetimes. <del> lifetime_elision_candidates: Option<FxIndexMap<LifetimeRes, LifetimeElisionCandidate>>, </del> <ins> lifetime_elision_candidates: Option<Vec<(LifetimeRes, LifetimeElisionCandidate)>>, </ins> /// The trait that the current context can refer to. current_trait_ref: Option<(Module<'a>, TraitRef)>,

Discussion:
Instead, this happened: Successful compilation Tested on the playground, all versions and editions. Stable channel: 1.64.0 Beta channel: 1.65.0-beta.3 (2022-10-10 ) Nightly channel: 1.66.0-nightly (2022-10-19 ) I'm labeling this as a regression as I believe it is severe enough of an unplanned change (at best an accidental stabilization?) that I should draw attention to it, even though I haven't found a way to cause miscompilation for example. I also have not tried to do so at all yet. label +T-compiler +A-lifetimes +regression-from-stable-to-stable <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2022-01-01 to nightly-2022-10-01 regressed nightly: nightly-2022-07-26 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
claim
Actually, this behavior is correct as : There is exactly one lifetime used in the parameters (), so assigning it to the output lifetime is as expected. release-assignment
That verbiage but it compiles on no stable version of rustc prior to 1.64, so I don't think it's actually relevant. (The reference is also explicitly non-normative.) mirrors in specifying input positions, not counts. Regardless of documentation, as something that has not compiled on Rust 1.0--1.63 but compiles today, this is clearly a change in language behavior without FCP which I believe to be unintentional. label +T-lang
Ok, so we will consider this for now a regression that should be backported to stable (we're ~2 weeks away from the new release). WG-prioritization assigning priority (). label -I-prioritize +P-critical
Filed
Nominating for lang team to figure out what we should do with this. Will also ping on zulip.

Discussed in lang, dropping nomination. Agreement that we want to revert the change in behavior and backport that to 1.65 (and 1.64, but that's not happening given short time window). Considering whether we want to make the behavior change can happen in a follow-up proposal.
Change:
lint_builtin_export_name_fn = declaration of a function with `export_name` lint_builtin_export_name_method = declaration of a method with `export_name` lint_builtin_export_name_static = declaration of a static with `export_name` <ins> lint_builtin_global_asm = usage of `core::arch::global_asm` lint_builtin_global_macro_unsafety = using this macro is unsafe even though it does not need an `unsafe` block </ins> lint_builtin_impl_unsafe_method = implementation of an `unsafe` method lint_builtin_incomplete_features = the feature `{$name}` is incomplete and may not be safe to use and/or cause compiler crashes

Discussion:
Similar to how deny(unsafecode) prevents from being used, it should also prevent blocks from being allowed. If misused, they can do any number of strange and horrible thing simply by being within the crate. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
label +C-bug +T-compiler
I suppose it's probably too late to actually make it require ?
that isn't even currently possible from a syntax perspective because blocks only work as expressions, you can't just put them around a top level item. It would take a whole RFC thing, even separately from global_asm already being stable.
Change:
<ins> // compile-flags: -Z save-analysis fn main() { let _: Box<(dyn ?Sized)>; //~^ ERROR `?Trait` is not permitted in trait object types //~| ERROR at least one trait is required for an object type } </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. --reduced from <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc although I think they might've already seen this?
claim
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. static FOO: uint = FOO; //~ ERROR recursive constant fn main() { let _x: [u8, ..FOO]; // caused stack overflow prior to fix let _y: uint = 1 + { static BAR: uint = BAR; //~ ERROR recursive constant let _z: [u8, ..BAR]; // caused stack overflow prior to fix 1 }; } </ins>

Discussion:
Normally when a static variable has a recursive the definition, the compiler issues an error. However, if the static is used (and not just defined) rustc overflows its stack. This program causes a stack overflow: Stack trace:
Constant checking -- which detects this recursion -- occurs after type checking in the phase order, but type checking needs to evaluate the constant expression in order to find the length of the array type. It looks like strategically inserting a call to in the appropriate place would fix this at the cost of potentially performing the check many times.
After some chatting on IRC, it looks like the best way to fix this is to break the item recursion check out into a separate pass that comes before type checking. This is my first time looking at this part of the compiler, but I'll give it a shot.
This approach looks promising. I need to do a full build/test run and then I can submit a PR.
Fixed.
Change:
<del> Subproject commit 4da2b2149ca1c6a3331260dfcbb2175c51f2842d </del> <ins> Subproject commit 4e44aa010c4c7d616182a3078cafb39da6f6c0a2 </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
Change:
// shouldn't affect `is_sized`. let gcx = self.tcx().global_tcx(); let erased_ty = gcx.lift(&self.tcx().erase_regions(&ty)).unwrap(); <del> if !erased_ty.is_sized(gcx, self.param_env, span) { </del> <ins> if !erased_ty.is_sized(gcx.at(span), self.param_env) { </ins> // in current MIR construction, all non-control-flow rvalue // expressions evaluate through `as_temp` or `into` a return // slot or local, so to find all unsized rvalues it is enough

Discussion:
One example is the method on . Internally it creates a , when it could simply be taking exactly that as an argument. In miri I had to write which just feels a little riddiculous (taking apart the , just to have the method construct it back). There's probably many other similar methods and functions that should be taking a
Can I take this one if no one is working on that ?
it's all yours!
Change:
error[E0728]: `await` is only allowed inside `async` functions and blocks --> $DIR/issue-51719.rs:10:19 | <del> LL |     let _gen = || foo.await; |                -- ^^^^^^^^^ only allowed inside `async` functions and blocks </del> <ins> LL |     let _gen = || foo().await; |                -- ^^^^^^^^^^^ only allowed inside `async` functions and blocks </ins> |                | |                this is not `async`

Discussion:
Hi I'm pretty new to rust and programming in general. I was trying (failing) to write some toy async code and I got this internal compiler error, the theme seems to be always report ICEs so here we go This was from cargo: ~ The code I was trying was this code: ~ <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Minimized:
ICEs with any statement between while inside a function that isn't async ICE Error without and without the ICE statement inside async function
claim
This is actually the same as . I think I've got a fix for both.
do you have a PR for this open?
Closing as a duplicate of , both of which are fixed by

<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Not had a lot of time to look at this unfortunately and it appears has come up with a fix in in the meantime. release-assignment
claim
assign (Sorry for the noise, testing a new GH feature)
Change:
let filename = format!("rust-dev-nightly-{}.tar.xz", builder.build.build.triple); let tarball = rustc_cache.join(&filename); if !tarball.exists() { <del> builder.download_component(base, &format!("{}/{}", url, filename), &tarball); </del> <ins> let help_on_error = "error: failed to download llvm from cin nhelp: old builds get deleted after a certain time nhelp: if trying to compile an old commit of rustc, disable `download-ci-llvm` in config.toml: n n[llvm] ndownload-ci-llvm = false n "; builder.download_component(base, &format!("{}/{}", url, filename), &tarball, help_on_error); </ins> } let llvm_root = builder.config.ci_llvm_root(); builder.unpack(&tarball, &llvm_root, "rust-dev");

Discussion:
I accidentally missed this when porting it to rustbuild: It would be nice to add it back. Mentoring instructions: Add a new parameter to and pass it down from : This code moved around in so you may want to base your changes off that PR until it lands. label +E-easy +E-mentor +A-rustbuild <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Please also remove the dead code from at the same time:
claim
Change:
<ins> // Regression test for // https://github.com/rust-lang/rust/issues/67945#issuecomment-572617285 // Make sure we don't emit an E0277 error. // revisions: full min #![cfg_attr(full, feature(generic_const_exprs))] #![cfg_attr(full, allow(incomplete_features))] struct Bug<S> { //[min]~ ERROR: parameter `S` is never used A: [(); { //[full]~ ERROR: overly complex generic constant let x: Option<S> = None; //[min]~^ ERROR: generic parameters may not be used in const operations 0 }], } fn main() {} </ins>

Discussion:
The following ICE's on nightly and beta: <details<summaryBacktrace:</summary</details
Reduced: ICE most likely occurs in: I cannot seem to reproduce this without an , so cc
Reduced even more: (Please include all 3 variants thus far in a regression test.)
I looked into this briefly and found that on this line: has the value: Digging a bit deeper, the generics appear to be empty because of the following lines: I can confirm that adding makes this code compile, so I suspect that this is blocked on .
What would be the consequences of always returning the DefId?
It causes query cycle errors at the moment.
Discussed at T-compiler meeting. Due to all the known examples being compile-time errors, the ICE here does not seem so strong a hazard as to warrant weekly visits during triage. (Certainly failing more gracefully would be great. But its not something we're going to e.g. block a release on.) Downgrading priority to P-medium.
Some relevant examples. This gives an (incorrect) error on stable that does not hold: This ICEs on stable:
Is there a reason why we can't just disallow type parameters from appearing within constants during resolve, like we do for type parameters from outer functions? Obviously const generics/lazy normization willl loosen this rule.
good point, I imagine that might work.
Another variant on this bug:
Triage: The two examples that Centril posted ( and ) are no longer ICEs in the latest nightly. Possibly related to ?
Maybe we should just add tests then?
Sounds good! I'll do later.
Another variant (though likely the same): This gives a different to the original, despite being essentially the same code.
Triage: All the snippets including the original are no longer ICE with the latest nightly:
Change:
use cmp::Ordering; use fmt::{self, Debug, Display}; use marker::Unsize; <ins> use mem; </ins> use ops::{Deref, DerefMut, CoerceUnsized}; <del> /// A mutable memory location that admits only `Copy` data. </del> <ins> /// A mutable memory location. </ins> /// /// See the [module-level documentation](index.html) for more. #[stable(feature = "rust1", since = "1.0.0")]

Discussion:
broke a library of mine where I had code like this: calls that used to call this trait method now call the new inherent method, but since that’s unstable the crate didn’t build until I . After that I could remove the trait since the new method has the same behavior. Anyway, this is just FYI. If we don’t want this kind of breakage we can’t add any new method to existing types ever, so that doesn’t sound viable. If the new method had had different behavior or if I wanted to keep supporting older compilers, it wouldn’t be too hard to rename my trait’s method or use UFCS.
Yeah in general we reserve the right to break downstream code with differences in method resolution because the downstream code can always be written in an "elaborated" form which works on all compilers (e.g. using ufcs). If a change to the standard library breaks an excessive amount of code in the ecosystem, though, then we'd need to take the steps much more purposefully.
Sounds good. Again, I don’t expect anything to change here and only made the previous comment to let people know this happened. I made this particular crate as an experiment, I don’t know of anyone actually using it.
Given that the core changes to the bounds on existing methods were instantly stable, it doesn't make a lot of sense to keep and as unstable. I propose we immediately stabilize these APIs. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, 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.
ping (checkbox)
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.
What’s the next step here? Batch stabilization PR near the end of the release cycle?
Yep, I'm preparing one right now.
Change:
// trait impls for private items should be stripped clean::ImplItem(clean::Impl{ <del> for_: clean::ResolvedPath{ did, .. }, .. </del> <ins> for_: clean::ResolvedPath{ did, is_generic, .. }, .. </ins> }) => { <del> if did.is_local() && !self.access_levels.is_exported(did) { </del> <ins> if did.is_local() && !is_generic && !self.access_levels.is_exported(did) { </ins> return None; } }

Discussion:
has the implementation which is It is however , so rustdoc does the correct thing after doc inlining. This bug with blanket impls shows up in user's crates, ; for example the trait in itertools does not have its blanket impl visible in the docs.
It regressed on nightly, it also disappeard from the libstd page.
The regression is not due to specialization, see e.g. vs which does not use specialization. Regression is also visible on beta btw.
hmm, is this bug affecting me? , corresponding
Yes, it's the same bug.
thanks. a bit confusing, since that impl is the whole point of my crate :smile:
The regression was already fixed in
Change:
<ins> trait Mumbo { fn jumbo(&self, x: @uint) -> uint; } impl uint: Mumbo { // Note: this method def is ok, it is more accepting and // less effecting than the trait method: pure fn jumbo(&self, x: @const uint) -> uint { *self + *x } } fn main() { let a = 3u; let b = a.jumbo(@mut 6); let x = @a as @Mumbo; let y = x.jumbo(@mut 6); //~ ERROR values differ in mutability let z = x.jumbo(@6); } </ins>

Discussion:
Right now, a fn implementing an iface method must match the purity of the iface method exactly. This is too strict. We should allow a pure fn to implement an impure fn, and both pure/impure to implement an unsafe fn. UPDATE: Updated title to reflect the real problem here. There is a FIXME in the code in the relevant area. If one declares a trait like: then in the impl, the method should take one type parameter with an bound. We don't really check this correctly though. As far as I can tell, we just check that has one type parameter with one bound, but not precisely what kind of bound it is.
Similarly, in , we require that the bounds on the method parameters be precisely equivalent, which is stronger than necessary. It is sufficient (I believe) that the bounds on the trait be stronger than the bounds on the implementation.
Is this still an issue? It seems to be fixed now.
Still an issue with respect to type parameter bounds.
I don't believe this is backwards incompatible, renominating.
accepted for feature-complete milestone
The following appears to work, but I assume that this is what was talking about:
triage bump. nothing to add.
Accepted for P-backcompat-lang
Added UPDATE to main bug description above.
I had a look at this issue and tried to create a test case. does test case covers the issue you mentioned? This test case fails because it seems like the parameter types are checked in
what error does it fail with? In the you need to use a different type bound for in order to test this issue. To be more precise, the bounds of the implementation should be implied by the bounds of the trait. For example, this should fail:
thanks for the hint, I guess your updated example should indeed test this issue. I'll start working on a patch.
Change:
} #[derive(Diagnostic)] <ins> #[diag(passes_unstable_attr_for_already_stable_feature)] pub(crate) struct UnstableAttrForAlreadyStableFeature { #[primary_span] #[label] #[help] pub span: Span, #[label(passes_item)] pub item_sp: Span, } #[derive(Diagnostic)] </ins> #[diag(passes_missing_stability_attr)] pub(crate) struct MissingStabilityAttr<'a> { #[primary_span]

Discussion:
This should probably not be accepted: is already stable, so having an unstable function under this feature makes no sense. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Should we also reject features that don't exist? Right now, this test would fail (because it would compile without problems)
"unstable" attributes is how library features come into existence. So yes we should accept features that do not yet exist.
Change:
<ins> warning[E0170]: pattern binding `Bar` is named the same as one of the variants of the type `Foo` --> $DIR/issue-67776-match-same-name-enum-variant-refs.rs:17:9 | LL |         Bar => {}, |         ^^^ help: to match on the variant, qualify the path: `Foo::Bar` warning[E0170]: pattern binding `Baz` is named the same as one of the variants of the type `Foo` --> $DIR/issue-67776-match-same-name-enum-variant-refs.rs:19:9 | LL |         Baz => {}, |         ^^^ help: to match on the variant, qualify the path: `Foo::Baz` warning[E0170]: pattern binding `Bar` is named the same as one of the variants of the type `Foo` --> $DIR/issue-67776-match-same-name-enum-variant-refs.rs:26:9 | LL |         Bar => {}, |         ^^^ help: to match on the variant, qualify the path: `Foo::Bar` warning[E0170]: pattern binding `Baz` is named the same as one of the variants of the type `Foo` --> $DIR/issue-67776-match-same-name-enum-variant-refs.rs:28:9 | LL |         Baz => {}, |         ^^^ help: to match on the variant, qualify the path: `Foo::Baz` warning[E0170]: pattern binding `Bar` is named the same as one of the variants of the type `Foo` --> $DIR/issue-67776-match-same-name-enum-variant-refs.rs:35:9 | LL |         Bar => {}, |         ^^^ help: to match on the variant, qualify the path: `Foo::Bar` warning[E0170]: pattern binding `Baz` is named the same as one of the variants of the type `Foo` --> $DIR/issue-67776-match-same-name-enum-variant-refs.rs:37:9 | LL |         Baz => {}, |         ^^^ help: to match on the variant, qualify the path: `Foo::Baz` </ins>

Discussion:
<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This lint was generated by : as we can see is just ignored, so the fix is pretty easy, just all the refs in the type of .
claim
Change:
<ins> // issue: 113596 #![feature(type_alias_impl_trait)] trait Test {} struct A; impl Test for A {} struct B<T> { inner: T, } impl<T: Test> Test for B<T> {} type TestImpl = impl Test; fn test() -> TestImpl { A } fn make_option() -> Option<TestImpl> { Some(test()) } fn make_option2() -> Option<TestImpl> { let inner = make_option().unwrap(); Some(B { inner }) //~^ ERROR concrete type differs from previous defining opaque type use } fn main() {} </ins>

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: I expected to see this happen: compile error that said the return type is wrong. Instead, this happened: compiled without 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. --:
cc

edit: minimized see for more details <!-- 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: I expected to see this happen: Compilation should fail, because different generator types should be generated by calling , meaning and should not share the same type . Instead, compilation passes, and occurs during runtime: More context: <!-- 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<summaryNo Backtrace from running it</summary<p</p</details
label +F-typealiasimpl_trait +I-unsound +T-compiler
Only possible with unstable feature label -I-prioritize
it would be good to have an example which does not depend on external crates or macros here.
slightly minimized completely minimized: + incorrectly ignoring recursive definitions, writing a clean MVCE rn
constrains to , which gets ignored because of I am not totally sure how this all interacts, would have to look at the code, but it feels like the same root cause as