jiebi/CodeConvo huggingface dataset:
Change:
} } <del> impl Clean<Item> for doctree::Macro { </del> <ins> impl Clean<Item> for (&hir::MacroDef<'_>, Option<Ident>) { </ins> fn clean(&self, cx: &DocContext<'_>) -> Item { <del> Item::from_def_id_and_parts( self.def_id, Some(self.name.clean(cx)), MacroItem(Macro { source: format!( "macro_rules! {} {{n{}}}", self.name, self.matchers </del> <ins> let (item, renamed) = self; let name = renamed.unwrap_or(item.ident).name; let tts = item.ast.body.inner_tokens().trees().collect::<Vec<_>>(); // Extract the spans of all matchers. They represent the "interface" of the macro. let matchers = tts.chunks(4).map(|arm| arm[0].span()).collect::<Vec<_>>(); let source = if item.ast.macro_rules { format!( "macro_rules! {} {{n{}}}", name, matchers .iter() .map(|span| { format!("    {} => {{ ... }};n", span.to_src(cx)) }) .collect::<String>(), ) } else { let vis = item.vis.clean(cx); if matchers.len() <= 1 { format!( "{}macro {}{} {{n    ...n}}", vis.print_with_space(), name, matchers.iter().map(|span| span.to_src(cx)).collect::<String>(), ) } else { format!( "{}macro {} {{n{}}}", vis.print_with_space(), name, matchers </ins> .iter() <del> .map(|span| { format!("    {} => {{ ... }};n", span.to_src(cx)) }) .collect::<String>() ), imported_from: self.imported_from.clean(cx), }), </del> <ins> .map(|span| { format!("    {} => {{ ... }},n", span.to_src(cx)) }) .collect::<String>(), ) } }; Item::from_hir_id_and_parts( item.hir_id, Some(name), MacroItem(Macro { source, imported_from: None }), </ins> cx, ) }

Discussion:
See for []: ! But when you click on : Or for []: ! With source: Or for [], which is not a built-in: ! []: []: []: modify labels: T-rustdoc C-bug
Related:
I have a hunch that and are both represented as and/or .
Cc
I would experiment to see if that is what's causing it, but I'm waiting on a build for something else
https://rustc-dev-
Wow, I never noticed that! That's so cool :)
Indeed, changing changed the output. See if you can notice my experimental change ;) ! And for a built-in: !
Change:
format!("maybe you meant this {}", suggestion.res.descr()) } }; <del> err.span_suggestion(span, msg, suggestion.candidate, Applicability::MaybeIncorrect); </del> <ins> err.span_suggestion(span, msg, sugg, Applicability::MaybeIncorrect); </ins> true }

Discussion:
Variables can be marked as unused by prepending with an underscore. If at some point such a variable is used again, the compiler suggests to name the use , even though every single time I have encountered this, what I wanted is to change the definition of to . () Errors:
I feel we should have a counterpart to the unused lint that checks for variables that are used but use the unused bar convention. That wouldn't be useful for the case presented here where you're using an unused bar for the first time, but seems like a reasonable addition.
Such a lint is problematic within macros or other compiler-expanded code, since it's a common pattern to work around not knowing if there are any uses by naming the variables appropriately (for an example look at the loop lowering code)
I agree but I'm pretty sure that most lints should ignore code with spans in macro context already.
Hi, I'd like to work on this!
sorry for not responding earlier. I only have very broad instructions right now, but don't hesitate to ask here or on the stream on zulip if you need more help. the place where the diagnostic "a local variable with a similar name exists" is emitted note that the "local variable" part may be a placeholder and the rest of the string might be broken across multiple lines if that place has more info than just the name of the local variable not, add a to whatever datastructure holds the name I'm not sure how the name is obtained right now, but there should be a way to get at the there, too. E.g. if the name is an , then it has a field. emitting the "similar name" diagnostic, first check whether the suggested name starts with an underscore, but the name used in the code does not that chek fails, keep the old message , emit the suggestion not on the span that it is currently emitted on, but on the definition span (and change the suggestion to remove the underscore)
Hi I've already done most of that :) I think I'll have a working PR next week.
I can work on this if you guys are caught up with something else :)
sure. Just once you start working on it. Maybe you can even get the WIP branch from fork
Change:
<ins> error[E0369]: cannot multiply `Bar` by `Bar` --> $DIR/borrow-suggestion-109352-2.rs:19:23 | LL |     let _ = owned_bar * owned_bar; |             --------- ^ --------- Bar |             | |             Bar | note: an implementation of `Mul` might be missing for `Bar` --> $DIR/borrow-suggestion-109352-2.rs:1:1 | LL | struct Bar; | ^^^^^^^^^^ must implement `Mul` note: the trait `Mul` must be implemented --> $SRC_DIR/core/src/ops/arith.rs:LL:COL error[E0369]: cannot multiply `&Bar` by `&Bar` --> $DIR/borrow-suggestion-109352-2.rs:21:21 | LL |     let _ = ref_bar * ref_bar; |             ------- ^ ------- &Bar |             | |             &Bar | = note: an implementation for `&mut Bar * &mut Bar` exists help: consider making this expression a mutable borrow --> $DIR/borrow-suggestion-109352-2.rs:21:13 | LL |     let _ = ref_bar * ref_bar; |             ^^^^^^^ help: consider making this expression a mutable borrow --> $DIR/borrow-suggestion-109352-2.rs:21:23 | LL |     let _ = ref_bar * ref_bar; |                       ^^^^^^^ error[E0369]: cannot multiply `&Bar` by `&mut Bar` --> $DIR/borrow-suggestion-109352-2.rs:23:21 | LL |     let _ = ref_bar * ref_mut_bar; |             ------- ^ ----------- &mut Bar |             | |             &Bar | = note: an implementation for `&mut Bar * &mut Bar` exists help: consider making this expression a mutable borrow --> $DIR/borrow-suggestion-109352-2.rs:23:13 | LL |     let _ = ref_bar * ref_mut_bar; |             ^^^^^^^ error[E0308]: mismatched types --> $DIR/borrow-suggestion-109352-2.rs:25:27 | LL |     let _ = ref_mut_bar * ref_bar; |                           ^^^^^^^ types differ in mutability | = note: expected mutable reference `&mut Bar` found reference `&Bar` error: aborting due to 4 previous errors Some errors have detailed explanations: E0308, E0369. For more information about an error, try `rustc --explain E0308`. </ins>

Discussion:
Finally getting around to filing this issue at encouragement in this (rather embarrassing) . CC and I've tried to capture things in ; to summarize: It seems like this should generally be a valid suggestion, and we have to create a diagnostic for this; current error output doesn't help the user to discover the "right" solution at all. No response No response
Hi Erich, thanks for tagging me :) Took me a couple of minutes to refresh my memory :sweatsmile: but glad to see there is something positive coming from that thread :) Should the suggested help-message not read: Since we're not just adding a but rather a ?
I think your point is valid. Edited!
Whoot whoot!
Change:
/// Unwraps the value. /// <del> /// # Safety /// /// This function is unsafe because this thread or another thread may currently be /// inspecting the inner value. /// </del> /// # Examples /// /// ```

Discussion:
It's been unsafe since 2014 when it was called . Nobody thought about it, I guess, but it shouldn't be unsafe.
For reference the PR which it is
Someone thought about it enough to : Has something changed to make this consideration unnecessary or do you have an explanation of why the reasoning is faulty?
Because the function takes so by definition it must be the owner of the value so there can be no other viewers, either from this thread or another thread.
Although this isn't backwards-compatible there is some prior art of going unsafe -safe: (although, that was pre-1.0)
That's weird, it seems like you ought to be able to assign a safe fn to an unsafe fn pointer. , Nicole Mazzuca wrote:
We removed the subtyping relation at some point; it does seem like a coercion would be (probably) ok, but that would still not be (strictly) backwards compatible.
(I tend to agree that could be safe, though, and I highly doubt any existing crates would actually break due to this change.)
We could always do a crater run just to be absolutely sure nobody is turning into a function pointer.
HI ! Any news on this one ?
No change that I know of.
FWIW the relevant coercion was in
This change is breaking my crate. If I add the then it will work for older compilers. If I remove the then it will work for newer compilers. Is there a conditional compilation attribute for compiler version? I can't find one.
Use
Yeah, that's what I'm doing for now. It seems kind of lame, though. But it does work.
Change:
<ins> // Tests #108655: closures in `#[target_feature]` functions can still be marked #[inline(always)] // check-pass // revisions: mir thir // [thir]compile-flags: -Z thir-unsafeck // only-x86_64 #![feature(target_feature_11)] #[target_feature(enable = "avx")] pub unsafe fn test() { ({ #[inline(always)] move || {} })(); } fn main() {} </ins>

Discussion:
The preceding code used to compile successfully. Since the stabilization of in the compilation fails with:
Hm, I think related to and
Based on , I'm guessing it would be fine to allow with on closures, at least from a language perspective, even if it still trips up LLVM?
Technically, is "just a hint" and thus one solution is and always was to accept the inline annotation and then simply ignore the request.
But yes, I believe this code actually should be fully acceptable. Note that in that if is enabled, the attributes do get applied to the closure and inlining is done normally by LLVM due to a full match. No hint required.
Assigning P-low because the regression has been contained to nightly versions due to an immediate revert, so this only blocks forward feature development.
label: -regression-from-stable-to-nightly +requires-nightly
Change:
threads: usize, f: F, ) -> R { <del> use rustc_data_structures::{jobserver, sync::FromDyn}; </del> <ins> use rustc_data_structures::{defer, jobserver, sync::FromDyn}; </ins> use rustc_middle::ty::tls; use rustc_query_impl::QueryCtxt; <del> use rustc_query_system::query::{deadlock, QueryContext}; </del> <ins> use rustc_query_system::query::{break_query_cycles, QueryContext}; use std::process; </ins> let registry = sync::Registry::new(std::num::NonZero::new(threads).unwrap());

Discussion:
I noticed that when parallel rustc panics due to deadlock, it would say instead of . Is this intended?
Hm, I did recently land but I'm not sure if it would cause this issue. It should only affect threads that Rust doesn't create itself and in any case it switches the default name from (which gets rendered as ) to the OS thread name (if available). So if anything I'd have thought it would have the opposite effect. Though maybe there's something about parallel's deadlocks I'm missing.
I think you're good since the problem is older than your pr :D
Oh good! I mean bad, but I was dreading a very long debugging session
well, if you feel bored or something.... :upsidedownface:
Serial rustc creates a single thread called rustc. I assume parallel rustc just doesn't name its rayon threads, no debugging session ahead.
We create a new thread to look for query cycles, it's unnamed at the moment and that's where the panic happens.
Change:
let ty::Dynamic(preds, lifetime, kind) = ty.kind() else { bug!("Tried to strip auto traits from non-dynamic type {ty}"); }; <del> let filtered_preds = if preds.principal().is_some() { </del> <ins> let new_rcvr = if preds.principal().is_some() { let filtered_preds = </ins> tcx.mk_poly_existential_predicates_from_iter(preds.into_iter().filter(|pred| { !matches!(pred.skip_binder(), ty::ExistentialPredicate::AutoTrait(..)) <del> })) } else { ty::List::empty() }; let new_rcvr = Ty::new_dynamic(tcx, filtered_preds, *lifetime, *kind); </del> <ins> })); Ty::new_dynamic(tcx, filtered_preds, *lifetime, *kind) } else { // If there's no principal type, re-encode it as a unit, since we don't know anything // about it. This technically discards the knowledge that it was a type that was made // into a trait object at some point, but that's not a lot. tcx.types.unit }; </ins> tcx.mk_args_trait(new_rcvr, args.into_iter().skip(1)) }

Discussion:
<!-- [31mICE[0m: Rustc '-Zsanitizer=cfi -Ccodegen-units=1 -Clto -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0'', 'thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0'' File: --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: --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I believe this happens since cc
seems to also cause problems
The core problem here is the encoding of the receiver on a object that has no principal. There's a fix for this in the larger patch stack I was breaking down to land piecewise. I'll upload it in a moment. claim
Change:
<ins> struct Project; struct Value; static settings_dir: String = format!(""); //~^ ERROR [E0019] //~| ERROR [E0015] //~| ERROR [E0015] fn from_string(_: String) -> Value { Value } fn set_editor(_: Value) {} fn main() { let settings_data = from_string(settings_dir); //~^ ERROR cannot move out of static item `settings_dir` [E0507] let args: i32 = 0; match args { ref x if x == &0 => set_editor(settings_data), ref x if x == &1 => set_editor(settings_data), _ => unimplemented!(), } } </ins>

Discussion:
err : code i was compiling : rest code lives at
Can you please check the beta & nightly compilers to see if you can reproduce? Also, if you can reproduce it, can you provide a backtrace (instructions in the ICE) and try to minimize the reproducer (start by adding instead of method bodies one by one and binary search your way by removing code)?
cc
after rebooting my issue seem to be gone , but i believe i should leave issue open for investigation , and beta channel test i could not test that as issue was resolved after my laptop rebooted due to system update , i apologize of being unhelpful ! , i will keep on testing and update you if i encounter any issue
maybe it wasn't the reboot, but did you execute in between? Then it may be a incremental compilation issue.
its the first time i am seeing that cargo has clean command
I ran , and still got the same compiler error. This is the code code:
Both code used file I/O library. In my case, my code worked before I applied writing files. Maybe borrowing check makes an error in writing files in current rust nightly compiler. My compiler environment is :
Minimized it:
It has been introduced <strikesomewhere between ...</strikein It has been fixed <strikesomewhere between ...</strikein
triage: stable-to-stable regression. Fixed in beta. Once release happens (scheduled for next week), it will be fixed.
(only remaining question I have is whether to add the reduced example as a regression test or not. The looks different enough from that I think a regression test may be warranted.)
Change:
} } <ins> // regression test for issue #85322. Peekable previously implemented InPlaceIterable, // but due to an interaction with IntoIter's current Clone implementation it failed to uphold // the contract. #[test] fn test_collect_after_iterator_clone() { let v = vec![0; 5]; let mut i = v.into_iter().map(|i| i + 1).peekable(); i.peek(); let v = i.clone().collect::<Vec<_>>(); assert_eq!(v, [1, 1, 1, 1, 1]); assert!(v.len() <= v.capacity()); } </ins> #[test] fn test_cow_from() { let borrowed: &[_] = &["borrowed", "(slice)"];

Discussion:
This code leads to an out of bounds write, makes the assert fail and triggers miri: The problem is that after cloning a the inner iterator can no longer be considered advanced, but the may still yield the peeked element without advancing it, thus breaking the contract of .
This can be fixed by either removing from or by changing the impl of to clone the exact state of rather than allocating a smaller one. The latter may be unnecessarily costly when cloning a mostly-exhausted iterator, but on the other hand it would preserve the optimization. So I'd try the first one first and do a perf run to see what the impact is (when it was introduced it mostly helped rustdoc) and try the latter if there's a significant regression.
It may also be possible to fix this by specializing on to look into its (if available) and do a custom clone of its source. I'll see if specialization is powerful enough to pull that off.
Hrm, I think it would be possible to do that but it would require some additional helper traits or methods tailored to just this use-case since doesn't know about . That's probably too much hackery for this optimization.
This also effects stable modify labels: regression-from-stable-to-stable
Is it a regression though? Marking as according to the . modify labels -I-prioritize +P-critical
Technically when was merged it broke any crate that used code like this (which is not that unexpected like exploting panics and stuff like that). In fact I found this bug due to a project written in only safe rust code that was segfaulting
Change:
(ty::PredicateKind::Projection(a), ty::PredicateKind::Projection(b)) => { relator.relate(predicate.rebind(a), p.rebind(b)).is_ok() } <ins> ( ty::PredicateKind::ConstEvaluatable(def_a, substs_a), ty::PredicateKind::ConstEvaluatable(def_b, substs_b), ) => tcx.try_unify_abstract_consts(((def_a, substs_a), (def_b, substs_b))), (ty::PredicateKind::TypeOutlives(a), ty::PredicateKind::TypeOutlives(b)) => { relator.relate(predicate.rebind(a.0), p.rebind(b.0)).is_ok() } </ins> _ => predicate == p, } };

Discussion:
This issue seems to be specific to the trait. : label A-const-generics F-constevaluatablechecked T-compiler
Also, is it expected that the where bounds need to be repeated in each of the type's trait impls?
Yes, bounds on type definitions need to be repeated in impls, at least until are introduced.
Is anyone aware of a way to work around this issue at the moment?
Change:
cargo.env("CFG_RELEASE", &build.release) .env("CFG_RELEASE_CHANNEL", &build.config.channel) .env("CFG_VERSION", &build.version) <del> .env("CFG_PREFIX", build.config.prefix.clone().unwrap_or(String::new())) </del> <ins> .env("CFG_PREFIX", build.config.prefix.clone().unwrap_or(PathBuf::new())) </ins> .env("CFG_LIBDIR_RELATIVE", "lib"); if let Some(ref ver_date) = build.ver_date {

Discussion:
No destdir is passed to in
That causes fail in Gentoo build
As far as I understand, we need to to pass to function and add value of to prefix here
Change:
export ANDROID_HOME=/android/sdk PATH=$PATH:"${ANDROID_HOME}/tools/bin" <ins> LOCKFILE="${ANDROID_HOME}/android-sdk.lock" </ins> <del> download_sdk() { mkdir -p /android curl -fo sdk.zip "https://dl.google.com/android/repository/sdk-tools-linux-$1.zip" unzip -q sdk.zip -d "$ANDROID_HOME" rm -f sdk.zip } download_sysimage() { abi=$1 api=$2 # See https://developer.android.com/studio/command-line/sdkmanager.html for # usage of `sdkmanager`. # # The output from sdkmanager is so noisy that it will occupy all of the 4 MB # log extremely quickly. Thus we must silence all output. yes | sdkmanager --licenses > /dev/null yes | sdkmanager platform-tools  "platforms;android-$api"  "system-images;android-$api;default;$abi" > /dev/null } download_emulator() { # Download a pinned version of the emulator since upgrades can cause issues curl -fo emulator.zip "https://dl.google.com/android/repository/emulator-linux-$1.zip" rm -rf "${ANDROID_HOME}/emulator" unzip -q emulator.zip -d "${ANDROID_HOME}" rm -f emulator.zip } create_avd() { abi=$1 api=$2 </del> <ins> # To add a new packages to the SDK or to update an existing one you need to # run the command: # #    android-sdk-manager.py add-to-lockfile $LOCKFILE <package-name> # # Then, after every lockfile update the mirror has to be synchronized as well: # #    android-sdk-manager.py update-mirror $LOCKFILE # /scripts/android-sdk-manager.py install "${LOCKFILE}" "${ANDROID_HOME}" </ins> <del> # See https://developer.android.com/studio/command-line/avdmanager.html for # usage of `avdmanager`. echo no | avdmanager create avd  -n "$abi-$api"  -k "system-images;android-$api;default;$abi" } </del> <ins> details=$(cat "${LOCKFILE}"  | grep system-images  | sed 's/^system-images;android-([0-9]+);default;([a-z0-9-]+) /1 2 /g') api="$(echo "${details}" | awk '{print($1)}')" abi="$(echo "${details}" | awk '{print($2)}')" </ins> <del> download_and_create_avd() { download_sdk $1 download_sysimage $2 $3 create_avd $2 $3 download_emulator $4 } </del> <ins> # See https://developer.android.com/studio/command-line/avdmanager.html for # usage of `avdmanager`. echo no | avdmanager create avd  -n "$abi-$api"  -k "system-images;android-$api;default;$abi" </ins> <del> # Usage: # #       download_and_create_avd 4333796 armeabi-v7a 18 5264690 # # 4333796 => #   SDK tool version. #   Copy from https://developer.android.com/studio/index.html#command-tools # armeabi-v7a => #   System image ABI # 18 => #   Android API Level (18 = Android 4.3 = Jelly Bean MR2) # 5264690 => #   Android Emulator version. #   Copy from the "build_id" in the `/android/sdk/emulator/emulator -version` output </del>

Discussion:
We already had at least two different CI issues caused by the Android SDK's sdkmanager: a new license was and sdkmanager failed to accept it with the old command the emulator was updated to a broken (at least for us) version, causing all builds to fail The root cause of those issues is that sdkmanager doesn't support any kind of pinning (as far as I can tell), and any change Google makes can break our CI. Should we develop a pinning mechanism and use it for all the Android SDK components? cc
Change:
<ins> //@ check-pass //! [macro@m!] //~ WARN: unresolved link to `m` //issue#126986 macro_rules! m { () => {}; } fn main() {} </ins>

Discussion:
<!-- 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. --Occurs on stable + nightly : : i replaced backtrace with for readability since it's displayed without any flags: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
The combination of course seems invalid, but the compiler shouldn't panic, right?
That was quick, thank you!
Change:
"checksum backtrace 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)" = "99f2ce94e22b8e664d95c57fff45b98a966c2252b60691d0b7aeeccd88d70983" "checksum backtrace-sys 0.1.14 (registry+https://github.com/rust-lang/crates.io-index)" = "c63ea141ef8fdb10409d0f5daf30ac51f84ef43bff66f16627773d2a292cd189" "checksum bitflags 0.7.0 (registry+https://github.com/rust-lang/crates.io-index)" = "aad18937a628ec6abcd26d1489012cc0e18c21798210f491af69ded9b881106d" <del> "checksum bitflags 0.8.2 (registry+https://github.com/rust-lang/crates.io-index)" = "1370e9fc2a6ae53aea8b7a5110edbd08836ed87c88736dfabccade1c2b44bff4" </del> "checksum bitflags 0.9.1 (registry+https://github.com/rust-lang/crates.io-index)" = "4efd02e230a02e18f92fc2735f44597385ed02ad8f831e7c1c1156ee5e1ab3a5" "checksum bitflags 1.0.0 (registry+https://github.com/rust-lang/crates.io-index)" = "f5cde24d1b2e2216a726368b2363a273739c91f4e3eb4e0dd12d672d396ad989" "checksum bufstream 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)" = "f2f382711e76b9de6c744cc00d0497baba02fb00a787f088c879f01d09468e32"

Discussion:
generates different HTML under and not. Not only does this trigger what's effectively a spurious warning, but it doesn't render correctly either. cc , marking this as p-high
This was fixed by google/pulldown-cmark rustdoc just needs to update its version of pulldown-cmark.
The thread in that issue says it was released in 0.0.15. we're pulling in 0.0.14 for rustdoc, but also 0.1.0 for mdbook. I'll see if i can update the dependency for rustdoc and pull it in.
updates Pulldown for rustdoc and fixes this.
I am not sure this actually fixes the warnings, as they use different IDs and such. I'm testing this locally right now though; expect an update in ~20 minutes