jiebi/CodeConvo huggingface dataset:
Change:
<ins> // run-pass // aux-build:arc_wake.rs extern crate arc_wake; use std::future::Future; use std::pin::Pin; use std::sync::{ Arc, atomic::{self, AtomicUsize}, }; use std::task::{ Context, Poll, }; use arc_wake::ArcWake; struct Counter { wakes: AtomicUsize, } impl ArcWake for Counter { fn wake(self: Arc<Self>) { Self::wake_by_ref(&self) } fn wake_by_ref(arc_self: &Arc<Self>) { arc_self.wakes.fetch_add(1, atomic::Ordering::SeqCst); } } struct MyFuture; impl Future for MyFuture { type Output = (); fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output> { // Wake twice let waker = cx.waker(); waker.wake_by_ref(); waker.wake_by_ref(); Poll::Ready(()) } } fn test_waker() { let counter = Arc::new(Counter { wakes: AtomicUsize::new(0), }); let waker = ArcWake::into_waker(counter.clone()); assert_eq!(2, Arc::strong_count(&counter)); { let mut context = Context::from_waker(&waker); assert_eq!(Poll::Ready(()), Pin::new(&mut MyFuture).poll(&mut context)); assert_eq!(2, counter.wakes.load(atomic::Ordering::SeqCst)); } drop(waker); assert_eq!(1, Arc::strong_count(&counter)); } fn main() { test_waker(); } </ins>

Discussion:
E.g. in and cc
I'd like to work on this :smile:
You've got it :)
Change:
} } <del> /// Wrapping (modular) division. Computes `floor(self / other)`, </del> <ins> /// Wrapping (modular) division. Computes `self / other`, </ins> /// wrapping around at the boundary of the type. /// /// The only case where such wrapping can occur is when one

Discussion:
Using Google I can find lots of old arguments over how integer division should work in Rust, but I cannot find anything in the reference, the API docs for the integer types, or the API docs for the trait that says what was actually decided. (And the documentation seems to imply that , , and may not all do the same thing.) This is further confused by the integer type documentation apparently sometimes using to refer to integer division and sometimes to mathematical division. (I can't come up with out any other reasonable interpretation of in the documentation.) It would be nice if this were clearly documented somewhere, since this varies between languages and is one of the main confusions with integer arithmetic.
talks about 'overflow' and mentions wrapping, but you're right that we can surface this better.
This is about rounding, not wrapping. We use LLVM's , which rounds towards zero (and has the same sign as the dividend). We should document this (the documentation for currently lies_, claiming that it rounds towards negative infinite).
This should also leave a warning, because integer / integer is not always desired and happens by accident. Just a thought if anyone is reading this.
Change:
--> $DIR/no-patterns-in-args-2.rs:4:11 | LL |     fn f1(mut arg: u8); <del> |           ^^^^^^^ </del> <ins> |           ^^^^^^^ help: remove `mut` from the parameter: `arg` </ins> | note: the lint level is defined here --> $DIR/no-patterns-in-args-2.rs:1:9

Discussion:
Taken from We should suggest to use an identifier. When possible take that identifier from the pattern, otherwise should work just as well. CC
I'll try it!
Change:
LL |     let _x = 1/(1-1); |              ^^^^^^^ attempt to divide by zero <ins> warning: attempt to divide by zero --> $DIR/promoted_errors.rs:25:20 | LL |     println!("{}", 1/(false as u32)); |                    ^^^^^^^^^^^^^^^^ </ins> warning: this expression will panic at runtime --> $DIR/promoted_errors.rs:25:20 | LL |     println!("{}", 1/(false as u32)); |                    ^^^^^^^^^^^^^^^^ attempt to divide by zero <ins> warning: attempt to divide by zero --> $DIR/promoted_errors.rs:28:14 | LL |     let _x = 1/(false as u32); |              ^^^^^^^^^^^^^^^^ warning: this expression will panic at runtime --> $DIR/promoted_errors.rs:28:14 | LL |     let _x = 1/(false as u32); |              ^^^^^^^^^^^^^^^^ attempt to divide by zero </ins>

Discussion:
inlined inside a , I get a warning: however, when I involve a variable there is no warning at all but looking at the generated code it is quite clear that this panics:
It warns on current stable, but not on beta and nightly. Might be miri fallout? cc Curiously, when you take a reference (to trigger promotion to static) you get a hard error on beta and nightly (stable is still a warning). Isn't that a regression?
triage: P-medium Still want to get those warnings, but no longer P-high
Hm, what is the status of this? The PR was merged, but with , I don't get a compiler warning for the first example. For the second one I get two though? :confused:
The PR was just for the compilation error. The missing warnings just need an impl for this branch: The warning duplication is unfortunate, but if we deduplicate it, we loose warnings in other edge cases. We could deduplicate it similar to the way the notes about where the lint level was set are deduplicated (note how the second warning has no message). That would probably be the cleanest solution.
Change:
<ins> trait Foo {} impl<'a, T> Foo for &'a T {} struct Ctx<'a>(&'a ()) where &'a (): Foo, //~ ERROR: type annotations needed &'static (): Foo; fn main() {} </ins>

Discussion:
Given this Rust code: A call to generates IR like this on x86_64 Linux: So we have a 12 byte alloca from which we then read 16 bytes.
Isn't this subject to alignment by LLVM?
what do you mean? The alloca is only 12 bytes large. That's also the amount of bytes we write in the , but then we ask to read data for a type that is 16 bytes large. I don't see how alignment is relevant here.
here's a demo: Build without optimizations on x86_64 Linux, and you should be able to observe in the C code, although it hasn't been passed as an argument. The mismatch in the struct type definitions is deliberate to show the problem.
Reading past the end of an alloca has well-defined behavior in LLVM IR. I guess we might end up with false positives if we ever support msan.
are you implying that the generated IR is fine? If so, what is the defined behaviour / where can I read up on that? reads as if it is undefined. Without optimizations, this gives random output: With optimizations, SROA ignores the out-of-bounds read and emits a warning in debug mode, which doesn't seem like it is well-defined behaviour to me either.
Basically, if a pointer points to valid memory, and is sufficiently aligned, you can load bytes up to the alignment... LLVM itself does this at etc. That said, looking a bit more closely, the given testcase performs an "align 8" load from an "align 4" pointer, which is more problematic.
Thanks! That looks like it just assumes that the load won't trap. Part of my concern here is that we might expose additional data this way, like observing in that C code example. Though I guess optimizations might eventually leave the upper 32bits undefined and expose data anyway, so this might be moot. The alignment problem is probably due to bad usage of . Ultimately, we should load and pass the struct elements individually anyway.
This has been fixed, we now only load 12 bytes: instead of . Marking as E-needstest.
Change:
relative_from: Some("") ); <ins> tc!("foo/.//bar", "foo/bar", eq: true, starts_with: true, ends_with: true, relative_from: Some("") ); tc!("foo//./bar", "foo/bar", eq: true, starts_with: true, ends_with: true, relative_from: Some("") ); </ins> tc!("foo/bar", "foo", eq: false, starts_with: true,

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 : I expected to see this happen: Different hashes since these represent different paths. Instead, this happened: The hashes are equal. This makes sense for redundant path separators (e.g. ), but not for all path separators. I a test case to the standard library — which fails. The relevant code is probably around which last changed in If I revert that commit, the error persists. It looks like the relevant change is , if I revert that commit the test passes. This was the solution I opted for downstream (in ) before performing this investigation. I tested this on stable (1.79.0), nightly (1.81.0), and on (). Discovered via
is not a cryptographic hash, so it does not promise a collision probability so low that practically all inputs map to distinct outputs. So if the correctness of your program relies on the absence of collisions then it's your program that's wrong, not . There may be some quality-of-implementation argument about avoiding collisions for data patterns that are likely to coexist. I'm not sure if it is the case here, I'll have to think about it. And even if it is then there also is the matter of making such a avoidance fast. The current code is optimized for speed.
I think that's a fair point, but the current implementation already goes out if its way to create equal hashes for paths like and — why is and different? It seems like a very surprising collision for a user to encounter. Thanks for taking a look!
The difference is that is a companion for . If things compare equal then they must hash the same because that's what hashmaps rely on. and do compare equally because normalizes the dot away. Therefore they must hash equally, which is why Hash must spend effort on that. Things comparing inequal does not require the Hash to be different. Instead it's only a matter of quality-of-implementation whether they produce distinct hashes, not a matter of correctness.
That's a great point, thanks for clarifying. I agree this is not a "correctness" problem, but more of a practical consideration for the hashing algorithm.
Change:
<ins> error[E0425]: cannot find value `x` in this scope --> $DIR/silenced-binding-typo.rs:4:14 | LL |     let _y = x; |              ^ | help: a local variable with a similar name exists, consider changing it | LL |     let x = 42; |         ~ error: aborting due to previous error For more information about this error, try `rustc --explain E0425`. </ins>

Discussion:
Variables can be marked as unused by prepending with an underscore. If at some point such a variable is used again, the compiler suggests to name the use , even though every single time I have encountered this, what I wanted is to change the definition of to . () Errors:
I feel we should have a counterpart to the unused lint that checks for variables that are used but use the unused bar convention. That wouldn't be useful for the case presented here where you're using an unused bar for the first time, but seems like a reasonable addition.
Such a lint is problematic within macros or other compiler-expanded code, since it's a common pattern to work around not knowing if there are any uses by naming the variables appropriately (for an example look at the loop lowering code)
I agree but I'm pretty sure that most lints should ignore code with spans in macro context already.
Hi, I'd like to work on this!
sorry for not responding earlier. I only have very broad instructions right now, but don't hesitate to ask here or on the stream on zulip if you need more help. the place where the diagnostic "a local variable with a similar name exists" is emitted note that the "local variable" part may be a placeholder and the rest of the string might be broken across multiple lines if that place has more info than just the name of the local variable not, add a to whatever datastructure holds the name I'm not sure how the name is obtained right now, but there should be a way to get at the there, too. E.g. if the name is an , then it has a field. emitting the "similar name" diagnostic, first check whether the suggested name starts with an underscore, but the name used in the code does not that chek fails, keep the old message , emit the suggestion not on the span that it is currently emitted on, but on the definition span (and change the suggestion to remove the underscore)
Hi I've already done most of that :) I think I'll have a working PR next week.
I can work on this if you guys are caught up with something else :)
sure. Just once you start working on it. Maybe you can even get the WIP branch from fork
Change:
let (keys_size, keys_align) = (capacity * mem::size_of::<K>(), mem::align_of::<K>()); let (vals_size, vals_align) = (capacity * mem::size_of::<V>(), mem::align_of::<V>()); let (edges_size, edges_align) = if is_leaf { <del> (0, 1) </del> <ins> // allocate one edge to ensure that we don't pass size 0 to `heap::allocate` if mem::size_of::<K>() == 0 && mem::size_of::<V>() == 0 { (1, mem::align_of::<Node<K, V>>()) } else { (0, 1) } </ins> } else { ((capacity + 1) * mem::size_of::<Node<K, V>>(), mem::align_of::<Node<K, V>>()) };

Discussion:
Output:
The expansion of this is: Note that does not cause this problem.
Note also that this is only the case with jemalloc. The following runs successfully:
Actually, this is just related to calling jemalloc with 0 for the size:
We should probably apply a temporary fix for this (and audit all other uses of ), though will remove the direct allocation calls.
triage: I-nominated Seems pretty serious and something we may want to fix soon!
cc
I have a potential PR in progress, just running tests locally.
Change:
<ins> fn main() { 0.....{loop{}1}; //~^ ERROR unexpected token //~| ERROR mismatched types } </ins>

Discussion:
I'm seeing an internal compiler error on the following input, found by : The ICE happens after reporting some other errors, so I guess low priority. Affected versions: nightly 2022-04-22 does show the ICE, but beta 1.61.0-beta.3 does not show the ICE. <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2022-04-01 to nightly-2022-04-22 regressed nightly: nightly-2022-04-17 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
A invocation should be replaced by and producing an error type as the adjustment result
I think this is still open and it looks like a fun problem to dig into. Please let me know if I should let someone else work on it though please! claim
I also found this issue in that version's nightly rustc. I consider that is a nontrival problem worth digging into.
I have opened a PR () that I believe addresses the ICE. I think I pretty much implemented what Oli described, but I'm a little unclear as to whether this is the actual solution or is the fact that there's an adjustment on a never type at all the real bug? I also wasn't able to reduce the minimal error case much beyond what Badel2 posted. Do you happen to have a simpler error case, Peter?
I'm assigned to your PR, and looked into this issue really quickly. So this is due to the new argument type compatibility algorithm implemented in (cc: The after  has been called once before during the "good" path of . This is somewhat problematic, since this means that typeck code deeper in the stack attemps to apply adjustments twice and sometimes panicks because of this. A similar bug was fixed in when other diagnostic code called several times on a bad path.

Since this will only reasonably happen during diagnostic code, I think it's fine for now to delay a bug.
Thank you for the background! That helps a lot to clarify things. I clearly need to do a lot more reading.
Yeah, I also just have a simple ICE from rustc. But there has been some expositions from , so I think maybe this issue would be solved in the future.
Change:
#![feature(crate_visibility_modifier)] #![feature(derive_default_enum)] <ins> #![feature(if_let_guard)] </ins> #![feature(let_chains)] #![feature(let_else)] #![feature(min_specialization)]

Discussion:
As of , some of our code utilizing macros in [] started to fail to compile. The code that is failing is some macro magic for making nice pin name aliases for microcontrollers, so it's not surprising that broke it. I see that some other repos were broken as well and that helped fix it, but I'm really not sure how to do the fix in our repo. To reproduce: clone the [] repo I expect this to compile properly like on stable, instead it fails to compile with: It most recently worked on: Regressed to with () : modify labels: +regression-from-stable-to-nightly -regression-untriaged []:
Fixed in
Thanks for the quick fix!
Change:
tcx.layout_raw(param_env.and(normalized))? } <del> ty::Bound(..) | ty::Placeholder(..) | ty::GeneratorWitness(..) | ty::Infer(_) => { </del> <ins> ty::Placeholder(..) | ty::GeneratorWitness(..) | ty::Infer(_) => { </ins> bug!("Layout::compute: unexpected type `{}`", ty) } <del> ty::Param(_) | ty::Error(_) => { </del> <ins> ty::Bound(..) | ty::Param(_) | ty::Error(_) => { </ins> return Err(LayoutError::Unknown(ty)); } })

Discussion:
I got a little excited with merged, soooo I gave it a try, and I found this rather funny ICE. Notice how I call , without a type parameter, while the function expects a type parameter. <!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
yeah, that ICE is interesting :thinking: and why is it only triggered with ? claim

() Errors: Probably related: Removing (at least) one of the s for makes the panic go away, and the compiler correctly reports the error: modify labels: I-ICE, T-compiler, A-const-eval, A-const-generics, C-bug, F-const_generics, requires-nightly
That's happening here: I don#t think there is a meaningful way to evaluate a polymorphic constant, so either some code earlier screwed up to even get so far, or we need to throw here. Cc
cc This ICE is totally expected. Using features that emit the lint are expected to ICE, otherwise they would not emit said lint. The const evaluator is not at fault here, there's just no way to evaluate this.
hmm, we shouldn't try to evaluate this constant here or at least have it be a instead of a . Not quite sure what's going on here, will have to look at it in more detail soon
So we probably fail here because we call with a which get's canonicalized to a . All of that seems correct to me :thinking: Is it possible that we should treat similar to and "just" return here?

<!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
NB: Only panics for me with the flag.
Change:
self.bump(); pat = PatStruct(enum_path, fields, etc); } <ins> token::DotDotDot => { let hi = self.last_span.hi; let start = self.mk_expr(lo, hi, ExprPath(None, enum_path)); self.eat(&token::DotDotDot); let end = if self.token.is_ident() || self.token.is_path() { let path = self.parse_path(LifetimeAndTypesWithColons); let hi = self.span.hi; self.mk_expr(lo, hi, ExprPath(None, path)) } else { self.parse_literal_maybe_minus() }; pat = PatRange(start, end); } </ins> _ => { let mut args: Vec<P<Pat>> = Vec::new(); match self.token {

Discussion:
The following code: Produces this error: Putting parens around and doesn't fix it.
Also, it doesn't work too (Should?):
Change:
<ins> // Copyright 2018 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. // compile-pass #![deny(warnings)] use std::collections::BTreeMap; pub struct RangeMap { map: BTreeMap<Range, u8>, } #[derive(Eq, PartialEq, Ord, PartialOrd)] struct Range; impl RangeMap { fn iter_with_range<'a>(&'a self) -> impl Iterator<Item = (&'a Range, &'a u8)> + 'a { self.map.range(Range..Range) } pub fn iter<'a>(&'a self) -> impl Iterator<Item = &'a u8> + 'a { self.iter_with_range().map(|(_, data)| data) } } fn main() {} </ins>

Discussion:
Works on beta, but not on nightly. This breaks miri.
That was probably me. I'll have a look
Change:
specialization_graph_of: specialize::specialization_graph_provider, specializes: specialize::specializes, subst_and_check_impossible_predicates, <ins> check_tys_might_be_eq: misc::check_tys_might_be_eq, </ins> is_impossible_method, ..*providers };

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailsThis occurred in code different from the above but this is a minimal example that causes this failure. I believe I am disobeying some rules in the manner in which is not bound in the underlying type of the trait. This bug appeared in my own code that worked with a previous nightly build. That code does bind into the underlying type and still fails. If I bind it in this example with the following changes: the error goes away. I will need to create a minimal example that produces an ICE closer to the failure in my own code but I was struggling to do this. This is at least one ICE of interest and perhaps the unbound should itself be prevented. I'm not entirely sure. Worthy of note, the following also compiles fine: which omits all of the stuff.
I've isolated it to the following commit range: ..
I determined it was due to the above linked-from PR.
Prior to this PR, the above code would emit the following warning instead of generating the ICE:
This is caused by the fact that acts sort of like a const item with a const param ty the references other generic parameters: . When we relate the in we constrain infer vars to be the same as eachother but do not end up actually resolving the infer vars before relating so the assertion that const param ty's are sees two different infer vars instead of the resolved ones.
Change:
let mut y: &mut [int] = []; assert!(y.mut_pop_ref().is_none()); } <ins> #[test] fn test_mut_last() { let mut x = [1, 2, 3, 4, 5]; let h = x.mut_last(); assert_eq!(*h.unwrap(), 5); let mut y: &mut [int] = []; assert!(y.mut_last().is_none()); } </ins> } #[cfg(test)]

Discussion:
changed the , and methods of vectors to return an Option instead of failing on empty vectors. These methods should probably get the same change, to be consistent - - -
I'll try to fix this!