jiebi/CodeConvo huggingface dataset:
Change:
endif $$(Q)$$(S)src/rust-installer/gen-installer.sh  --product-name=Rust  <del> --verify-bin=rustc  </del> --rel-manifest-dir=rustlib  --success-message=Rust-is-ready-to-roll.  --image-dir=tmp/dist/$$(PKG_NAME)-$(1)-image  --work-dir=tmp/dist  --output-dir=dist  <del> --non-installed-prefixes=$$(NON_INSTALLED_PREFIXES)  </del> <ins> --non-installed-overlay=tmp/dist/$$(PKG_NAME)-$(1)-overlay  </ins> --package-name=$$(PKG_NAME)-$(1)  --component-name=rustc  --legacy-manifest-dirs=rustlib,cargo

Discussion:
There are a few issues of polish that I want to fix here: Although the installer internally supports multiple components there is no interface for actually selecting individual components. This is important because it allows to not install docs, which are 250 MB of the 50 MB install. Uninstallation can only be done through the original installer, which in many cases means the user is going to have to download the installer again. I want to put an uninstall script in the installation. This will require some refactoring and an upgrade of the installer manifest format.
This is a prereq for my plan to fix the .pkg uninstall issue
cc
cc
Change:
#![feature(hasher_prefixfree_extras)] #![feature(hashmap_internals)] #![feature(ip)] <del> #![feature(ip_in_core)] </del> #![feature(maybe_uninit_slice)] #![feature(maybe_uninit_uninit_array)] #![feature(maybe_uninit_write_slice)]

Discussion:
Feature gate: This is a tracking issue for RFC , providing networking types in : , , , , , , and . [x] Implementation: [x] Final comment period (FCP)[^1] [x] Stabilization PR: [^1]: https://std-dev-
I guess there's nothing left to do. Can this feature now move to the the FCP?
Can this be stabilized before  ( implements )?
I believe so. Nothing in ipaddr points or uses core::error::Error: (master) The only impl Error is in Parser and I guess it needs to be featured gated:
You can't feature gate a trait implementation. The question would be if it's possible to refer to any of the methods on the error types without having to activate the feature. I believe not, since you would have to in order to bring the methods into scope.
Thanks for the explanation and yes, I agree that it can't be stabilised before Error then.
I disagree, this feature can be specialized before . Nothing will change for users, and users will merely not be able to use the impl. This is just like all existing errors in , eg (which is arguably stable):
Ping could this go into FCP?
Yes, please.
nominate libs
Error: The feature is not enabled in this repository. To enable it add its section in the in the root of the repository. Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
maybe? Would like to get some confirmation that this is on some list somewhere for discussion.
I've the nomination label so it'll be discussed in a libs-api meeting, though it's possible a libs-api member may decide to remove the label and just fcp it. It'd likely be helpful if someone could provide a summary of the current state of things and why this is ready for stabilization.
I'm not claiming this bears enough weight to stabilize but I just allowed in a small library that used address types and it went completely smooth.
Starting FCP for stabilization. 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.
I pushed a stabilization PR:
Change:
<ins> // run-pass #![allow(dead_code)] enum OpenResult { Ok(()), Err(()), TransportErr(TransportErr), } #[repr(i32)] enum TransportErr { UnknownMethod = -2, } #[inline(never)] fn some_match(result: OpenResult) -> u8 { match result { OpenResult::Ok(()) => 0, _ => 1, } } fn main() { let result = OpenResult::Ok(()); assert_eq!(some_match(result), 0); let result = OpenResult::Ok(()); match result { OpenResult::Ok(()) => (), _ => unreachable!("message a"), } match result { OpenResult::Ok(()) => (), _ => unreachable!("message b"), } } </ins>

Discussion:
I tried this code (reduced from a much larger test): () I expected to see this happen: runs with 0 exit code and no output Instead, this happened: This code works on stable and beta, and as recently as . This reproduces with the 2022-11-16 nightly on the playground. this was introduced by . modify labels: +regression-from-stable-to-nightly -regression-untriaged <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
That looks like a real miscompilation :( cc
WG-prioritization assigning priority (). label -I-prioritize +P-high
I've found the problem; it is indeed an issue with my code in . I'll have a PR with a fix some time today.
Since there is some work in progress to fix this: assign
Change:
let mut err = struct_span_err!( tcx.sess, impl_item.span, E0520, "`{}` specializes an item from a parent `impl`, but  <del> neither that item nor the `impl` are marked `default`", </del> <ins> that item is not marked `default`", </ins> impl_item.name); err.span_label(impl_item.span, &format!("cannot specialize default item `{}`", impl_item.name));

Discussion:
Because the itself cannot be marked , only the individual item.
Hi, I'm very new to rust and I'm trying to learn more about this language. I would like to make the change. Seems that I have to change the error text (e.g. ..., but the item of the parent impl is not marked ), Is it right? However searching about specialization documents I found this issue where seems that a will be possible. Am i missing something?
The text should suggest that the item could be , but not that the parent impl could be, because it can't. It might be in the future (as suggested by ) but that is not certain.
Hi , I'm seeing a bit more deep the specialization feature. I'm wondering if I can try to implement the . I have in mind to do what is described in the following quotes taken from the RFC For the moment, with this implementation, the must define all items of the trait (not a part of them) and, therefore, they will be all treated as default items. Would you accept a PR for this?
there is some debate at the moment about some of the details of specialisation. It would probably be best to open a thread on before starting to work on this.
PR was merged, so this can be closed now.
Change:
<ins> WARN rustc_infer::infer::relate::generalize may incompletely handle alias type: AliasTy { args: [?1t, '^0.Named(DefId(0:15 ~ structually_relate_aliases[de75]::{impl#1}::'a), "'a")], def_id: DefId(0:5 ~ structually_relate_aliases[de75]::ToUnit::Unit) } WARN rustc_infer::infer::relate::generalize may incompletely handle alias type: AliasTy { args: [?1t, !2_0.Named(DefId(0:15 ~ structually_relate_aliases[de75]::{impl#1}::'a), "'a")], def_id: DefId(0:5 ~ structually_relate_aliases[de75]::ToUnit::Unit) } error[E0277]: the trait bound `for<'a> T: ToUnit<'a>` is not satisfied --> $DIR/structually-relate-aliases.rs:13:36 | LL | impl<T> Overlap<for<'a> fn(&'a (), Assoc<'a, T>)> for T {} |                                    ^^^^^^^^^^^^ the trait `for<'a> ToUnit<'a>` is not implemented for `T` | help: consider restricting type parameter `T` | LL | impl<T: for<'a> ToUnit<'a>> Overlap<for<'a> fn(&'a (), Assoc<'a, T>)> for T {} |       ++++++++++++++++++++ error[E0277]: the trait bound `for<'a> T: ToUnit<'a>` is not satisfied --> $DIR/structually-relate-aliases.rs:13:17 | LL | impl<T> Overlap<for<'a> fn(&'a (), Assoc<'a, T>)> for T {} |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `for<'a> ToUnit<'a>` is not implemented for `T` | help: consider restricting type parameter `T` | LL | impl<T: for<'a> ToUnit<'a>> Overlap<for<'a> fn(&'a (), Assoc<'a, T>)> for T {} |       ++++++++++++++++++++ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '-Znext-solver=coherence -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'assertion failed: obligations.isempty()'', 'thread 'rustc' panicked at 'assertion failed: obligations.isempty()'' 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: [specializationgraphof] building specialization graph of trait [coherent_trait] coherence checking all impls of trait [analysis] running analysis passes on this crate --
cc
Probably due to the fact that doesn't preserve the flag.
should be fixed by
With the output is ...
should add the following as a test
Hello, I'm a beginner and I would like to contribute to Rust. Since this issue has been marked as "Easy," what is the desired behavior of this program and how can I approach it? Any help would be appreciated.
This is marked E-needs-test, so the only change here would be to add this test to the test suite, since the issue has been fixed.
Change:
} } <del> /// Tests whether this is the AST for a reference to the type /// parameter with ID `param_id`. We use this so as to avoid running /// `ast_ty_to_ty`, because we want to avoid triggering an all-out /// conversion of the type to avoid inducing unnecessary cycles. fn is_param(tcx: TyCtxt<'_>, ast_ty: &hir::Ty<'_>, param_id: hir::HirId) -> bool { if let hir::TyKind::Path(hir::QPath::Resolved(None, path)) = ast_ty.kind { match path.res { Res::SelfTy(Some(def_id), None) | Res::Def(DefKind::TyParam, def_id) => { def_id == tcx.hir().local_def_id(param_id).to_def_id() } _ => false, } } else { false } } </del> fn convert_item(tcx: TyCtxt<'_>, item_id: hir::ItemId) { let it = tcx.hir().item(item_id); debug!("convert: item {} with id {}", it.ident, it.hir_id());

Discussion:
Given the following code: The current output is: Ideally, the diagnostic shouldn't suggest relaxing an explicit bound in the where clause. (There is already code that skips the suggestion for type parameters that have an explicit bound.) I can work on this in an in-progress pull request where I'm making other improvements to unsized suggestions. claim label +A-traits +A-typesystem +D-papercut <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Change:
// Yield let state = 3 + self.suspension_points.len(); <ins> // The resume arg target location might itself be remapped if its base local is // live across a yield. let resume_arg = if let Some(&(ty, variant, idx)) = self.remap.get(&resume_arg.local) { self.make_field(variant, idx, ty) } else { resume_arg }; </ins> self.suspension_points.push(SuspensionPoint { state, resume,

Discussion:
I tried this code: I expected to see see the output "Person is Mood", instead, I got a segfault: : <details<summaryBacktrace</summary<p</p</details
Heh, looks like my "fix" for the miscompilation I found while implementing this wasn't actually sufficient. Reduced to: Looking at the MIR, you can see: The first leads to , which stores the resume argument from in the generator state as and advances to the next state (discriminant 3). On the next call it resumes at , which doesn't store the resume argument in the state (it only moves it to ). Here, the argument should have ended up in the generator state as some field. It then sets the discriminant to 4 to resume at . The next call thinks is still live and uses it to call the function. MIR of (minus storage statements):
Hmm, on second thought, it seems weird that is not put in the generator state at all, I would expect the existing transform infrastructure to handle this. cc
Looking at the MIR generated for reduced test case we can see that the writes that should have been to is instead done to the generator : So this seems to be a problem in MIR construction.
Hmm: I assume this isn't correct anymore? ( probably should have been replaced with the newly introduced field in ? )
Well that would explain why the MIR looks wrong.
I suspect this is because doesn't consider terminators as writes.
Thought I'd fix the printing real quick I'll look into the real bug tomorrow or some time next week, but the pass does indeed look wrong now.
I don't know much about rustc internals but it seems these places seem relevant somehow?
Yes, that's the issue I was referring to.
This patch makes the generator layout look more reasonable (actually containing slots for the s), but doesn't fix the crash. In fact, it makes the test miscompile too:
Well, afaict the main issue here is that the transformation which replaces the s with generator struct accesses is run before creating the actual resume function which emits the store of the resume argument to a local which should've been replaced. This happens: before this: I've tested the follwing patch (Hacky, we probably want to use the somehow): (Most of the diff is not relevant to the patch, contains the fix).

And it produces correct MIR code: EDIT: The original code contains a logic bug, every loop iteration a new empty is created , which is probably not intended, instead moving that binding to the outer scope should "fix" it. EDIT: And passes too. EDIT: Also I've just stupidly realized that the unwrap for should probably be avoided too since a local may not live across a suspension point.
I probably would have noticed that if not for that pesky segfault
That's a great start! I've opened a fix (+ cleanup + more docs) based on the same idea in
Change:
self.msg_span_from_early_bound_and_free_regions(region) }, ty::ReStatic => ("the static lifetime".to_owned(), None), <del> _ => bug!(), </del> <ins> _ => bug!("{:?}", region), </ins> } }

Discussion:
I got ICE for sometime and also searched in issues but cannot find a relative one. Sorry for not able to produce the minimal cases to pin down the actual failing case in my code base by simply reverting my code. x This issue does not exists in . Error message as follows: meta for 2018-03-21 meta for 2018-03-24 I appreciate any hints and suggestions on helping me to reproduce this issue into minimal case but right now I just can't find out what changes in my code caused this problem. My code base is
I have dig into this and found the snippet of code caused this problem: It should produce an error which did not appeared in previous build This is not the whole story, when I assign to a variable and return the variable, it got the same ICE but the type inference error gone. I finally able to mitigate the problem by turning the return type from to
I got a possibly same ICE with this code: Meta: <detailsBacktrace: </details
This gives me the same ICE: However this does not ICE:
Hi all. does not fix my issue.
Sorry, I forgot to test with your case. Though you seem to be using a nightly-2018-03-23 which can never contain unmerged , right? depends on which is not even compilable with recent nightlies.
Hi, sorry for the slow reply. I will try that again once the branch have been merged. Any ETA on when it will go into nightly? Thanks
No, it varies due to approval of other PRs. Here is the current queue:
Nightly 2018-04-14 contains . Could you reopen if the problem persists?
As at least one data point, I had the same issue and it was resolved with 2018-04-15.
Change:
#![stable(feature = "rust1", since = "1.0.0")] use prelude::*; <del> use fmt::Display; </del> <ins> use fmt::{Debug, Display}; </ins> /// Base functionality for all errors in Rust. <del> #[unstable(feature = "core", reason = "the exact API of this trait may change")] pub trait Error: Display { /// A short description of the error; usually a static string. </del> <ins> #[stable(feature = "rust1", since = "1.0.0")] pub trait Error: Debug + Display + Send { /// A short description of the error. /// /// The description should not contain newlines or sentence-ending /// punctuation, to facilitate embedding in larger user-facing /// strings. #[stable(feature = "rust1", since = "1.0.0")] </ins> fn description(&self) -> &str; /// The lower-level cause of this error, if any. <ins> #[stable(feature = "rust1", since = "1.0.0")] </ins> fn cause(&self) -> Option<&Error> { None } }

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:
If you do, Rust has been installed successfully! Congrats! <del> If you don't and you're on Windows, check that Rust is in your %PATH% system variable: `$ echo %PATH%`. If it isn't, run the installer again, select "Change" on the "Change, repair, or remove installation" page and ensure "Add to PATH" is installed on the local hard drive.  If you need to configure your path manually, you can find the Rust executables in a directory like `"C:Program FilesRust stable GNU 1.xbin"`. </del> <ins> If you don't, that probably means that the `PATH` environment variable doesn't include Cargo's binary directory, `~/.cargo/bin` on Unix, or `%USERPROFILE%.cargobin` on Windows. This is the directory where Rust development tools live, and most Rust developers keep it in their `PATH` environment variable, which makes it possible to run `rustc` on the command line. Due to differences in operating systems, command shells, and bugs in installation, you may need to restart your shell, log out of the system, or configure `PATH` manually as appropriate for your operating environment. </ins> Rust does not do its own linking, and so you’ll need to have a linker installed. Doing so will depend on your specific system. For

Discussion:
Specifically at , and recommend for Windows too, right? We've , but in the meantime, the old book should recommend the new recommended toolchain :) If it's too soon to do this because isn't stable enough yet, consider this a reminder issue to make this change once it is :)
wants to wait a bit, and we'd need to then make sure to update the website in sync (see )
Maybe the big red warning "this is beta software" should be removed from the website?
This will be fixed by
Change:
|              not allowed in type signatures |              help: replace `_` with the correct type: `i32` <del> error: aborting due to 67 previous errors </del> <ins> error: aborting due to 69 previous errors </ins> Some errors have detailed explanations: E0121, E0282, E0403. For more information about an error, try `rustc --explain E0121`.

Discussion:
Hello, While trying to figure out how to keep a JoinHandle in a thread-local variable, I tried compiling this incorrect code, and rust crashed. It will not panic if I use a regular static var instead of in a block. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
The ICE happens since 1.44 label: +regression-from-stable-to-stable
ping icebreakers-cleanup-crew can we add a bit more detail and trace where this starts?
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Assigning as discussed as part of the and removing . label -I-prioritize +P-medium
Regression between ... If I had to guess, I would say
Reduced testcase:
Not sure if of any help, but the thread_local macro is not needed:
const : Option<= map(value); ;)
Change:
None => match rscope.anon_regions(default_span, 1) { Ok(rs) => rs[0], Err(params) => { <del> let mut err = struct_span_err!(self.tcx().sess, default_span, E0106, "missing lifetime specifier"); </del> <ins> let ampersand_span = Span { hi: default_span.lo, ..default_span}; let mut err = struct_span_err!(self.tcx().sess, ampersand_span, E0106, "missing lifetime specifier"); err.span_label(ampersand_span, &format!("expected lifetime parameter")); </ins> if let Some(params) = params { report_elision_failure(&mut err, params); }

Discussion:
From: src/test/compile- Error E0106 needs a span_label, updating it from: To:
I'll try this one.
I think "expected lifetime parameter" is a better label. bonus: have the label on the ampersand only.
to suggestions
Do you mean like this? Or like this, with the primary span changed?
I think he means the second one:
Change:
function usableLocalStorage() { // Check if the browser supports localStorage at all: <del> if (typeof(Storage) === "undefined") { </del> <ins> if (typeof Storage === "undefined") { </ins> return false; } // Check if we can access it; this access will fail if the browser

Discussion:
Right now it is allowed to select whether we want to search within all crates or in the specific ones (e.g. core, std, etc). It would be really useful to remember the selected option, because in most cases we want to search in the std crate only. cc
Good idea!
Does not work, neither in stable nor nightly. Go to Choose the "std" option. Type Option, click on it We still see the "All crates" on the , and if we try to search something else, results will be from all sources anyway.
Indeed, will take a look quickly.
Works perfectly now. Thanks!
Change:
<ins> error[E0491]: in type `&'a &'b ()`, reference has a longer lifetime than the data it references --> $DIR/impl-header-unnormalized-types.rs:15:18 | LL |     type Assoc = &'a &'b (); |                  ^^^^^^^^^^ | note: the pointer is valid for the lifetime `'a` as defined here --> $DIR/impl-header-unnormalized-types.rs:14:6 | LL | impl<'a, 'b> NeedsWf<'a, 'b> for Foo<<&'a &'b () as GoodBye>::Forget> { |      ^^ note: but the referenced data is only valid for the lifetime `'b` as defined here --> $DIR/impl-header-unnormalized-types.rs:14:10 | LL | impl<'a, 'b> NeedsWf<'a, 'b> for Foo<<&'a &'b () as GoodBye>::Forget> { |          ^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0491`. </ins>

Discussion:
this compiles with because we now assume unnormalized types in the impl header to be well formed when computing implied bounds. We don't check that when using the impl so we should be able to transmute lifetimes with this, though I haven't tried that yet. Going to fix that myself once I am back home in 2 weeks. cc
assigning after a very long and deep discussion in https://rust-
(FYI I also nominated PR for discussion at T-compiler meeting, essentially because of this associated issue; I hadn't seen that this was tagged as P-critical at that time. I'm leaving it nominated for now, just to ensure doubly that we discuss the matter.)
this is an existing issue on stable if we prevent the projection from normalizing in the impl while normalizing it when using the impl: that's the same issue as , which has been only fixed for function signatures edit: that's