jiebi/CodeConvo huggingface dataset:
Change:
let guard_start = self.add_dummy_node(&[pat_exit]); // Visit the guard expression let guard_exit = match guard { <del> hir::Guard::If(ref e) => self.expr(e, guard_start), </del> <ins> hir::Guard::If(ref e) => (&**e, self.expr(e, guard_start)), </ins> }; // #47295: We used to have very special case code // here for when a pair of arms are both formed

Discussion:
ICE with the borrow checker on nightly. Tried on stable/beta and it correctly errors with in nightly, I get : Backtrace:
Reduced: cc
Bisected this one to and , that is, PR . cc
Change:
} TerminatorKind::Yield { ref value, resume_arg: ref place, .. } => { <ins> self.gather_operand(value); </ins> self.create_move_path(place); self.gather_init(place.as_ref(), InitKind::Deep); <del> self.gather_operand(value); </del> } TerminatorKind::Drop { ref location, target: _, unwind: _ } => {

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:
of stdout", "PATH"), getopts::optflag("", "nocapture", "don't capture stdout/stderr of each  task, allow printing directly"), <ins> getopts::optopt("", "test-threads", "Number of threads used for running tests  in parallel", "n_threads"), </ins> getopts::optflag("q", "quiet", "Display one character per test instead of one line"), getopts::optopt("", "color", "Configure coloring of output: auto   = colorize if stdout is a tty and tests are run on serially (default);

Discussion:
Discussion carried over from: rust-lang/cargo Test binaries created by rustc should have a option instead of (in addition to?) controlling the thread count with . It's not a consistent user experience to have some functionality controlled via environment variables and some via command line options. CLI options should be preferred since they encourage users to keep configuration local to a single execution of a test binary and not export it globally, making it affect other test runs perhaps accidentally. It would also make the output of more uniform and compact.
Agreed.
The ability to specify this in the somehow might be nice. One of my crates I'm working on needs all the tests run like this.
It is already set table by an env var, no? Cargo just can't specify them. So still not ideal but might work in the meantime. On Apr 16, 2016, 19:05 -0400, Nathan , wrote:
Oh cool thanks, I'll set that in my project.
Change:
} #[instrument(skip(self), level = "debug")] <del> fn self_type_matches_expected_vid( &self, trait_ref: ty::PolyTraitRef<'tcx>, expected_vid: ty::TyVid, ) -> bool { let self_ty = self.shallow_resolve(trait_ref.skip_binder().self_ty()); </del> <ins> fn self_type_matches_expected_vid(&self, self_ty: Ty<'tcx>, expected_vid: ty::TyVid) -> bool { let self_ty = self.shallow_resolve(self_ty); </ins> debug!(?self_ty); match *self_ty.kind() {

Discussion:
Repro: Output:
cc
What's causing this is that we currently inspect the obligations in scope for obligations, but in this case the obligation is (which implies a obligation as a supertrait). This is expected but unfortunate, yes. We could probably fix this particular case in a relatively straightforward way by trying to upcast each pending obligation to a obligation.
I imagine that atm this could be worked around by changing: to
Today, this gives a completely different error about not implementing ...
Updated code to not give the unrelated error (by removing bounds everywhere), still gives the type must be known error.
This comes up for me fairly regularly. It would be really nice to fix it. (e.g., it came up recently in )
We discussed this in the types team 'backlog bonanza' meeting today. Our conclusion was that this is a "nice to have" and that directly fixing this issue felt like a types team FCP, because it's a tweak to the inference rules. TL;DR right now we say If there is some trait obligation , then we take the args from it seems reasonable to say If there is some trait obligation that implies (through the "invariants", in terms) , then we take the args from that would fix this example (types team FCP would be required). However, I believe that beyond this specific example, most people who wind up here are trying to do something a bit more sophisticated, such as having an argument that might be a closure but might not, or have extended varieties of closures (). It is possible that just making the above change would fix those problems, but it's likely that further changes would be required. Those scope feels like a lang-team initiative. Still may be worth making this change just to screen out the easy cases, mind you!
Change:
CTEST_MODE_codegen = codegen CTEST_RUNTOOL_codegen = $(CTEST_RUNTOOL) <ins> # CTEST_DISABLE_$(TEST_GROUP), if set, will cause the test group to be # disabled and the associated message to be printed as a warning # during attempts to run those tests. </ins> ifeq ($(CFG_GDB),) CTEST_DISABLE_debuginfo = "no gdb found" endif

Discussion:
Original title: "compiletest has implicit dependency on libnative" compiletest has implicit dependency on libnative When I tried to do , I get the following: says this is because, despite 's continued use of , there is an implicit attempt to link in unless one puts in a attribute into the crate attributes. I plan to try to fix this pronto. After fixing the above, I get: So there's another separate problem blocking from working.
Still working on this, there was a new problem that came up (run-pass-fulldeps needs libsyntax to have been rebuilt), so I've updated the description and the title to reflect the more general issue here.
Change:
#[derive(Subdiagnostic)] pub enum UnusedVariableSugg { <del> #[multipart_suggestion(passes_suggestion, applicability = "machine-applicable")] </del> <ins> #[multipart_suggestion(passes_suggestion, applicability = "maybe-incorrect")] </ins> TryPrefixSugg { #[suggestion_part(code = "_{name}")] spans: Vec<Span>,

Discussion:
For example: I don't like that refactor because I might end up with local variables that do nothing. I think should just ignore unused local variables all together. If just renames local variables to hide the warnings from the compiler, then the compiler lint is a bit pointless. Renaming unused function parameters seems fine.
To get a better understanding of your thought process, why do you feel should treat local variables and function parameters differently here?
For example Now at one point you remove , and then cargo fix will rename to Now you have you might never find this in your code base. You really wanted to remove it, or maybe it was a bug in the first place that you are not using it anymore. Just renaming it for the sake of removing the warning seems wrong. Maybe it should also not rename parameters for free standing functions. I think that there are some cases in functions were you just want to rely on type inference and then the parameter should always be , but I think that decision should come from the programmer. It seems reasonable to rename parameters for trait impls because you can't just change the function signature, and you might not always want to use the parameter.
I think I'm persuaded? Here's where the lint is issued: We just need to change to to tell not to auto-apply the suggestion. We have access to the HIR here, so setting the applicability conditionally based on whether it's a binding or a method argument should be doable, although potentially slightly tricky.
I think you are right, this is misleading in your use case. Just wondering: At which points in your workflow are you running cargo fix? I also think this is one of the cases where we need to differentiate between "cargo fix should fix it" and "get a lightbulb with auto-fix suggestions in your editor". Just because it might be auto-fixable doesn't mean we should automatically fix it. This is a discussion for a higher level issue, though.
I only ran once for a project where I had a few warnings after I did some refactoring.
Is anyone against changing this suggestion to simply be instead of ? Prepending an underscore to variable names is saying to the compiler "yes, I intentionally won't use this value", which should very much be a manual action. I'm hesitant to use , since it might silently hide a bunch of leftover variables from an in-process refactoring. I mostly want it to remove unnecessary parenthesis and fix my imports, this is overreaching a bit.
Change:
abi_return_struct_as_int: true, emit_debug_gdb_scripts: false, eh_frame_header: false, <ins> lld_flavor: LldFlavor::Ld64, </ins> // The historical default for macOS targets is to run `dsymutil` which // generates a packed version of debuginfo split from the main file.

Discussion:
has progressed to the point where there is now a flag for linux builds. On a lark, I tested what happens on macos. Surprisingly, it wasn't immediately rejected. Unsurprisingly, it exploded. I'm not 100% sure if macos and linux are similar enough environments that the same mechanism should just work, but I think it should? <details<summarybuild log </summary</details
Oh interesting, ok so with it's blowing up in build scripts, but it seems to build (something with no dependencies or build scripts) fine!
(I do not have a readily available linux env to test if this failure mode is uniquely macos or just the usual "build-scripts and plugins have weird interactions with compiler flags" problem)
Using gets farther on rust-minidump's , but still blows up at the final link: <details<summarybuild log </summary</details<details<summaryfailing cc invocation broken up into lines</summary</details
Maybe your lld is too old? I can build my workspace with:
There is one binary lld and various symbolic links with different names. You have to pass for OSX and for linux. You are probably passing the wrong flavour, i.e. gnu.
Change:
help: use `Box::new()` instead | LL |     let _ = Box::new(()); <del> |             ~~~~~~~~~~~~ </del> <ins> |             ~~~~~~~~~  + </ins> error: `box_syntax` has been removed --> $DIR/removed-syntax-box.rs:10:13

Discussion:
Found by grepping through the compiler via while reviewing an unrelated PR. File : File : : . or move source file . : . <details<summaryFull compiler output</summary</details:
Solution: Get rid of altogether and use a multi-part suggestion (, ).
Change:
} fn check_let(&mut self, pat: &'tcx hir::Pat<'tcx>, expr: &hir::Expr<'_>, span: Span) { <del> self.check_patterns(pat); </del> <ins> self.check_patterns(pat, Refutable); </ins> let mut cx = self.new_cx(expr.hir_id); let tpat = self.lower_pattern(&mut cx, pat, &mut false); check_let_reachability(&mut cx, pat.hir_id, tpat, span);

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: Ideally the lint should not trigger on such a pattern, it does not really make sense and the suggestion is wrong altogether,
label: +D-confusing +D-incorrect
Note that the suggestion isn't wrong in this particular case, because can actually match any Foo. It's wrong only when has 2+ variants.
Right, the real world case of this was with the ascii crate with the AsciiChar enum, this is just a tiny test case
Change:
warnings: self.warnings, suggest_unsafe_block: self.suggest_unsafe_block, }; <ins> // params in THIR may be unsafe, e.g. a union pattern. for param in &inner_thir.params { if let Some(param_pat) = param.pat.as_deref() { inner_visitor.visit_pat(param_pat); } } // Visit the body. </ins> inner_visitor.visit_expr(&inner_thir[expr]); // Unsafe blocks can be used in the inner body, make sure to take it into account self.safety_context = inner_visitor.safety_context;

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: . I expected to see this happen: rustc rejecting this code. We are transmuting arbitrary types without unsafe, this is clearly unsound. Instead, this happened: rustc accepted this code, and it SIGSEGVs at runtime. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Seems to have regressed between 1.76 and 1.77. In 1.76 (and below) it gave: It's probably related to the THIR unsafeck which in .
I'll take a look at this. I think I may have found out what's going on. claim
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Reopening for beta nomination.
Fix backported via
Change:
|                  ^ no rules expected this token in macro call error: unexpected end of macro invocation <del> --> $DIR/missing-comma.rs:25:23 </del> <ins> --> $DIR/missing-comma.rs:29:23 </ins> | LL | macro_rules! bar { | ---------------- when calling this macro

Discussion:
I don't know what to make of this error. () Errors: On stable (1.34) the output is
I'm pretty sure this is fallout from the "missing comma here" suggestion for macros, that evaluates the macro again with the current arguments but adding a comma token in between the argument tokens in different combinations to see if it would be correct. My guess is that that is causing a parse error that doesn't happen for normal things than only have one token in them. We can disable the suggestion when fully qualified paths are involved.
Change:
}; if res == unqualified_result { let lint = lint::builtin::UNUSED_QUALIFICATIONS; <del> self.r.lint_buffer.buffer_lint( </del> <ins> self.r.lint_buffer.buffer_lint_with_diagnostic( </ins> lint, finalize.node_id, finalize.path_span, "unnecessary qualification", <ins> lint::BuiltinLintDiagnostics::UnusedQualifications { path_span: finalize.path_span, unqualified_path: path.last().unwrap().ident } </ins> ) } }

Discussion:
In the middle of a large refactoring that was mostly automated by rust-analyzer's structural-search-and-replace, I had a lot of qualified paths that shouldn't be qualified. I made do with a regular text-based search-and-replace since I couldn't find a better way, but I think that better way could have been , because introducing an import for the relevant type once per file is much easier than replacing all uses manually. As such, it would be nice if the unnecessary qualification lint had a machine-applicable suggestion attached to it. However, one interesting thing about this is that I also had warnings about the import for that same type being unused. I don't know whether it would be possible with the current compiler infrastructure to create mutually-exclusive suggestions. Either way the suggestion would be helpful, since a simple could disable the automatic removal of the imports.
I second that should be applicable. To fix the violations I almost found and removed the qualified prefix one by one.
Mentoring instructions: Add a new .
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. // Test that we do not error out because of a (False) ambiguity // between the builtin rules for Sized and the where clause. Issue // #20959. fn foo<K>(x: Option<K>) where Option<K> : Sized { let _y = x; } fn main() { foo(Some(22)); } </ins>

Discussion:
The following program: dies with a false ambiguity report. The problem is that the builtin bound rules kick and identify that , but there is also a where-clause for that same thing. We should treat builtin-bounds expansions in the same was an explicit impl and resolve in favor of the where-clause.
Change:
message = "Some changes might have occurred in exhaustiveness checking" cc = ["@Nadrieril"] <ins> [mentions."library/core/src/intrinsics/simd.rs"] message = """ Some changes occurred to the platform-builtins intrinsics. Make sure the LLVM backend as well as portable-simd gets adapted for the changes. """ cc = ["@antoyo", "@GuillaumeGomez", "@bjorn3", "@calebzulawski", "@programmerjake"] </ins> [mentions."library/portable-simd"] message = """ Portable SIMD is developed in its own repository. If possible, consider 

Discussion:
will introduce this submodule. Any changes here need all codegen backends to implement them. And portable-simd likely wants to know about it. As such I propose adding a ping for any change to this file mentioning me, and
Change:
llvm_c_strs.push(s); }; add("rustc"); // fake program name <del> add("-arm-enable-ehabi"); add("-arm-enable-ehabi-descriptors"); </del> if vectorize_loop { add("-vectorize-loops"); } if vectorize_slp  { add("-vectorize-slp");   } if sess.time_llvm_passes() { add("-time-passes"); }

Discussion:
This code Will generate this IR under Yes, that is a of length 7. I have no idea why this is getting generated, I'm trying to narrow down which pass is generating this, but that is absolutely awful code to generate for such a simple operation. I would expect this function to generate two stores, one of the discriminant and one of the value. Now change the program to have in front of the enum, and we get this code:
cc
I would expect similar code generation with as well as with no annotation. Is this because we're attempting to zero-out the discriminant padding?
Look at the asm. This may actually not be so bad unless the is getting lowered to a true .
Here is the asm. It is not actually generating a call to :
the equivalent to no in this case would be , fwiw.
I agree that the assembly doesn't look that bad, but this is still completely unnecessary, no? I was looking at assembly with huge waterfalls of moving al/ax/eax/rax over and over again. I don't think this is a closed bug because this is a real problem. This may not be a high priority bug, but our assembly is certainly doing things that it doesn't need to do.
Is this ?
Aha, I see the problem: SROA happened, split up our struct into 3 elements, one of which is the padding, and stored the padding. The solution is to add , like . Closing again as a dupe.
It may be, but I don't know enough about LLVM's optimizations to know whether that would help or not.
It would be possible to make the type , and that might make the code seen here less bad, but I don't know if LLVM would be less able to optimize code that accesses the discriminant in that case. It would also be possible to make more complex and have it avoid filling in alignment padding for bytes where none of the variants have fields (so → , → ). We might need this information anyway for .
Patch has been submitted to LLVM upstream.
Change:
/// /// Using [`Acquire`] as success ordering makes the store part /// of this operation [`Relaxed`], and using [`Release`] makes the final successful load <del> /// [`Relaxed`]. The (failed) load ordering can only be [`SeqCst`], [`Acquire`] or [`Relaxed`] /// and must be equivalent to or weaker than the success ordering. </del> <ins> /// [`Relaxed`]. The (failed) load ordering can only be [`SeqCst`], [`Acquire`] or [`Relaxed`]. </ins> /// /// **Note**: This method is only available on platforms that support atomic operations on #[doc = concat!("[`", $s_int_type, "`].")]

Discussion:
Currently requires the failure ordering to "be equivalent to or weaker than a success ordering". On the other hand C11/C++11 requires only that "failure shall be no stronger than the success", which arguably means that one can write e.g. in C/C++ but not in Rust. Arguably, because neither C11 standard nor C++11 standard defines what it means for an ordering to be stronger from another. When the issue was raised in [LWG2445], the proposed and accepted resolution was to lift those restrictions altogether, leaving only requirement that "the failure argument shall not be nor ". It would be beneficial to remove success/failure ordering restrictions for reasons described in C++ proposal [P0418r2]. [LWG2445]: [P0418r2]: EDIT: Restrictions were lifted in clang & LLVM:
Blocked on The cmpxchg release acquire is accepted by LLVM but miscompiled on AArch64.
I'm about to send a PR that implements this.
I do have implementation ready as well, but that's fine, I can review instead :-).
I split it in a PR that renames the intrinsics first, and a separate PR for exposing the new ordering combinations afterwards.
Looks like llvm 12 doesn't support this: Can we make things conditionally fall back to a stronger ordering depending on the llvm version? I don't think we do anything like that in the library right now, but maybe the compiler already does things differently for different llvm versions?
Ah yes, some code checks . I suppose Builder::atomic_cmpxchg could check the same, and upgrade the ordering if necessary in that case.
Did exactly that in
To do: [x] Add codegen test. [x] Publicly expose the new orderings. [x] Update memory order lint to accept the new orderings.