jiebi/CodeConvo huggingface dataset:
Change:
Wrapping(self.0.wrapping_shl((other & self::shift_max::$t as $f) as u32)) } } <ins> forward_ref_binop! { impl Shl, shl for Wrapping<$t>, $f, #[stable(feature = "wrapping_ref_ops", since = "1.39.0")] } </ins> #[stable(feature = "op_assign_traits", since = "1.8.0")] impl ShlAssign<$f> for Wrapping<$t> {

Discussion:
The other day I noticed that only implements and co. for , which contradicts that without the shift amount can be any type. So, I think it may be useful to create tests which use macros to shove together all the types we expect to have impls for and check that we're consistent there. What I've noticed: For every operation three extra impls are , with the combinations of single-level references on both sides, e.g. , , for . Assignment ops do the same as the above, with only one extra impl, e.g. for . , , , , exist for all int and float types with themselves , , exist for all int types and bool and allow any integer type for both the left and the right side exists for all ints and floats exists for all ints and bool should mimic all of the above, where references are of the form and not . Like, I wouldn't be surprised if rearranging some macros might add or remove impls for these and adding comprehensive tests might help make sure we covered everything. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This seems like a simple but useful task, I will try to finish it.
I am reformulating the task to make sure it is clear (to myself at least) : Create tests using a set of macros to check that every numerical instances of for the following operations are implemented for every combination of numerical instances (, , ...) : with : * having the integer and float types with themselves, ¤ having the integer and bool types with themselves, having the integer and float types with themselves, and Am I correct ? How does this relate to ?(e.g. is it possible to bypass the bug and still implement the test ? I could not see from the issue if a solution had been found)
claim isn't implemented for and /. So this is probably only useful for integer types.
This doesn't actually fix the issue; it should be tested for all types, not just .
Hi ! Are you or anyone else working on adding the missed tests?
They're free for anyone to implement right now!
Nope, not right now. Feel free to take over.

It should be pretty similar to , just add the missing types (bool, fp) and operators (bit wise operators).
Thank you very much and , I'll send a PR.
unassign
claim I'll try to get a PR in by next weekend, If nothing happens past that I'm afraid I may have been too busy so [anyone] feel free to overtake :smile:
claim
Hi, are you still working on this issue
I'm sorry, I couldn't do it. Please feel free to reassign this.
No worries release-assignment
Change:
}; // Check the qualifs of the value of `const` items. <del> // FIXME(valtrees): check whether const qualifs should behave the same // way for type and mir constants. </del> let uneval = match constant.literal { ConstantKind::Ty(ct) <del> if matches!(ct.kind(), ty::ConstKind::Param(_) | ty::ConstKind::Error(_)) => </del> <ins> if matches!( ct.kind(), ty::ConstKind::Param(_) | ty::ConstKind::Error(_) | ty::ConstKind::Value(_) ) => </ins> { None } <del> ConstantKind::Ty(c) => bug!("expected ConstKind::Param here, found {:?}", c), </del> <ins> ConstantKind::Ty(c) => { bug!("expected ConstKind::Param or ConstKind::Value here, found {:?}", c) } </ins> ConstantKind::Unevaluated(uv, _) => Some(uv), ConstantKind::Val(..) => None, };

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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
regressed in
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
pub(crate) fn print_visibility(&mut self, vis: &ast::Visibility) { match vis.kind { ast::VisibilityKind::Public => self.word_nbsp("pub"), <del> ast::VisibilityKind::Restricted { ref path, .. } => { </del> <ins> ast::VisibilityKind::Restricted { ref path, id: _, shorthand } => { </ins> let path = Self::to_string(|s| s.print_path(path, false, 0)); <del> if path == "crate" || path == "self" || path == "super" { </del> <ins> if shorthand && (path == "crate" || path == "self" || path == "super") { </ins> self.word_nbsp(format!("pub({})", path)) } else { self.word_nbsp(format!("pub(in {})", path))

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:
} } <del> pub fn new_filemap(&self, filename: FileName, src: String) -> Rc<FileMap> { </del> <ins> pub fn new_filemap(&self, filename: FileName, mut src: String) -> Rc<FileMap> { </ins> let mut files = self.files.borrow_mut(); let start_pos = match files.last() { None => 0,

Discussion:
cc
The rfc says It also includes an example which depends on usize: However RangeArgument only implements the first four. Furthermore as things stand it does not appear possible to accept RangeArgument<usizeand usize simultaneously, because dispatch doesn't consider the trait bound and reports that conflicting implementations exist.
Yes, was explicit about these issues. I forsee a new RFC to finish off drain and maybe the RangeArgument trait.
I believe this has
Change:
}, }); <del> (opt_self, true) </del> <ins> (opt_self, Defaults::Allowed) </ins> } ItemKind::TyAlias(..) | ItemKind::Enum(..) | ItemKind::Struct(..) | ItemKind::OpaqueTy(..) <del> | ItemKind::Union(..) => (None, true), _ => (None, false), </del> <ins> | ItemKind::Union(..) => (None, Defaults::Allowed), _ => (None, Defaults::FutureCompatDisallowed), </ins> } } <del> _ => (None, false), </del> <ins> // GATs Node::TraitItem(item) if matches!(item.kind, TraitItemKind::Type(..)) => { (None, Defaults::Deny) } Node::ImplItem(item) if matches!(item.kind, ImplItemKind::TyAlias(..)) => { (None, Defaults::Deny) } _ => (None, Defaults::FutureCompatDisallowed), </ins> }; let has_self = opt_self.is_some();

Discussion:
I tried this code: I expected to see this happen: It not work correctly as if you remove it shouts at you saying its unsupported and will be a hard error one day. Instead, this happened: defaults on GATs seem to function perfectly fine version from playground: cc this is probably should either be allowed or a hard error before stabilisation?
one issue is that we ignore defaults on the gat in impls
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
" )) <ins> (ert-deftest indent-match () (test-indent " fn foo() { match blah { Pattern => stuff(), _ => whatever } } " )) (ert-deftest indent-match-multiline-pattern () (test-indent " fn foo() { match blah { Pattern | Pattern2 => { hello() }, _ => whatever } } " )) (ert-deftest indent-indented-match () (test-indent " fn foo() { let x = match blah { Pattern | Pattern2 => { hello() }, _ => whatever }; y(); } " )) (ert-deftest indent-curly-braces-within-parens () (test-indent " fn foo() { let x = foo(bar(|x| { only_one_indent_here(); })); y(); } " )) (ert-deftest indent-weirdly-indented-block () (rust-test-manip-code " fn foo() { { this_block_is_over_to_the_left_for_some_reason(); } } " 16 #'indent-for-tab-command " fn foo() { { this_block_is_over_to_the_left_for_some_reason(); } } " )) (ert-deftest indent-multi-line-attrib () (test-indent " #[attrib( this, that, theotherthing)] fn function_with_multiline_attribute() {} " )) ;; Make sure that in effort to cover match patterns we don't mistreat || or expressions (ert-deftest indent-nonmatch-or-expression () (test-indent " fn foo() { let x = foo() || bar(); } " )) </ins> (setq rust-test-motion-string " fn fn1(arg: int) -> bool {

Discussion:
There are several common cases where the emacs mode gets the indentation incorrect. I'll list the examples as I believe they should be formatted. indent after open paren with no argument: with arguments: field names:
Oh, and the motivating example for filing the bug: comments don't work quite right. and also you should be able to hit M-q and have it reflow correctly.
I've found trailing line comments breaks the indentation of the next line: (Not sure if this is worth a separate bug.)
Another example is a pattern relative to an indented match: Also, I believe patterns in general are indented incorrectly, though admittedly I'm not sure what the standard is. My preference is to keep all patterns at the same level of indentation, as shown here:
If we're going to fix , we should try to also take the time to fix the other doc comment variations, namely , if possible.
part of
Change:
default: warn }), <del> ("dead_code", </del> <ins> (DEAD_CODE_LINT_STR, </ins> LintSpec { lint: DeadCode, desc: "detect piece of code that will never be used",

Discussion:
Currently if you have some dead_code and you want to preserve it, you have to annotate every function you want to preserve and all the dead code that function calls. I think we should consider annotated code to be alive, and then all the code that touches to be alive as well.
cc sounds like a cool idea to me.
By "annotate", do you mean putting an attribute above the function you want to preserve?
yes.
Change:
/// There may be multiple cycles involved in a deadlock, so this searches /// all active queries for cycles before finally resuming all the waiters at once. #[cfg(parallel_compiler)] <del> pub fn deadlock<CTX: QueryContext>(tcx: CTX, registry: &rayon_core::Registry) { </del> <ins> pub fn deadlock(query_map: QueryMap, registry: &rayon_core::Registry) { </ins> let on_panic = OnDrop(|| { eprintln!("deadlock handler panicked, aborting process"); process::abort(); }); let mut wakelist = Vec::new(); <del> let query_map = tcx.try_collect_active_jobs().unwrap(); </del> let mut jobs: Vec<QueryJobId> = query_map.keys().cloned().collect(); let mut found_cycle = false;

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. --code from glacier <!-- 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. --: NOTE this is the alt master rustc, installed via <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This features a parallel-compiler-only bug. It is a variant of It is ultimately a blocker for and might be a blocker for but itself does not need to be fixed any time soon.
Remark from
This is not a problem with the implementation logic of the deadlock handler, but a very hard-to-trace thread scheduling vulnerability. If we add the following non-functional statement in of the function, this problem will disappear. Get rid of in deadlock handler can fix this. I just submited a to fix a set of ui test failures, including this issue.
Change:
option = "-s" # If curl is not present on Win32, we should not sys.exit #   but raise `CalledProcessError` or `OSError` instead <del> require(["curl", "--version"], exception=platform_is_win32) </del> <ins> require(["curl", "--version"], exception=platform_is_win32()) </ins> with open(path, "wb") as outfile: run(["curl", option, "-L", # Follow redirect.

Discussion:
I tried this: I expected to see this happen: Bootstrap rebuilds the compiler. 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. --is
In particular, this happens when rust-analyzer is running in the background and you have this config set: We currently recommend that config in https://rustc-dev-
This would be fixed by having a "public" and "private" sysroot: https://rust-
This happens because Windows doesn't allow deleting a running executable/DLL. The way forward would be to special-case it as it is already the case with the file and ignore failures, or to make a double sysroot as you proposed.
You can usually rename a running executable so it may be possible to simulate a delete by moving it within the same filesystem. However, having a public and a private sysroot seems like a more generally useful solution.
I'm happy with both solutions. I think special casing proc-macro-server in the short term seems fine, but if we do that, we should open another issue for the public and private sysroot.
Change:
let r = match f(self) { Ok(val) => Some(val), Err(error) => { <del> let diagnostic = error_to_const_error(&self.ecx, error); </del> use rustc::mir::interpret::InterpError::*; <del> match diagnostic.error { </del> <ins> match error.kind { </ins> Exit(_) => bug!("the CTFE program cannot exit"), Unsupported(_) | UndefinedBehavior(_)

Discussion:
The idea behind was that it should only show a backtrace (of where a Miri error originates) when an error is actually shown to the user. And that worked fine when I implemented it. But since then, something changed in constprop, and now I get thousands of backtraces even for crates with no errors, making the env var basically unusable. That is a big problem for debugging of the Miri engine. Even shouldn't show so many errors, but that will be harder to do for constprop which runs the CTFE engine on broken and non-monomorphized MIR (causing tons of problems, not just this). AFAIK you did a bunch of const_prop changes over the last few weeks/months; likely some of what you did is the culprit here. Any ideas?
Well. Const prop tries to eval things and if it fails it doesn't prop. The reason why there are many errors now is that we are actually using the interpcx instead of reimplementing its logic
I'm not sure how to reduce your noise. Maybe we can disable the env var before const prop and reenable after?
only prints when  is explicitly called -- somehow constprop must be triggering that. If that was fixed, things would still be slow because so many backtraces are captured, but at least the result should be readable.
The really fancy solution, but probably too magic, would be to determine if we are running inside a const_prop query and let that alter the behavior. AFAIK rustc uses thread-local storage so this could actually be done, but it might not be how that TLS is supposed to be used.
my guess is that the printing originates here: calls , but that line does not always result in an error to be shown, right?
Change:
args: Vec::new(), env: None, cwd: None, <ins> flags: 0, </ins> detach: false, stdin: None, stdout: None,

Discussion:
Now a tracking issue for on Windows. Open questions: Should we provide a method of adding* flags as opposed to setting them entirely? Would be a bit more composition-friendly. Also, don't forget to add to the prelude when stabilizing! There's a currently-unused codepath in the Windows implementation of that can set : It looks like historically there was a method to set this but it got removed. Unfortunately there's currently no way to set this, and no other way to set the flags, so for a project I'm working on I basically had to reimplement for Windows: I think we need some way to set this, even if it's Windows-specific. There are a bunch of other flags that can be specified, so maybe a way to set arbitrary flags would be useful? (v=vs.85).aspx I think this would fit nicely onto a Windows equivalent of the  trait, maybe something like:
Seems reasonable to me!
I'm always in favor of adding more Windows specific extension traits to expose useful functionality that other platforms don't seem to have.
I have a patch, it just took me a while to write a test for it. I'm trying to sort out the stability annotations for the new APIs--can I just use this issue as the tracking issue for the new feature?
Sure!
To the open question: I had first written the API as originally proposed: with a method to set the flags directly. Then I thought that might make it difficult if callers wanted to set different flags in different places, so I split it into and methods, but Alex asked me to change it back. I'm not sure it's that important, I don't think there are that many process creation flags that it would be useful to set from a library context, and callers can always aggregate flags into a u32 and just call with that value.
fcp merge With the one remaining open question I think it's safe to stabilize as this is still consistent with our approach to custom flags in other areas of platform-specific extensions as well.
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, 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: psst I wasn't able to add the label, please do so.
Change:
self.reserve(lower.saturating_add(1)); } unsafe { <del> ptr::write(self.get_unchecked_mut(len), element); </del> <ins> ptr::write(self.as_mut_ptr().add(len), element); </ins> // NB can't overflow since we would have had to alloc the address space self.set_len(len + 1); }

Discussion:
To my knowledge, the following code is intended to be legal: However, Miri currently flags this as UB. I believe this is , but for . Discovered while writing . cc
Yeah this looks pretty similar. uses under the hood though, so I wonder why the issue still exists here. Looks like is implemented via -- and indeed, this errors, too:
The problem is in this line: The here is a slice method, so this creates a slice covering the entire , which overlaps with the mutable reference created before and thus invalidates it.
It shouldn't be too hard to locally fix this, but that duplicates some code and there are some other uses of in . Ideally, this would all use raw slices to avoid making any uniqueness promises. But without , raw slices are not very useful.
Here's a possible fix:
Fix PR is up:
Change:
--> $DIR/issue-7575.rs:70:7 | LL |     t.is_str() <del> |       ^^^^^^ this is an associated function, not a method </del> <ins> |     --^^^^^^-- |     | | |     | this is an associated function, not a method |     help: disambiguate the method call for the candidate: `ManyImplTrait::is_str(t)` </ins> | = note: found the following associated functions; to be used as methods, functions must have a `self` parameter note: the candidate is defined in the trait `ManyImplTrait`

Discussion:
Given the following test and nightly 2020-01-12: I get that this is not supposed to work without const generics, but the error message suggestion is very funny: With const generics:
Weird suggestion is on current stable as well.
The ICE component is fixed by , the diagnostics issue remains ()
I think it's another example of now.
Change:
$$(TLIB$(1)_T_$(4)_H_$(3))/$(CFG_STDLIB_$(4))  $$(HLIB$(2)_H_$(4))/$(CFG_CORELIB_$(4))  $$(HLIB$(2)_H_$(4))/$(CFG_RUNTIME_$(4))  <del> | $$(HBIN$(2)_H_$(4))/ </del> <ins> | $$(HLIB$(2)_H_$(4))/ </ins> @$$(call E, cp: $$@) $$(Q)cp $$< $$@ $$(Q)cp -R $$(TLIB$(1)_T_$(4)_H_$(3))/$(STDLIB_GLOB_$(4)) 

Discussion:
There comes a time in the life of every Rust developer when they have to blow away various parts of the directory to avoid messages about "multiple matching crates". Then when they do the next build they get things like: . It would be better if the Makefile would just create all the needed parent directories automatically.
+1
I'm pretty sure I know how to do this. (I think the right tools for the job are some in and )
I haven't actually waited for a whole build to go through yet, and I have to leave for the evening. But I'd welcome it if you would be willing to pull this (SHA: ) into your repo and give it a spin. If you don't get around to it, no sweat; it can obviously wait until Monday.
argh ignore comment above; the commit isn't anywhere near fully baked yet; somethings off with my make syntax.
Okay. It would be nice to do this in the interim, but eventually when rustpkg is the build system it will do this (much more easily than with Makefile hacking), so no sweat if you don't get it done :-)
Change:
<ins> // Copyright 2012 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. enum color { red = 1u, blue = 2, } fn main() {} </ins>

Discussion:
Currently, the following fails to compile, with errors about expecting int instead of uint: Is there any reason why this should be disallowed?
Linking to issue
Fixed by