jiebi/CodeConvo huggingface dataset:
Change:
<ins> // Copyright 2015 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. trait SomeTrait {} struct Meow; impl SomeTrait for Meow {} struct Foo<'a> { x: &'a SomeTrait, y: &'a SomeTrait, } impl<'a> Foo<'a> { pub fn new<'b>(x: &'b SomeTrait, y: &'b SomeTrait) -> Foo<'b> { Foo { x: x, y: y } } } fn main() { let r = Meow; let s = Meow; let q = Foo::new(&r as &SomeTrait, &s as &SomeTrait); } </ins>

Discussion:
For some reason, trying to place two trait objects with the same templated lifetime into a struct confuses borrowck: This does NOT occur with references to primitive types (tested w/ int). It also does NOT occur if there is only one trait object reference. This is currently holding up progress on red (my text editor in Rust), so a rapid fix would be very helpful. Thanks in advance.
In an absolutely baffling turn of events, using tuple-like structs works fine. The below compiles happily... This is a usable workaround for the time being, but really only raises more questions as to what exactly is going on in the borrow checker.
cc me
This compiles as of .
Change:
<del> // Checks existence of a note for "a caller chooses ty for ty param" upon return ty mismatch. </del> <ins> // Checks existence or absence of a note for "a caller chooses ty for ty param" upon return ty // mismatch. </ins> fn f<T>() -> (T,) { (0,) //~ ERROR mismatched types

Discussion:
The statement "the caller chooses a type for which can be different from " is confusing because and are always different. I think it would be best to supress that note when the types only differ in reference-ness. The message was introduced in . No response No response
label +D-confusing
Thanks, that note definitely doesn't make sense. CC (). I suggested to move out of in order to catch more cases but that was a bit too aggressive as can be witnessed here — that's on me. We should replicate some parts of , namely checking that the type param in question does not occur in the return expression type. That did cross my mind back then but I didn't really follow up on that thought for some reason.
Thanks for the cc I'll take a look ~today/tomorrow
Opened to avoid making the note if found return type contains the expected return type (type parameter).
Change:
instance: Instance<'tcx>, options: TypeIdOptions, ) -> String { <ins> assert!(!instance.has_non_region_param(), "{instance:#?} must be fully monomorphic"); </ins> let transform_ty_options = TransformTyOptions::from_bits(options.bits()) .unwrap_or_else(|| bug!("typeid_for_instance: invalid option(s) `{:?}`", options.bits())); let instance = transform_instance(tcx, instance, transform_ty_options); let fn_abi = tcx <del> .fn_abi_of_instance(tcx.param_env(instance.def_id()).and((instance, ty::List::empty()))) </del> <ins> .fn_abi_of_instance(ty::ParamEnv::reveal_all().and((instance, ty::List::empty()))) </ins> .unwrap_or_else(|error| { bug!("typeid_for_instance: couldn't get fn_abi of instance {instance:?}: {error:?}") });

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
label A-sanitizers
Change:
var code = $('<code>').append(structs[j]); $.each(code.find('a'), function(idx, a) { var href = $(a).attr('href'); <del> if (!href.startsWith('http')) { $(a).attr('href', rootPath + $(a).attr('href')); </del> <ins> if (href && !href.startsWith('http')) { $(a).attr('href', rootPath + href); </ins> } }); var li = $('<li>').append(code);

Discussion:
There should be one cross-crate implementation of this trait, but a JS error is thrown trying to load it:
Change:
pub const E: f64 = 2.71828182845904523536028747135266250_f64; /// log<sub>2</sub>(10) <del> #[unstable(feature = "extra_log_consts", issue = "50540")] </del> <ins> #[stable(feature = "extra_log_consts", since = "1.43.0")] </ins> pub const LOG2_10: f64 = 3.32192809488736234787031942948939018_f64; /// log<sub>2</sub>(e)

Discussion:
Specifically, and . PR:
Has anyone used these constants at all and want to pitch in for stabilisation of these? These have landed for a while and I'm curious how many people are using them.
+1 for stabilization. (Tried to see if log<sub2</sub(10) exists and found that it is unstable .)
(Mind providing the specific use case? Curious to see if people are using this for anything other than scientific computing.)
to estimate the "&minus;log<sub2</sub(probability)" of collision of two values chosen randomly from a set, which will be used to derive the probability of collision of N values (≈ 1 &minus; e<sup-pN<sup2</sup/2</sup, p &ll; 1, N &gg; 1). log<sub2</subis chosen instead of natural log because the set size is often 2<supn</sup(e.g. u32), but sometimes it is drawn from a set of n decimal digits which would then involve n·log<sub2</sub(10).
One ) is = shannons (bits). Currently the constant is duplicated in .
I can't @ anyone from the libs team but do you think we'd be able to start an FCP for this?
cc .
fcp merge I believe the stabilization includes .
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), 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.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
Does this need a stabilization report/PR?
It needs a PR.

Not sure if we should include in that though; would you be willing to open a separate tracking issue for that, considering how that wasn't included in the FCP for this one?
There is already .
Oh, my bad. I for some reason noticed that this issue got linked in the PR and thought that there wasn't a separate tracking issue.
Change:
<del> error[E0072]: recursive type `f::E` has infinite size --> $DIR/infinite-recursive-type-impl-trait.rs:2:5 | LL |     enum E { |     ^^^^^^ LL |         V(E), |           - recursive without indirection | help: insert some indirection (e.g., a `Box`, `Rc`, or `&`) to break the cycle | LL |         V(Box<E>), |           ++++ + error: aborting due to previous error For more information about this error, try `rustc --explain E0072`. </del>

Discussion:
If we run with the option on this code: Both and are documented, but not being accessible outside of , it shouldn't be documented.
probably knows this, but for others seeing this issue, I think it's probably due to (which was reverted in , and later re-applied in ). It has to do with the fact that we're using a HIR visitor now, so we're visiting nested items unconditionally.
Yes I know where it's coming from. :smile: I was just thinking today that since we were going through the whole HIR without checking whether or not we were in a block, all elements inside the block could be visible. Tested and... :fearful: Should be pretty easy to fix.
For reference, I put up because this was causing documentation to become really verbose with serde + . If you fix this such that we no longer document those items, we could probably revert that PR.
Indeed. Don't hesitate to come to me if you have such issues with rustdoc. Such problems should definitely not go unnoticed.
The thing is, it was not particularly clear from the PRs whether this was intentional or not.
Unfortunately it wasn't. The goal was to retrieve the missing impl blocks. But if anything isn't clear, don't hesitate to ask too. :wink:
Change:
implied_bounds, tcx.hir().local_def_id_to_hir_id(impl1_def_id), ); <del> infcx.process_registered_region_obligations(outlives_env.region_bound_pairs(), param_env); infcx.resolve_regions_and_report_errors(impl1_def_id, &outlives_env); </del> <ins> infcx.check_region_obligations_and_report_errors(impl1_def_id, &outlives_env); </ins> let Ok(impl2_substs) = infcx.fully_resolve(impl2_substs) else { let span = tcx.def_span(impl1_def_id); tcx.sess.emit_err(SubstsOnOverriddenImpl { span });

Discussion:
into causes an internal compiler panic This causes an internal compiler error: This seems related to , except this is using
:
This is not specific to . The following produces the same kind of error.
modify labels: +regression-from-stable-to-stable The ICE happens on stable regardless of having the feature gate or not (the ICE does not requires a nightly compiler to reproduce)
Change:
over elements of type `{A}`", label = "value of type `{Self}` cannot be built from `std::iter::Iterator<Item={A}>`" )] <ins> #[rustc_diagnostic_item = "FromIterator"] </ins> pub trait FromIterator<A>: Sized { /// Creates a value from an iterator. ///

Discussion:
(As I mentioned :) I tried out the migration lints on some of my own code, and ran into one false positive: A struct being used with This doesn't actually become ambiguous when FromIterator is imported, because Opt doesn't implement that. Niko :
(If we don't end up doing this, we should at least change the wording to say instead of .)
Which exact function on which type do you mean? Do you have some pointers here?
Maybe Niko meant evaluate-obligation ?
Okay I have an implementation that uh.. compiles. And seems to work, maybe? (:
Change:
inputs.push(mtime(path)); } <ins> // Compiletest itself. inputs.extend(collect_timestamps(&rust_src_dir.join("src/tools/compiletest/"))); </ins> inputs.iter().any(|input| *input > stamp) }

Discussion:
If I modify a file in the rustc source code (), is smart enough to rerun all tests. However, if I modify something in , then still ignores the tests that completed successfully in the previous run. Steps to reproduce: tests: . For example, replace the function in  with: tests again: Expected output: some tests fail. Actual output:
I would be interested in fixing this issue myself if someone could give me some guidance on how to do that. The main thing that I do not understand is how understands that was changed. It seems that it does not use files for this because they include only the hash of the configuration options which do not include version. cc
The most likely culprit (that ignores the test files) is in module. It is called from and will set the flag for the test depending on its output.
That being said, I find it hard to see how to adjust compiletest itself to take the dependencies into account. rustbuild should probably have some sort of dependency edge and delete the stamp files if/when stuff like compiletest changes.
Compiletest source code has only 9 files. Would it be acceptable to check that their timestamps are newer than the timestamp of the stamp file? PR:
Change:
} pub fn walk_vis<'a, V: Visitor<'a>>(visitor: &mut V, vis: &'a Visibility) { <del> if let VisibilityKind::Restricted { ref path, id } = vis.kind { </del> <ins> if let VisibilityKind::Restricted { ref path, id, shorthand: _ } = vis.kind { </ins> visitor.visit_path(path, id); } }

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 this happen: it to print . Instead, this happened: it prints . <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.62.1 <!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-beta -regression-untriaged -- modify labels: +regression-from-stable-to-beta -regression-untriaged
Similar effect can already be observed on stable too prints already. But it is indeed a (small?) behavior change in this beta for the case.
I would expect to see this issue in 2020, but not now when we are collecting tokens in (almost) all cases instead of converting them from AST. Apparently for visibilities they are collected incorrectly for some reason. cc (in case you have time for this)
bisection points to searched nightlies: from nightly-2022-01-01 to nightly-2022-08-03 regressed nightly: nightly-2022-05-24 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </detailsThe commit is a rollup so I think_ it's in cc ?
Without even looking at the rest of the rollup, it's definitely my PR. Short of storing whether was used, I'm not sure what could be done.
This will slip into 1.63.

I'll work on this this evening to get it resolved quickly, even if it is too late to patch the beta. I don't think it'll be too difficult.
PR is up: . This also fixes to be , which is certainly better than the status quo of .
Change:
use rustc_data_structures::fx::{FxHashMap, FxHashSet}; use rustc_data_structures::sync; use rustc_hir::def_id::DefIdSet; <ins> use rustc_middle::mir; </ins> use rustc_middle::mir::mono::MonoItem; use rustc_middle::mir::mono::{CodegenUnit, Linkage}; use rustc_middle::ty::print::with_no_trimmed_paths;

Discussion:
This can be seen here: To reproduce:
Last passing run was so this regressed between 2022-06-30 and 2022-07-02.
Minimized a reproducer. : : Execution:
label regression-untriaged
Bisection says searched nightlies: from nightly-2022-06-29 to nightly-2022-07-03 regressed nightly: nightly-2022-07-03 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsSo,
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Unfortunately while this fixes the minimal reproducer, it doesn't fix the full case. Would you prefer I file a new bug, or should this one be re-opened? To reproduce:
It's not very minimized, but slightly better. : : Empty
searched nightlies: from nightly-2022-07-07 to nightly-2022-07-22 regressed nightly: nightly-2022-07-09 searched commits: from to regressed commit:
Interesting, I had assumed based on the matching panic message that it'd have the same regressing commit.
Happy to report that with the latest nightly we're back to green on nightly. Thanks much
Thanks the first fix was enough for Suricata :-)
Thanks so much, pydantic-core has been pinned to but is not back on nightly.
Change:
/// ``` #[inline] #[stable(feature = "unreachable", since = "1.27.0")] <del> #[rustc_const_unstable(feature = "const_unreachable_unchecked", issue = "53188")] </del> <ins> #[rustc_const_stable(feature = "const_unreachable_unchecked", since = "1.57.0")] </ins> pub const unsafe fn unreachable_unchecked() -> ! { // SAFETY: the safety contract for `intrinsics::unreachable` must // be upheld by the caller.

Discussion:
Currently one cannot call in constant functions, so one cannot add hints of the form: These types of hints can heavily influence code generation, which can substantially change the performance of when they are invoked at run-time. It would be a shame to have to write and call and because the code generated for is sub-par. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
One cannot do any sort of conditional control flow, so would currently be less than useless. Any test you can write would be undefined behaviour
the RFC for / in const was merged and is pending an implementation right? When that's implemented, will still be useless?
No it makes sense after we have conditional control flow.
As I understand / in const functions is now implemented. Can be made into a now?
yes. Basically you just need to add the attribute to the intrinsic and wrapper function. This is documented at https://rustc-dev- Let me know if anything is unclear (in which case we should update the guide)
Hi, It looks like previous PR is not being worked on currently. I'm working on this and will create a PR soon. claim
As mentioned in , this issue should be reopened (to track stablization)
cc ^
After a short discussion on Zulip, it was decided that it's best to wait for to stabilize to avoid a potential footgun wherein users use this instead of , leading to UB at runtime. I'm subscribed to the issue and intend to file a PR to stabilize this once the aforementioned happens.
Change:
"riscv32" => Architecture::Riscv32, "riscv64" => Architecture::Riscv64, "sparc64" => Architecture::Sparc64, <ins> "avr" => Architecture::Avr, "msp430" => Architecture::Msp430, "hexagon" => Architecture::Hexagon, "bpf" => Architecture::Bpf, </ins> // Unsupported architecture. _ => return None, };

Discussion:
sure the is installed. Optionally install  for convenience. . Use commit specifically. any rust nightly after (I am using / for the error below). the following command: With a working compiler (I used / for this example), I expect compilation to succeed: Instead, I get a link error about a missing symbol, and cannot link any code that doesn't optimize it out (so everything with and sometimes higher s?): The target doesn't support unwinding (and I don't imagine it ever will), only aborting panics. So I'm not sure why is being linked in in the first place (or how compilation should be fixed). searched nightlies: from nightly-2022-08-07 to nightly-2022-09-21 regressed nightly: nightly-2022-09-08 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
WG-prioritization assigning priority (). thanks for the bisection. It leads to cc: label -I-prioritize +P-medium
~This issue should be fixed by Could you test it once that PR lands into nightly?~ This is a different issue.
This should be fixed by
I rebuilt Rust w/ and then tested against the code I linked in the initial post, and linking in debug mode succeeded; will indeed fix the issue.
Change:
ret @respan(sp, ast.item_obj(i, ob, ty_params, id, a)); } <ins> // View Item folds. fn identity_fold_view_item_use[ENV](&ENV e, &span sp, ident i, vec[@meta_item] meta_items, def_id id) -> @view_item { ret @respan(sp, ast.view_item_use(i, meta_items, id)); } fn identity_fold_view_item_import[ENV](&ENV e, &span sp, vec[ident] is, def_id id) -> @view_item { ret @respan(sp, ast.view_item_import(is, id)); } </ins> // Additional identities.

Discussion:
I was trying to build the stdlibs for the target like this: However, the build fails with the following error: Here is the full build log: I'm using Xubuntu 15.10. At the time of building, the Rust master was at .
Unfortunately is a which means that we don't guarantee that it builds in-tree right now. Patches are certainly welcome to fix this, however! We tend to not keep issues tracking build support for all Tier 3 platforms, however, so I'm going to close this. If you're interested in promoting this to at least tier 2 you could also help modify out to be able to support this target!
Change:
/// # Examples /// /// ``` <del> /// #![feature(cell_filter_map)] /// </del> /// use std::cell::{RefCell, Ref}; /// /// let c = RefCell::new(vec![1, 2, 3]);

Discussion:
Feature gate: This is a tracking issue for and , which lets you optionally project data inside a or , wrapped in a or . If the projection returns then these methods return a so that you can still get the original or back out. [x] Implementation: [x] Final commenting period (FCP) [ ] Stabilization PRNaming and signature: We wanted to call this method and accept a closure like , but that's not sound with bound lifetimes. This method is only ok when the mapping closure uses HRTB. So we opted to call it instead, with the closure returning a .
I am in need of this API for my library in order to be able to have an efficient implementation that avoids unsafe Rust code. I wonder, why is the goal to have instead of since I can see a great value in having both APIs available. So if is already good to go we could stabilize that one and later add as soon as all open questions for it are resolved.
The name seems unusual for something that returns a - for example, returns an iterator with filtering built in. The equivalent method already exists in the Mutex implementations of , under the name . In both cases the closure it accepts returns and not the more general . So maybe the name should be reconsidered in that light.
I'm also interested in the stabilization of this API for the same reason as However, I also agree that should be named since it returns a . As an API user it makes more sense to me.
I wonder if we can have a generic filter & map for any inner enum instead of just Option. For example in this code As the code show, ref is compared twice to get the result. Is there any way to make it simpler?
fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [x] [ ] [x] [x] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), 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.
:bell: This is now entering its final comment period, as per the .

:bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon.
Change:
impl_clone! { usize u8 u16 u32 u64 u128 isize i8 i16 i32 i64 i128 <del> f32 f64 </del> <ins> f16 f32 f64 f128 </ins> bool char }

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. --Playground nightly version: 1.79.0-nightly (2024-03-25 ) This isn't expected since it doesn't seem to hit a label +T-compiler +f-f16andf128 +I-ICE +requires-incomplete-features +S-has-mcve claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label -needs-triage
Minimized:
Looks like it just expects primitives to be . I'm not sure where exactly this assumption comes from, but might as well fix it before the rest of libs support can get merged.