jiebi/CodeConvo huggingface dataset:
Change:
<ins> // check-pass #![feature(generic_associated_types)] pub trait Fooey: Sized { type Context<'c> where Self: 'c; } pub struct Handle<E: Fooey>(Option<Box<dyn for<'c> Fn(&mut E::Context<'c>)>>); fn tuple<T>() -> (Option<T>,) { (Option::None,) } pub struct FooImpl {} impl Fooey for FooImpl { type Context<'c> = &'c (); } impl FooImpl { pub fn fail1() -> Handle<Self> { let (tx,) = tuple(); Handle(tx) } } fn main() {} </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. --I included the (commented out) workaround I found in case it's helpful. uncomment for a different ICE (Likely a duplicate of ) <!-- 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 --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-incr-comp
claim
Change:
assert_eq!(unsafe { DROPS }, 8); } <ins> #[test] fn test_allocator() { use core::alloc::AllocError; use core::alloc::Allocator; use core::alloc::Layout; use core::cell::Cell; struct A { has_allocated: Cell<bool>, has_deallocated: Cell<bool>, } unsafe impl Allocator for A { fn allocate(&self, layout: Layout) -> Result<NonNull<[u8]>, AllocError> { assert!(!self.has_allocated.get()); self.has_allocated.set(true); Global.allocate(layout) } unsafe fn deallocate(&self, ptr: NonNull<u8>, layout: Layout) { assert!(!self.has_deallocated.get()); self.has_deallocated.set(true); unsafe { Global.deallocate(ptr, layout) } } } let alloc = &A { has_allocated: Cell::new(false), has_deallocated: Cell::new(false) }; { let mut list = LinkedList::new_in(alloc); list.push_back(5u32); list.remove(0); } assert!(alloc.has_allocated.get()); assert!(alloc.has_deallocated.get()); } </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: alloc <addrand dealloc <addris printed Instead, this happened: only alloc <addris printed <!-- 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. --: forgets that it's been initialized with an allocator, and always deletes the node with the global allocator. There seems to be one more place where this happens in the same file. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Change:
let func_ty = func.ty(body, tcx); if let ty::FnDef(callee, substs) = *func_ty.kind() { <del> let (callee, call_substs) = if let Ok(Some(instance)) = Instance::resolve(tcx, param_env, callee, substs) { (instance.def_id(), instance.substs) } else { (callee, substs) }; </del> <ins> let normalized_substs = tcx.normalize_erasing_regions(param_env, substs); let (callee, call_substs) = if let Ok(Some(instance)) = Instance::resolve(tcx, param_env, callee, normalized_substs) { (instance.def_id(), instance.substs) } else { (callee, normalized_substs) }; </ins> // FIXME(#57965): Make this work across function boundaries

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rustfmt 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!
Hi can you please the command to replicate this bug? Thanks
with set in
won't be able to get to this myself in the next few days. To fix this we probably have to compile it with , find the place where we call and put a before that
Hi the error occurred where we just erasing regions by simply doing this (tcx.eraseregions(&traitref)) and provided assertion with (tcx.normalizeerasingregions(paramenv, traitref)). Is this scenario correct? Just want to confirm as you already mentioned to put a tcx.normalizeerasingregions. Thanks
yes, so we do not want to use in as that can be a bit costly but instead normalize eagerly before then. To detect cases where we are still using unnormalized values a debug assert there. If we look at the backtrace we can find out where the is coming from and normalize it there
okay, thanks for the update.
Hi as you mentioned can you please elaborate it please? As I can see the Instace::resolve in but don't get you point to put tcx.normalizeerasing_regions. Thanks
Can you post the resulting backtrace using ?
here it is:
So I think that the easiest fix is to add before this call. I am however surprised that isn't actually normalized here. cc do we want to instead normalize this in mir building?
Change:
<ins> // check-pass // See issue #109356. We don't want a false positive to the `implied_bounds_entailment` lint. use std::borrow::Cow; pub trait Trait { fn method(self) -> Option<Cow<'static, str>> where Self: Sized; } impl<'a> Trait for Cow<'a, str> { // If we're not careful here, we'll check `WF(return-type)` using the trait // and impl where clauses, requiring that `Cow<'a, str>: Sized`. This is // obviously true, but if we pick the `Self: Sized` clause from the trait // over the "inherent impl", we will require `'a == 'static`, which triggers // the `implied_bounds_entailment` lint. fn method(self) -> Option<Cow<'static, str>> { None } } fn main() {} </ins>

Discussion:
The lint is triggered by the following code (from , cc : In the environment , the type surprisingly requires for well-formedness (see ), but this constraint is not used in implied bounds, so I believe it can't be exploited for unsoundness. The lint was upgraded to deny-by-default in the current beta (1.68.0-beta.5 2023-02-15 ). So this counts as regression? cc label C-bug T-types T-compiler regression-from-stable-to-beta
:facepalm: I think this is due to us preferring param-env candidates for .
So the issue here is that requires . We try to prove that in the hybrid param-env of the impl's WC + trait method's WC, being after substituting . Due to some frustrating precedence rules around candidate assembly in the trait solver, we try to match against the param-env candidate and get . We also assemble a built-in sized bound, but always prefer the param-env candidate over that. That requires us to prove , which is not known to be true in the hybrid param-env, triggering the lint.
I wonder if we could get away with not checking , but just the implied lifetime bounds or something :thinking:
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Been thinking about this a little bit. One thought I had was to check that the impl method is WF given only the trait method, but I think that would break this example: I wonder if we could get away with not checking WF(return-type), but just the implied lifetime bounds or something This is annoying difficult, because it's not straightforward to get "just the implied lifetime bounds" of a type. I'm playing around with using and filtering outlives bounds, but that can generate more predicates (which, I thought we had somewhere a function that recurses though those). We'll see if this works...
Change:
mbcx: &'visit mut MirBorrowckCtxt<'cx, 'gcx, 'tcx>, } <ins> impl GatherUsedMutsVisitor<'_, '_, '_, '_> { fn remove_never_initialized_mut_locals(&mut self, into: &Place<'_>) { // Remove any locals that we found were initialized from the // `never_initialized_mut_locals` set. At the end, the only remaining locals will // be those that were never initialized - we will consider those as being used as // they will either have been removed by unreachable code optimizations; or linted // as unused variables. if let Some(local) = into.base_local() { let _ = self.never_initialized_mut_locals.remove(&local); } } } </ins> impl<'visit, 'cx, 'gcx, 'tcx> Visitor<'tcx> for GatherUsedMutsVisitor<'visit, 'cx, 'gcx, 'tcx> { fn visit_terminator_kind( &mut self,

Discussion:
(sorry if this is an duplicate or the wrong repo :innocent: ) () Current behavior: no warning Expected behavior: The variable clearly doesn't need to be mutable, still, nothing is detected and no warning is emitted. Rust 1.35.0 (Using the , also in ())
The warning appears again if you switch to 2015 edition. Huh. Nice catch!
I found that Stable 2015 edition produces the warning and everything else doesn't.
cc (likely caused by NLL migrate mode, which was enabled in for the 2015 edition)
Yes, looks like another nll bug. If someone wants to have a go at this, the issue is that we are treating DropAndReplace differently to Assign for the purposes of this lint.
I can try doing it I just don't know here to begin.
I don't know this code too well, but take a look at . The first thing I'd try is adding a case for to the match in that mirrors what's done for .
Makes sense thank you. I was looking at librustc_lint and couldn't find anything.
Change:
let type_start = own_start - has_self as u32 + params.len() as u32; let mut i = 0; <ins> const TYPE_DEFAULT_NOT_ALLOWED: &'static str = "defaults for type parameters are only allowed in  `struct`, `enum`, `type`, or `trait` definitions"; </ins> params.extend(ast_generics.params.iter().filter_map(|param| match param.kind { GenericParamKind::Lifetime { .. } => None, GenericParamKind::Type { ref default, synthetic, .. } => { <del> if !allow_defaults && default.is_some() { if !tcx.features().default_type_parameter_fallback { tcx.struct_span_lint_hir( lint::builtin::INVALID_TYPE_PARAM_DEFAULT, param.hir_id, param.span, |lint| { lint.build( "defaults for type parameters are only allowed in  `struct`, `enum`, `type`, or `trait` definitions", ) .emit(); }, ); </del> <ins> if default.is_some() { match allow_defaults { Defaults::Allowed => {} Defaults::FutureCompatDisallowed if tcx.features().default_type_parameter_fallback => {} Defaults::FutureCompatDisallowed => { tcx.struct_span_lint_hir( lint::builtin::INVALID_TYPE_PARAM_DEFAULT, param.hir_id, param.span, |lint| { lint.build(TYPE_DEFAULT_NOT_ALLOWED).emit(); }, ); } Defaults::Deny => { tcx.sess.span_err(param.span, TYPE_DEFAULT_NOT_ALLOWED); } </ins> } }

Discussion:
I tried this code: I expected to see this happen: It not work correctly as if you remove it shouts at you saying its unsupported and will be a hard error one day. Instead, this happened: defaults on GATs seem to function perfectly fine version from playground: cc this is probably should either be allowed or a hard error before stabilisation?
one issue is that we ignore defaults on the gat in impls
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
.unwrap_or(false); let (res, self_ctor_substs) = if let Res::SelfCtor(impl_def_id) = res { <del> let ty = self.impl_self_ty(span, impl_def_id).ty; let adt_def = ty.ty_adt_def(); </del> <ins> let ty = self.normalize_ty(span, tcx.at(span).type_of(impl_def_id)); </ins> match ty.kind { ty::Adt(adt_def, substs) if adt_def.has_ctor() => { let variant = adt_def.non_enum_variant();

Discussion:
Summary from : used as a tuple-struct constructor function should use the fully type-substituted form from the block, but does not. Thus, today this code is accepted, but it should not be. (Fixing this would be a breaking-change, so we should take care in how we deploy it.) Original bug report follows: <!-- 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: In nightly rustc, compiles while yields a type mismatch error:
The one is incorrect, has all its generic parameters substituted, i.e. it's / in both cases, type or constructor function.
To be 100% clear here: I believe what is saying is that the compiler has a bug, and that the bug is that the code should be treated as a short-hand for: and thus should be yielding the same error that one sees for the cases in the code from the description. However, the code is not yielding an error at all.
T-compiler triage: leaving nominated for T-lang. Tagging as P-high priority to resolve whether the semantics described by is indeed what we want, and if so, how to address deploying a breaking-change to fix it.
cc I thought we had fixed this bug in (and to be clear, it's clearly a bug (as noted by in ). It should not compile.
Just to simplify a bit (still passes but shouldn't):
Just checked on godbolt and it seems to compile in every stable release since it was stabilized (). I haven't looked into the code again, but I don't really understand how didn't cover this. Did we forget to add a test with errors, and only tried to prevent ICEs, or something?
Change:
<ins> //@ edition:2021 //@ compile-flags:--test //@ aux-build:bad_on_unimplemented.rs // Do not ICE when encountering a malformed `#[diagnostic::on_unimplemented]` annotation in a // dependency when incorrectly used (#124651). extern crate bad_on_unimplemented; use bad_on_unimplemented::Test; fn breakage<T: Test>(_: T) {} #[test] fn test() { breakage(1); //~ ERROR E0277 } </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. --The simplest version uses / however I have also tested this via a sub-crate. : : <!-- 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. --: I can also reproduce this on and on and . When running <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
cc
Change:
write!(w, "<div class="sub-variant" id="{id}">", id = variant_id); write!( w, <del> "<h3>Fields of <b>{name}</b></h3><div>", name = variant.name.as_ref().unwrap() </del> <ins> "<h3>{extra}Fields of <b>{name}</b></h3><div>", extra = if s.struct_type == CtorKind::Fn { "Tuple " } else { "" }, name = variant.name.as_ref().unwrap(), </ins> ); for field in &s.fields { use crate::clean::StructFieldItem;

Discussion:
Rustdoc should expose doc comments written on tuple fields: Tagging based on conversation on IRC.
This issue also applies to tuple variant fields:
It promises to be very interesting from a design point of view. We'll to think about how to render this nicely.
Change:
llvm_dylib_path.display(), e); }); <del> let dst_libdir = image.join("lib"); </del> <ins> let dst_libdir = image.join("lib/rustlib").join(&*target).join("lib"); </ins> t!(fs::create_dir_all(&dst_libdir)); builder.install(&llvm_dylib_path, &dst_libdir, 0o644);

Discussion:
Short description: I am building for a environment using , and the embedded as my linker of choice. The linker fails to load since it depends on a dynamic library that doesn't actually exist. Rolling back to works
Searching the source tree for turns up some humorous comments...
I have this issue too!
I believe this issue is caused by : "Link LLVM tools dynamically...". It only enables dynamic linking on Linux and Mac OS, and since no Windows users complained so far I can only assume it's the probable cause. <hr/Speaking of which, it might be a good idea to add testing the built LLVM tools / LLD to Rust's CI, to ensure issues like this are caught earlier on.
this may have been caused by . Also, I don't see this issue on Linux:
I keep my toolchain updated with rustup, yet it seems I don't have ...? output:
it seems that is provided by the component which I have installed. Try running and see if that fixes LLD. it sounds like should always by shipped with the compiler since rust-lld depends on it.
I installed them, but it didn't help. The LLVM tools do seem to work, and I now have the library in the directory. However, checking rust-lld's RPATH shows , i.e. it points to . Doing does (temporarily) fix the problem.
I'm working on a fix for this!
diagnosis is spot on and this should be fixed in To recap, interim fixes include: Downgrading to an older nightly temporarily
Thanks,
Doesn't work for me on macOS by the way.
Edit I was wrong. It's still nightly I get this with stable rust too (1.28.0):
only just had all of the features it relies on stabilize, so it is still nightly-only until those newly-stabilized features ride the release trains from nightly -beta -stable.
thanks for pointing out. I just noticed that it is using nightly version. I am new to rust, so I have no idea how to rollback to previous nightly version to use as a workaround.
For future reference, you can use rustup to install any nightly, for instructions see .
Still getting this issue on the latest nightly:
It seems to work fine for me (on arch linux)
I agree with It is still not working on macOS.

Seems like a number of people (including myself) are still having this issue, can we re-open?
Apparently did not fix this entirely on Mac OS X.
I'm working on a fix for this and should be able to post it soon
I'm getting this on Linux too: https://travis-
Thanks for your super-fast help,
For anyone wondering, the osx fix is not on the current nightly – – yet.
Why's this issue closed then?
Is it because the fix will be in tomorrow's nightly build?
Yes this fix missed last night's nightly but it should be in tonight's nightly!
I'm still getting this error with .
Looks like there's at least one more bug to fix --
Finally, I managed to compile on a mac with the latest nightly build of rust!
Change:
def count(t): return sum(map(lambda (f, s): len(s.get(t, [])), summaries)) logfiles = sys.argv[1:] <del> map(summarise, logfiles) </del> <ins> for files in map(glob.glob, logfiles): map(summarise, files) </ins> ok = count('ok') failed = count('failed') ignored = count('ignored')

Discussion:
On OS X at least, it will think the link itself is the executable, then calculate sysroot based on that. Thanks to kyle for the report.
nominating to change to production ready
accepted for production-ready milestone
triage bump. still annoying.
or could be used to resolve the symlink. Would this issue warrant the badge "E_easy"?
Seems so! Adding the E-easy label.
Note that the relevant code is and it probably needs a check to see whether is a symlink or not.
seems important to fix for polish reasons. Accepted for P-high.
Change:
<del> //@ check-pass #![warn(unnameable_types)] //~ WARN unknown lint fn main() {} </del>

Discussion:
This is a tracking issue for the RFC "Type privacy and private-in-public lints " (rust-lang/rfcs). Steps: [ ] Implement the RFC (cc ) [ ] Adjust documentation ([see instructions on forge][doc-guide]) [ ] Stabilization PR ([see instructions on forge][stabilization-guide]) [stabilization-guide]: [doc-guide]: Unresolved questions: [ ] It's not fully clear if the restriction for associated type definitions required for type privacy soundness, or it's just a workaround for a technical difficulty. [ ] Interactions between macros 2.0 and the notions of reachability / effective visibility used for the lints are unclear. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Oops - I didn't mean for that to un-assign you. Is there a way to prevent these lints from becoming insta-stable? Would it make sense to put them behind a feature gate?
Perhaps we could only fire the lints if an unstable compiler flag (maybe ) is passed? This would still make the lint names insta-stable, though.
in core ffi There is a fixme about , how to fixes that?
By implementing this RFC, I guess. Until that workarounds like this sealed trait will need to be used.
Where is the impl, the RFC is already accepted...
An RFC being accepted just means the feature can be implemented, not that it has been implemented. It doesn't even mean that implementing it is a priority. I believe there has been more discussion of this RFC over at as well as other issues that I can't seem to track down right now.
Hello! I know y'all are busy, but I'm curious if there's an update, particularly on for Voldemort Types - which I'd love to see. I was actually a bit surprised to find that it wasn't included in the existing lint. Appreciate the work that y'all are doing, especially who seems to have put in a lot of legwork.
The tentative plan is that will work on this in March-May.
Cool! Good luck! I'm happy to be a guinea pig to try it out or do code review if that would be helpful.
This issue should be closed by Two follow up issues about improving the effective visibility tables
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. #![feature(unboxed_closures)] // Test generating type visitor glue for unboxed closures extern crate debug; fn main() { let expected = "fn(); fn(uint, uint) -> uint; fn() -> !"; let result = format!("{:?}; {:?}; {:?}", |:| {}, |&: x: uint, y: uint| { x + y }, |&mut:| -> ! { fail!() }); assert_eq!(expected, result.as_slice()); } </ins>

Discussion:
Here is the code: and the produced error:
The type visitor glue generation code does not support unboxed closures: A quick fix would mimic the visitor glue for boxed closures. Ideally, the interface could be extended to handle unboxed closures separately, which would allow for visting upvars in the closure environment.
Working on the quick fix
Closing as a dupe of
Change:
<ins> // https://github.com/rust-lang/rust/pull/83872#issuecomment-820101008 #![crate_name="foo"] mod sub4 { /// 0 pub const X: usize = 0; pub mod inner { pub use super::*; /// 1 pub const X: usize = 1; } } #[doc(inline)] pub use sub4::inner::*; // @has 'foo/index.html' // @has - '//div[@class="item-right docblock-short"]' '1' // @!has - '//div[@class="item-right docblock-short"]' '0' fn main() { assert_eq!(X, 1); } </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. --If glob reexport reexports module and there is already module , the documentation duplicates. Current behaviour: ! ( module is duplicated, though both module links point to as expected) The expected behaviour: module is only shown once. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim
Change:
Ok(literal) => acc.push(ReprPacked(literal)), Err(message) => literal_error = Some(message), }; <del> } else if matches!(name, sym::C | sym::simd | sym::transparent) </del> <ins> } else if matches!(name, sym::Rust | sym::C | sym::simd | sym::transparent) </ins> || int_type_of_word(name).is_some() { recognised = true;

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: unrecognized representation hint', 'error: internal compiler error: unrecognized representation hint' File: --snippet: 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: --
Regression in nightly-2023-08-26