jiebi/CodeConvo huggingface dataset:
Change:
a.srclink, a#toggle-all-docs, a.anchor, <del> .section-header a, </del> <ins> .small-section-header a, </ins> #source-sidebar a, pre.rust a, .sidebar a,

Discussion:
They used to be blue and are now black. I don't think this change was intentional, although we have been thinking about migrating more headers to be black recently. I think this regressed very recently, since I probably would have noticed it otherwise. !
I wonder if this was caused by or ? Those were both merged recently, though the second one doesn't seem like it could have changed colors. cc
This regressed in , which as one of the rules for an anchor to be styled black. The goal with that change was to make the section headings on module pages black (e.g. ). Those have . However, headings generated from Markdown in a docblock also have . I think the right short-term fix is: Section headings on module pages get , like their peers on other pages. Remove the CSS rule for to be black. It's not really clear to me why Markdown gets , and Rustdoc-generated headings get , particularly given that the Rustdoc headings are almost always bigger. Probably we should rename these to and .
Since you figured out a way to fix this regression, do you want to assign yourself and open a PR with the fix?
Will do.
Change:
$$(TBIN$(1)_T_$(2)_H_$(3))/rustc$$(X_$(3)):			 $$(DRIVER_CRATE)				 $$(TLIB$(1)_T_$(2)_H_$(3))/$(CFG_LIBRUSTC_$(3))  <del> | $$(TLIB$(1)_T_$(2)_H_$(3))/ </del> <ins> | $$(TBIN$(1)_T_$(2)_H_$(3))/ </ins> @$$(call E, compile_and_link: $$@) $$(STAGE$(1)_T_$(2)_H_$(3)) --cfg rustc -o $$@ $$< ifdef CFG_ENABLE_PAX_FLAGS

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:
<del> warning: non-binding let on a type that implements `Drop` </del> <ins> warning: non-binding let on a type that has a destructor </ins> --> $DIR/let_underscore_drop.rs:13:5 | LL |     let _ = NontrivialDrop;

Discussion:
I tried this code: I got this warning: However, there is no impl on the type, so the error message is misleading. It is true however that there is a destructor, as defined here: That being said, it's insiginificant for all underlying types (only destructor of and type in the ), so ideally the warning still wouldn't even show. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Well, even if the parameter of is , it still has a side-effect (deallocates memory). I don't think we need this special-casing. I do think the diagnostic is a bit misleading and should just say "has a destructor" or "has side-effects when dropped". Is there a more practical code example for why you'd want to suppress this error? The example you gave is a bit artificial, so it's a hard to motivate why we'd want to suppress this code since it really could be rewritten to be clearer.
claim
Change:
<ins> //! Previously, we tried to remove extra arg commas when providing extra arg removal suggestions. //! One of the edge cases is having to account for an arg that has a closing delimiter `)` //! following it. However, the previous suggestion code assumed that the delimiter is in fact //! exactly the 1-byte `)` character. This assumption was proven incorrect, because we recover //! from Unicode-confusable delimiters in the parser, which means that the ending delimiter could be //! a multi-byte codepoint that looks *like* a `)`. Subtracing 1 byte could land us in the middle of //! a codepoint, triggering a codepoint boundary assertion. //! //! issue: rust-lang/rust#128717 fn main() { // The following example has been modified from #128717 to remove irrelevant Unicode as they do // not otherwise partake in the right delimiter calculation causing the codepoint boundary // assertion. main(rahh）; //~^ ERROR unknown start of token //~| ERROR this function takes 0 arguments but 1 argument was supplied //~| ERROR cannot find value `rahh` in this scope } </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' File: --snippet: 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: 536 | Err(#[stable(feature = "rust1", since = "1.0.0")] E), [typeck] type-checking [analysis] running analysis passes on this crate --
Probably one of those cases... We should almost have an internal deny lint that bans explicit manipulations for suggestions. Possibly
Strongly agree. It's so easy to find these kinds of ICEs: simply needs to look for inside , out which ASCII character is meant to one's favorite Unicode table website that can list Confusables a Confusable whose is 1 and :boom:
For example, here's another one which I organically found while reviewing an unrelated PR: This code uses a Medium Right Parenthesis Ornament (U+2769) which is confusable with Right Parenthesis
I'll open an issue for the internal lint.
Change:
<ins> error: `$x:pat` is followed by `|`, which is not allowed for `pat` fragments --> $DIR/macro-pat-pattern-followed-by-or-in-2021.rs:3:28 | LL | macro_rules! foo { ($x:pat | $y:pat) => {} } |                            ^ not allowed after `pat` fragments | = note: allowed there are: `=>`, `,`, `=`, `if` or `in` error: `$x:pat` is followed by `|`, which is not allowed for `pat` fragments --> $DIR/macro-pat-pattern-followed-by-or-in-2021.rs:4:32 | LL | macro_rules! bar { ($($x:pat)+ | $($y:pat)+) => {} } |                                ^ not allowed after `pat` fragments | = note: allowed there are: `=>`, `,`, `=`, `if` or `in` error: `$pat:pat` may be followed by `|`, which is not allowed for `pat` fragments --> $DIR/macro-pat-pattern-followed-by-or-in-2021.rs:7:36 | LL |     ( $expr:expr , $( $( $pat:pat )|+ => $expr_arm:expr ),+ ) => { |                                    ^ not allowed after `pat` fragments | = note: allowed there are: `=>`, `,`, `=`, `if` or `in` error: aborting due to 3 previous errors </ins>

Discussion:
In Edition 2021, the following should error: for the same reason that the following already errors: cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I was wondering if you were interested in fixing this as a follow-up to -- I don't think you included it in that PR, right?
claim
I think the problem is here: , but if we allow , then will also be allowed. This does not seem right. But in the current function we can't yet tell what token comes next in . Do you have any suggestions?
Actually, the code may already be correct? It appears that is not allowed for , which is the goal: Maybe we just need a test -- or maybe there already is one!
Yes this part of the logic I have , but my question is about . I will add an additional test for pat2021.
I expect to be an error -- it is, right?
Yes. I see what you mean. I misunderstood your description in the issue.
Change:
self.report_conflict(target, ns, &directive.import(binding, None), old_binding); } } <del> module_.decrement_outstanding_references_for(target, ns, directive.is_public); </del> <ins> module_.update_resolution(target, ns, |resolution| { resolution.decrement_outstanding_references(directive.is_public); }) </ins> } match (&value_result, &type_result) {

Discussion:
Unfortunately, I can't reproduce this at a smaller scale. This issue occurs with as of commit . Rust version is Currently the tests (run from the directory with ) pass. However, applying the following patch: causes the following compiler error: which is claiming that an import conflicts with itself. I have pushed up the branch with that change applied for easy reproduction. Again, I'm sorry that I cannot provide a report on a smaller scale, but this appears to be some edge case blowing up. I have no clue why adding a module with a few imports and nothing else would be causing this issue.
Bisecting to find the nightly which caused this
I can confirm that this issue does not occur on . Unfortunately, there was a bug that prevented us from compiling on that wasn't fixed until , so I cannot provide anything more specific than that.
cc
Thanks for the report! This bug was introduced in . I diagnosed the issue and will fix it ASAP.
Change:
<ins> error[E0271]: type mismatch resolving `[u8; 3] <: <Range<usize> as SliceIndex<[u8]>>::Output` --> $DIR/slice-match-byte-lit.rs:6:9 | LL |     match &s[0..3] { |           -------- this expression has type `&<std::ops::Range<usize> as SliceIndex<[u8]>>::Output` LL |         b"uwu" => {} |         ^^^^^^ types differ error: aborting due to previous error For more information about this error, try `rustc --explain E0271`. </ins>

Discussion:
This code previously compiled fine, but as of ~2 weeks ago it began to fail on nightly and has continued to do so since. p.s. Is the output of suppose to be one day behind compared to the toolchain name? In any case, was the last working version, and onward trigger the error. modify labels: +regression-from-stable-to-nightly -regression-untriaged
cc
I can put up a fix for this. I suspected this might cause an issue but couldn't think how.
Change:
mod caches; pub use self::caches::{ <del> CacheSelector, DefaultCacheSelector, QueryCache, SingleCacheSelector, VecCacheSelector, </del> <ins> CacheSelector, DefIdCacheSelector, DefaultCacheSelector, QueryCache, SingleCacheSelector, VecCacheSelector, </ins> }; mod config;

Discussion:
Per-crate cache maps keyed on may be more efficient and/or allow us to use for queries keyed on instead of . We can use specialization (e.g. for splitting into and ), I think. cc
Sounds like a good idea if the lookup array ends up being densely populated enough. In general, we should provide a way to implement customized in-memory caching for specific queries.
Change:
<ins> trait Foo { fn foo([a, b]: [i32; 2]) {} //~^ ERROR: patterns aren't allowed in methods without bodies } fn main() {} </ins>

Discussion:
Using a generic function to "converge" two into when T is an associated type for another trait causes the following error: Example code (): This may or may not be related to the compiler seemingly failing to assert that , an error that can be triggered by using the alternate signature for at line 40 of the example. I tested this with the linked playground on the latest stable (1.32.0), as well as a recent nightly: Compiling with doesn't seem to yield a very useful stack but here it is:
Another example by that causes only the second "call dest mismatch" ICE:
P-medium. Removing nomination label. (But maybe we should have a WG-impl-trait to provide a structured effort for working through the bugs with impl trait?)
This has been fixed in 1.38.0 as, while I can reproduce the ICE in 1.37.0, I am not observing it in neither of: stable (1.38.0), beta nor nightly. modify labels: E-needstest

The following code works on beta: But when used in a trait like so: rustc reports the following error:
Possibly related to rustc expecting possibly a type in this scenario? As you can declare trait methods with no parameter name
Possibly related to rustc expecting possibly a type in this scenario? Exactly. When becomes an error, we'll be able to accept arbitrary patterns in parameters of trait methods, but for now only very limited subset is allowed.
The example in the issue now compiles. If we don't have existing tests for this, we ought to add one.
Change:
ProjectionElem, Rvalue, Statement, StatementKind, Terminator, TerminatorKind, VarBindingForm, }; use rustc_middle::ty::{self, suggest_constraining_type_param, Ty}; <del> use rustc_mir_dataflow::drop_flag_effects; use rustc_mir_dataflow::move_paths::{MoveOutIndex, MovePathIndex}; </del> <ins> use rustc_mir_dataflow::move_paths::{InitKind, MoveOutIndex, MovePathIndex}; </ins> use rustc_span::source_map::DesugaringKind; use rustc_span::symbol::sym; use rustc_span::{BytePos, MultiSpan, Span, DUMMY_SP};

Discussion:
Forgetting to initialize a non-Copy variable in a loop and then referring to it gives a 'borrowed after move' error, instead of a 'possibly-uninitialized variable' error: Using a type like does result in the right error: Tested with 1.43.0 (stable) and 1.45.0-nightly.
In both Ada and D languages (in different ways, in Ada it's more refined) there's a way to tell the type system that the input variable to that bla function is not initialized and that bla must initialize it, and inside bla you can't read it before it's initialized. This means you have a way to propagate the not initialized state in function arguments, and safety is preserved. In practice this is not a big problem for Rust because in Rust you can return tuples and now Rustc is getting logic to optimize this usage pattern.
Uh, this issue is just about the error message. That this code gives an error is fine.
I'd be interested in fixing this myself, but I'm not sure where to start.
This is an issue for a command line program I'm writing. At the beginning of a function, I declare some uninitialized variables, and then I have a loop for each one. In this loop, it will read user input, and if it is valid, assign the variable that value. The loop will never complete without the variable being initialized, but rustc refuses to compile because it thinks the variable could be uninitialized after the loop.
That sounds like a different issue. This issue is about a confusing error message. The example is supposed to not compile. If the compiler rejects correct code, that's another issue.
To add context, I find this example illustrates the problem more clearly for me: the same code with the same types, just outside a loop context:
Change:
// we must mirror everything that `visit::walk_fn` below does. self.visit_fn_header(&sig.header); visit::walk_fn_decl(self, &sig.decl); <del> if let Some(body) = body { let closure_def = self.create_def(closure_id, DefPathData::ClosureExpr, span); self.with_parent(closure_def, |this| this.visit_block(body)); } </del> <ins> let closure_def = self.create_def(closure_id, DefPathData::ClosureExpr, span); self.with_parent(closure_def, |this| walk_list!(this, visit_block, body)); </ins> return; } }

Discussion:
I'm seeing an internal compiler error on the following input (found by ):
Report from cargo-bisect-rustc: searched nightlies: from nightly-2020-03-09 to nightly-2020-04-03 regressed nightly: nightly-2020-03-16 searched commits: from to regressed commit:
Maybe due to cc
Fixed by
Change:
debug_assert_eq!(result, 0); } } <ins> struct PthreadMutexAttr<'a>(&'a mut MaybeUninit<libc::pthread_mutexattr_t>); impl Drop for PthreadMutexAttr<'_> { fn drop(&mut self) { unsafe { let result = libc::pthread_mutexattr_destroy(self.0.as_mut_ptr()); debug_assert_eq!(result, 0); } } } </ins>

Discussion:
In libstd/sys/unix there are numerous cases where return code is checked for error using following pattern: That means, that error checking is performed only when compiled in non-optimized mode or after explicitly enabling debug assertions. This is a little bit worrying, especially when used on platforms where those functions can indeed fail and break safety.
(For anyone who was confused by the given example, pthreadmutexattrinit can fail with ENOMEM.)
On some platforms types like pthreadmutext, pthreadcondt, etc., are "fat" structures that have sufficient size to hold everything necessary and their initialization will never fail (unless initialized incorrectly). But on others they are opaque pointers to and require an additional memory allocation. Search for those typedefs in libc crate, gives a rough approximation of affected platforms. Sadly this also affects static mutexes, so even lock / unlock could potentially fail. Either way you could end up with a mutex which is not mutually exclusive at all.
When mutex initialization fails this leads to non-functioning mutex and unsoundness. The pthreadmutexlock might also fail for recursive mutexes used in std::io and cause a mismatch in the number of locks / unlocks, but one needs to go out of the way to cause that. modify labels: C-bug I-unsound
Change:
item, &diag_info, )?; <del> let id = clean::register_res(self.cx, rustc_hir::def::Res::Def(kind, id)); </del> <ins> let page_id = clean::register_res(self.cx, rustc_hir::def::Res::Def(kind, id)); </ins> Some(ItemLink { link: ori_link.link.clone(), link_text: link_text.clone(), <del> did: id, </del> <ins> page_id, </ins> fragment, }) }

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. --field contains wrong IDs for some kind of items. Items for which no independent HTML is generated (link target URL is ) appear to have incorrect IDs. I tried this code: I expected to see this happen: contains the IDs of link targets Instead, this happened: contains the ID of the items containing the link targets <!-- 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 --
modify labels: +A-rustdoc-json +T-rustdoc +A-intra-doc-links
claim
Change:
use rustc_middle::mir::*; use rustc_middle::ty::{self, Ty}; use rustc_mir_dataflow::move_paths::{LookupResult, MovePathIndex}; <del> use rustc_span::{BytePos, Span}; </del> <ins> use rustc_span::{BytePos, ExpnKind, MacroKind, Span}; </ins> use crate::diagnostics::CapturedMessageOpt; use crate::diagnostics::{DescribePlaceOpt, UseSpans};

Discussion:
The following code causes a compilation error. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is intended, it is an attempt to make derives and work in more cases. The derive cannot know whether the field is copy. It cannot take a reference to the field, since it's not aligned. So it tries to copy, which at least works for types.
Should, or can this be fixed?
It cannot. repr(packed) sucks.
Atleast, we should modify the error message to make it clearer? Something like error[E0507]: cannot move out of which is behind a shared reference -- | 3 | #[derive(Debug)] | ----- in this derive macro expansion 4 | struct B(String); | ^^^^^^ move occurs because has type , which does not implement the trait | = note: this error originates in the derive macro (in Nightly builds, run with -Z macro-backtrace for more info) = note: this struct is marked as , but unaligned field references are undefined behaviour. For more information about this error, try .
that's possible.
claim
I'll let others implement the diagnostic message.
Change:
<ins> // This test checks that comparison operation // generated by #[derive(PartialOrd)] // doesn't contain jumps for C enums // compile-flags: -Copt-level=3 #![crate_type="lib"] #[repr(u32)] #[derive(Copy, Clone, Eq, PartialEq, PartialOrd)] pub enum Foo { Zero, One, Two, } #[no_mangle] pub fn compare_less(a: Foo, b: Foo)->bool{ // CHECK-NOT: br {{.*}} a < b } #[no_mangle] pub fn compare_le(a: Foo, b: Foo)->bool{ // CHECK-NOT: br {{.*}} a <= b } #[no_mangle] pub fn compare_ge(a: Foo, b: Foo)->bool{ // CHECK-NOT: br {{.*}} a >= b } #[no_mangle] pub fn compare_greater(a: Foo, b: Foo)->bool{ // CHECK-NOT: br {{.*}} a > b } </ins>

Discussion:
The manual version: The manual version ASM: The derived version: The derived version ASM: The diff is that while the manual version does: derived version does: All the other operators are optimized properly.
LLVM can't properly optimize the match against Some(Less Some(Greater) and negate the result, LLVM does find a way to optimize the code, because the IR we generate is somewhat simpler having to handle only one of the Some() cases. I didn't really look into how to maybe teach LLVM to handle this case, and didn't see anything obvious in the way we generate IR that could be improved here either. Should I prepare a PR to adjust the default impl of with a comment that explains why it's written that way, or should we investigate more here?
I wonder if this issue is related to
We could test it in next nightly.
Well, this issue doesn't fixed by it (which is expected because we changed MIR of && and , not match) so we need to make changes in LLVM or change our generated code.
Created PR with fix.
Upstream fix for LLVM: