jiebi/CodeConvo huggingface dataset:
Change:
#[rustc_effective_visibility] pub use half_public_import::HalfPublicImport; //~ ERROR Public: pub, Exported: pub, Reachable: pub, ReachableFromImplTrait: pub <ins> //~^ ERROR Public: pub, Exported: pub, Reachable: pub, ReachableFromImplTrait: pub </ins> fn main() {}

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see no output from the compiler. Instead, this happened: searched nightlies: from nightly-2022-09-22 to nightly-2022-09-27 regressed nightly: nightly-2022-09-25 searched commit range: regressed commit: This is a roll-up, seems the most likely culprit. cc <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: aarch64-apple-darwin Reproduce with: </details modify labels: +regression-from-stable-to-nightly -regression-untriaged
WG-prioritization assigning priority, probably a P-high since the lint malfunction is blocking valid code (iiuc) label -I-prioritize P-high T-compiler
any ideas how to address this or should I start digging in to it
In HIR desugars into two items (import in type namespace and import in value namespace). One of them is externally reachable and another is not (before both of them were incorrectly marked as externally reachable). Code in should somehow account for this desugaring and not report the as unnecessary if at least one of the imports is reachable.
I have been unable to fix this or apply a revert. can you look at implementing this before the beta cutoff?
Reverted in
Change:
<ins> error[E0261]: use of undeclared lifetime name `'b` --> $DIR/undeclared-lifetime-used-in-debug-macro-issue-70152.rs:13:13 | LL |     fn foo(&'b self) {} |             ^^ undeclared lifetime | = help: if you want to experiment with in-band lifetime bindings, add `#![feature(in_band_lifetimes)]` to the crate attributes help: consider introducing lifetime `'b` here | LL | impl<'b> T for Test { |     ^^^^ help: consider introducing lifetime `'b` here | LL |     fn foo<'b>(&'b self) {} |           ^^^^ error[E0261]: use of undeclared lifetime name `'b` --> $DIR/undeclared-lifetime-used-in-debug-macro-issue-70152.rs:3:9 | LL | struct Test { |            - help: consider introducing lifetime `'b` here: `<'b>` LL |     a: &'b str, |         ^^ undeclared lifetime | = help: if you want to experiment with in-band lifetime bindings, add `#![feature(in_band_lifetimes)]` to the crate attributes error[E0261]: use of undeclared lifetime name `'b` --> $DIR/undeclared-lifetime-used-in-debug-macro-issue-70152.rs:3:9 | LL | #[derive(Eq, PartialEq)] |          -- lifetime `'b` is missing in item created through this procedural macro LL | struct Test { LL |     a: &'b str, |         ^^ undeclared lifetime | = help: if you want to experiment with in-band lifetime bindings, add `#![feature(in_band_lifetimes)]` to the crate attributes error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0261`. </ins>

Discussion:
In case there is an undeclared lifetime in an ADT deriving a wrong help message is emited causes the following error thx, bye
There are two things here: 1) the suggestion should try and identify spans coming from macro expansion and not suggest changes 2) in this case expands to the following: Note the param, which could avoid having any lifetimes and thing would work correctly. We can probably change the desugaring to not specify the lifetime and then we would avoid the second unnecessary duplicated error. would you happen to know if there's any clear negative in doing 2 above and if not, point me in the right direction in to make that change?
I believe that we can't remove the explicit lifetime here. This would allow for even if is only implemented for .
Change:
<ins> // check-pass macro_rules! impl_primitive { ($ty:ty) => { impl_primitive!(impl $ty); }; (impl $ty:ty) => { fn a(_: $ty) {} } } impl_primitive! { u8 } macro_rules! test { ($ty:ty) => { compile_error!("oh no"); }; (impl &) => {}; } test!(impl &); 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: Macro is expanded to Instead, this happened: On stable it works as expected. On beta and nightly it fails with the following error It is probably caused by fragment that now treats as a start of type. So makes sense. But breaks existing code :) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
searched nightlies: from nightly-2022-06-01 to nightly-2023-02-01 regressed nightly: nightly-2023-01-18 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: </detailsI think I see where the issue is, I'll fix it. claim
WG-prioritization assigning priority (). label -I-prioritize +P-high
IIRC issues with a backport pending should stay open to track the backport process (not 100% sure tho)
beta backport in
Change:
<ins> use crate::fmt; </ins> use crate::iter::{FusedIterator, TrustedLen, UncheckedIterator}; <del> use crate::mem::ManuallyDrop; </del> <ins> use crate::mem::{self, MaybeUninit}; </ins> use crate::num::NonZero; /// Creates a new iterator that repeats a single element a given number of times.

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. --This is technically different from as there's no UAF. However, using with has undefined behavior if you use the last/original element after moving the iterator, since the field has noalias properties. <details<summaryMiri Backtrace</summary<p</p</detailsWrapping the element using (or once we have that) should make this sound.
See also:
The minimal example is actually this: Because eagerly calls drop for . This basically boils down to Which is indeed I quite strongly think that this is a bug in miri and/or ( should use inside of itself probably?). That being said this is not yet decided (again, see the UCG issue) :/
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Yeah, it should -- someone just has to implement first. ;) See
I tweaked the title because while there is an experimental Miri flag to make Unique magical, codegen only has special treatment for Box.

<!-- 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. --currently unconditionally derives . However, it will also drop its inner object if is 0, which can cause a UAF if it's cloned afterwards. Running the above program segfaults: Edit: Made the segfault quicker/more reliable.
same issue with its implementation
cc I think you implemented this. ^^
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Change:
<ins> #![feature(type_alias_impl_trait)] use std::marker::PhantomData; trait Trait { fn foo<T, U>(t: T) -> U; } trait ProofForConversion<X> { fn convert<T, U>(_: PhantomData<Self>, r: T) -> U; } impl<X: Trait> ProofForConversion<X> for () { fn convert<T, U>(_: PhantomData<Self>, r: T) -> U { X::foo(r) } } type Converter<T> = impl ProofForConversion<T>; //~^ ERROR the trait bound `T: Trait` is not satisfied fn _defining_use<T: Trait>() -> Converter<T> { () } fn main() { } </ins>

Discussion:
() I would’ve expected rustc to complain about the not matching the with a suggestion to turn it into . modify labels: A-typesystem, A-lifetimes, A-traits, A-impl-trait, F-typealiasimpl_trait, T-compiler, requires-nightly and someone please add “I-unsound ” (and/or tell me if there is a way to do it myself).
One thing that is of note here is that we properly enforce type bounds, but not lifetime bounds, as the equivalent program with types fails to compile right where we expect that:
Aha! If we change to have an explicit bound, then we get the right error: so we're just missing a check of the implied bounds on the impl
Change:
<ins> // Checks that the following does not ICE because `decorate` is incorrectly skipped. //@ compile-flags: -Dunused_must_use -Awarnings --crate-type=lib #[must_use] fn f() {} pub fn g() { f(); //~^ ERROR unused return value } </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:
ty::ReLateParam(_) => {} // Remap early-bound regions as long as they don't come from the `impl` itself, // in which case we don't really need to renumber them. <del> ty::ReEarlyParam(ebr) if ebr.index >= self.tcx.generics_of(self.impl_def_id).count() as u32 => {} </del> <ins> ty::ReEarlyParam(ebr) if ebr.index as usize >= self.num_impl_args => {} </ins> _ => return Ok(region), }

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: expected lifetime parameter, but found another generic parameter', 'error: internal compiler error: expected lifetime parameter, but found another generic parameter' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [collectreturnpositionimpltraitintraittys] comparing an impl and trait method signature, inferring any hidden types in the process [typeof] computing type of --
cc
Change:
self.add_traits_in_parent_scope(impl_def_id); } } <ins> for def_id in all_lang_items { self.add_traits_in_parent_scope(def_id); } </ins> self.all_traits.extend(all_traits); self.all_trait_impls.extend(all_trait_impls.into_iter().map(|(_, def_id, _)| def_id));

Discussion:
(Using + ) (Minimized from ) : <details<summary<strongBacktrace</strong</summary<p</p</detailscc
One thing I forgot to do is check that my minimization is exhaustive. After deleting all the from the original crate it still ICEs, so there must be another way that it is triggering this too.
Could this issue be related/duplicate of (and therefore fixed by )? Also, perhaps replace the team label with ?
I assume you meant ? That was included in which I tested with (we have a collection of failing crates in that I am rebuilding as each fix for the fallout from lands).
Fixed in
Change:
pairs when they occur at the beginning of, or immediately after, a `$(...)*`; requiring a distinctive token in front can solve the problem. <del> ## Syntax extensions useful for the macro author </del> <ins> ## Syntax extensions useful in macros </ins> <del> * `log_syntax!` : print out the arguments at compile time * `trace_macros!` : supply `true` or `false` to enable or disable macro expansion logging </del> * `stringify!` : turn the identifier argument into a string literal * `concat!` : concatenates a comma-separated list of literals <del> * `concat_idents!` : create a new identifier by concatenating the arguments The following attributes are used for quasiquoting in procedural macros: </del> <ins> ## Syntax extensions for macro debugging * `log_syntax!` : print out the arguments at compile time * `trace_macros!` : supply `true` or `false` to enable or disable macro expansion logging ## Quasiquoting The following syntax extensions are used for quasiquoting Rust syntax trees, usually in [procedural macros](book/plugins.html#syntax-extensions): </ins> * `quote_expr!` * `quote_item!`

Discussion:
As of the original docs on recursive macros are gone. We should have an example that clearly illustrates the increased power vs. the built-in repetition operator.
Change:
<ins> //check-pass use higher_kinded_types::*; mod higher_kinded_types { pub(crate) trait HKT { type Of<'lt>; } pub(crate) trait WithLifetime<'lt> { type T; } impl<T: ?Sized + for<'any> WithLifetime<'any>> HKT for T { type Of<'lt> = <T as WithLifetime<'lt>>::T; } } trait Trait { type Gat<'lt>; } impl Trait for () { type Gat<'lt> = (); } /// Same as `Trait`, but using HKTs rather than GATs trait HTrait { type Hat: ?Sized + HKT; } impl<T: Trait> HTrait for T { type Hat = dyn for<'lt> WithLifetime<'lt, T = T::Gat<'lt>>; } impl<Hat: ?Sized + HKT> Trait for Box<dyn '_ + HTrait<Hat = Hat>> { type Gat<'lt> = Hat::Of<'lt>; } fn existential() -> impl for<'a> Trait<Gat<'a> = ()> {} fn dyn_hoops<T: Trait>( _: T, ) -> Box<dyn HTrait<Hat = dyn for<'a> WithLifetime<'a, T = T::Gat<'a>>>> { loop {} } fn main() { let _ = || -> _ { dyn_hoops(existential()) }; } </ins>

Discussion:
All of this is yanked out of my work-in-progress bug-for-bug Misskey Flavored markdown parser, which uses the trait, as defined below, to hopefully allow the compiler to create well-optimized functions via inlining and such. Where things get messy is in the introduction of the trait, which uses the same technique used by the and crates in order to remove the generic lifetime from its associated type, , since lifetime-only generic associated types aren't object-safe (yet?), despite lifetime-only generic parameters being object-safe. Object-safety is required in this case, because the syntax doesn't support cyclic types (for obvious reasons), so boxing and dynamic dispatch is necessary in order to break said cycle. as in, it behaves identically to , regardless of if that behavior is really "correct" behavior for a markdown parser or not._ <details<summarySorry for the rather large reproduction, this was as small as I was able to get it :sweat:</summary</details: <details<summary<strongBacktrace</strong</summary<p</p</details
Reduced:
Further reduced.
Further minimized:
Change:
/// /// # Panics /// <del> /// This function will panic if `rhs` is 0 or if `self` is -1 and `rhs` is /// `Self::MIN`. This behavior is not affected by the `overflow-checks` flag. </del> <ins> /// This function will panic if `rhs` is 0 or if `self` is `Self::MIN` and /// `rhs` is -1. This behavior is not affected by the `overflow-checks` flag. </ins> /// /// # Examples ///

Discussion:
The documentation of and for any signed integer type, e.g.: In the "Panics" section it says "This function will panic if is 0 or if is -1 and is .", but I believe this is the wrong way around: the panic happens on , not on , as (correctly) explained in and all other related functions. Also, is there any situation where someone would want over ? Mathematically, should really just be 0, that it panics is more of an implementation artifact (the corresponding division overflows). Maybe it would be a good idea to add something like "If this is a problem, use instead." to the documentation of ? Though in most applications will probably be positive anyway. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
the error is also present on and .
Change:
use rustc_data_structures::fx::FxHashSet; use rustc_hir::def_id::{DefId, LOCAL_CRATE}; <ins> use rustc_middle::ty::DefIdTree; </ins> use rustc_span::symbol::sym; crate const COLLECT_TRAIT_IMPLS: Pass = Pass {

Discussion:
I tried this code: I expected to see this happen: both impls being highlighted as needing the feature. Instead, this happened: only the impl got the message: ! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
modify labels: +T-rustdoc
claim
Change:
def main(): parser = argparse.ArgumentParser(description='Build rust') parser.add_argument('--config') <ins> parser.add_argument('--clean', action='store_true') </ins> parser.add_argument('-v', '--verbose', action='store_true') args = [a for a in sys.argv if a != '-h']

Discussion:
Errors like are happening on the bots, e.g.: This is under the covers, but rustbuild's command should blow away the build system directory ahead of time to be more resilient to bugs like this.
Change:
} #[stable(feature = "rust1", since = "1.0.0")] <del> impl<T> error::Error for TrySendError<T> { </del> <ins> impl<T: Send> error::Error for TrySendError<T> { </ins> fn description(&self) -> &str { match *self {

Discussion:
currently requires , while requires . I'm unsure of what each should require, but I think they should agree so that it is possible to have code which returns (which is useful to allow try! across functions returning different types of error codes), and be able to the results.
There was a lengthy discussion about this towards the bottom of the RFC:
/cc , I vaguely remember this might change? If not, then this should be in the RFCs repo.
Nominating for 1.0-beta P-backcompat-libs. (The trait isn't yet, but it probably will be for 1.0).
0 beta, P-backcompat-libs, I-needs-decision.
Change:
/// ``` #[inline] #[stable(feature = "cstr_from_bytes", since = "1.10.0")] <del> pub unsafe fn from_bytes_with_nul_unchecked(bytes: &[u8]) -> &CStr { </del> <ins> #[rustc_const_unstable(feature = "const_cstr_unchecked")] pub const unsafe fn from_bytes_with_nul_unchecked(bytes: &[u8]) -> &CStr { </ins> &*(bytes as *const [u8] as *const CStr) }

Discussion:
The current implementation of is not valid in a const context, but it can easily be tweaked so that it is:
At this point you can just enable the feature gate and use . There's no need for unions anymore
I thought was explicitly not going to become as per the discussion in .
Alternatively, why can't we make DST constructors work for simple wrappers like this? Why can't it be, e.g. &CStr{ bytes: *bytes } Where it looks kind of like the opposite of a deref coercion, and the compiler just reinterprets the fat pointer? This would eliminate the need for any besides what's necessary for the API contract.
Yes I would like such constructors, too. But that needs and RFC and probably has a lot of caveats that we want to think about. I did not know about that issue. I commented there.
Change:
<ins> // Test Setting the value of an associated type // that is shadowed from a supertrait pub trait Super { type X; } pub trait Sub: Super { type X; } impl<T> Clone for Box<dyn Sub<X = T>> { //~^ ERROR value of the associated type `X` in `Super` must be specified fn clone(&self) -> Self { unimplemented!(); } } pub fn main() {} </ins>

Discussion:
Given the following code: The current output is: is wrong, specifying another isn't going to fix the problem. Writing just has a suggestion where`, which is good, but the concrete syntax would be nice. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
We probably should modify E0191 to hint that an supertrait's associated type is shadowed. I think E0719 here is fine to keep as-is, imo.
I agree the message for E0719 is good as-is.
Is this issue fixed ? If not can I take this up, please. Also how exactly should E0191 be modified. Imo, I don't think E0191 should pop up in this case as E0719 conveys the message.
claim
claim
Ask for help How do I specify the association type of supertrait with the same name? In other words, is there an easy way to modify the code in the issue to make it pass compilation? Here's my clumsy way of creating a new trait.
Is this issue still open? If so I would like to take a crack at it.
If you can still reproduce it, then yes indeed. assign
Error: Parsing assign command in failed: ...'zyDutchman' ''... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
I have now a hint about the shadowing: But I am not quite sure about what to do about the actual message. Do we want to suggest renaming to something else Or do we want to suggest the work-around by
If the trait is local, then we could suggest renaming it. It's not required to be super specific here--we could just note the conflict to make the user aware of it, for example.
I have updated the help message so that this case: gives this error message: The rename help message is emitted for both the super trait and the subtrait, if they are local. I think I am ready to make a merge request, or does somebody have something else to add?
I recommend you to just open a PR. Any further discussions can happen over there :)
Change:
- [Added an experimental backend for codegen with `libgccjit`.][87260] <ins> [85200]: https://github.com/rust-lang/rust/pull/85200/ </ins> [86191]: https://github.com/rust-lang/rust/pull/86191/ [87220]: https://github.com/rust-lang/rust/pull/87220/ [87260]: https://github.com/rust-lang/rust/pull/87260/

Discussion:
landed in 1.57, causing derived and implementations to be ignored during dead code analysis. The for 1.57 don't mention this change anywhere. There's discussion in the original PR about including it in the release notes, but looks like nobody got around to it. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think this is also worth a mention in the compatibility notes for 1.57, given that it can break builds where is set.
label +D-incorrect +D-invalid-suggestion
label -D-incorrect -D-invalid-suggestion
My bad there, had two different issues open.
I'd be happy to approve a PR adding a line to the release notes about this.
claim
Change:
use rustc_data_structures::temp_dir::MaybeTempDir; use rustc_fs_util::fix_windows_verbatim_for_gcc; use rustc_hir::def_id::CrateNum; <del> use rustc_middle::middle::cstore::{EncodedMetadata, LibSource, NativeLib}; </del> <ins> use rustc_middle::middle::cstore::{EncodedMetadata, LibSource}; </ins> use rustc_middle::middle::dependency_format::Linkage; use rustc_session::config::{self, CFGuard, CrateType, DebugInfo}; use rustc_session::config::{OutputFilenames, OutputType, PrintRequest, SanitizerSet};

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 command: I expected to see this happen: An file is generated. Instead, this happened: <!-- 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. --: Originally posted by in cc (original implementer of
PR changed the encode/decode method of . When was implemented, the encode/decode of was purposely crafted to avoid calling the encode/decode method of . The most straightforward fix is to implement / for to allow it be serialized outside of metadata. After that, may be now it is the time to re-think the way we store data in the file. What do you think ?
I think should completely be avoided in the input of the linker function. One of the uses if in it's field. This field doesn't seem to be used by the linking code.
Good suggestion, let me look into it.
are you still working on this?
Thank you for reminding and apologize for the delay. I did create a prototype but haven't got a chance polish it yet. I'll create the PR this week.
Sorry again about the delay. I've created PR , which fixes this issue.