jiebi/CodeConvo huggingface dataset:
Code change:
#[cfg(any(target_os = "horizon", target_os = "hurd"))] pub fn accessed(&self) -> io::Result<SystemTime> { <del> Ok(SystemTime::from(self.stat.st_atim)) </del> <ins> SystemTime::new(self.stat.st_atim.tv_sec as i64, self.stat.st_atim.tv_nsec as i64) </ins> } #[cfg(any(

Related discussion:
text: Compiling project with causes the following compilation error: See this .
cc target maintainer
I guess has the same issue? This got broken by ("unix time module now return result") which dropped I guess the way forward is to make use instead. I'm wondering if there is a way to make sure that this kind of breakage doesn't happen before a rustc release?
Our platform support policy is to avoid blocking PRs on whether tier 3 platforms build, because tier 3 platforms are not required to build.
Sure, I'm not saying to block PRs, but I'm wondering about somehow getting notified quickly enough to be able to react before a rustc release.
(as in: getting the break notice from a getrandom CI build a dozen days after the merge does not look that robust)
Hm. Does the Rust compiler for hurd get built from a stable or beta branch of rustc? My understanding was that tier 3 targets generally used the nightly compiler in any case.
In Debian we will use the stable releases to compile all rust-needing Debian packages, as the Debian policy requires.
The breaking commit is not in the current 1.77 release but is in the 1.78 beta. It will not be in a stable release for another 5 weeks-ish. Would you like your PR that fixes it to be beta-nominated, so that it gets backported and is in the stable release of 1.78?
Yes, please.
I recommend you set up a daily/weekly job on your side building master to check for regressions. ( may fix this)
Code change:
use DefModifiers; use Module; <ins> use ModuleKind; </ins> use Namespace::{self, TypeNS, ValueNS}; use NameBindings; use NamespaceResult::{BoundResult, UnboundResult, UnknownResult};

Related discussion:
text: I found an error message that seems a bit off to me. The code: Clearly it should fail to compile, and it does. But the error message is: I would expect something like "a module name has already been imported", instead. Is it accurate to call it a type?
Code change:
<ins> error[E0308]: mismatched types --> $DIR/clone-on-unconstrained-borrowed-type-param.rs:3:5 | LL | fn wat<T>(t: &T) -> T { |        -            - expected `T` because of return type |        | |        this type parameter LL |     t.clone() |     ^^^^^^^^^ expected type parameter `T`, found `&T` | = note: expected type parameter `T` found reference `&T` note: `T` does not implement `Clone`, so `&T` was cloned instead --> $DIR/clone-on-unconstrained-borrowed-type-param.rs:3:5 | LL |     t.clone() |     ^ help: consider restricting type parameter `T` | LL | fn wat<T: Clone>(t: &T) -> T { |         +++++++ error[E0308]: mismatched types --> $DIR/clone-on-unconstrained-borrowed-type-param.rs:9:5 | LL | fn wut(t: &Foo) -> Foo { |                    --- expected `Foo` because of return type LL |     t.clone() |     ^^^^^^^^^ expected struct `Foo`, found `&Foo` | note: `Foo` does not implement `Clone`, so `&Foo` was cloned instead --> $DIR/clone-on-unconstrained-borrowed-type-param.rs:9:5 | LL |     t.clone() |     ^ help: consider annotating `Foo` with `#[derive(Clone)]` | LL | #[derive(Clone)] | error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

Related discussion:
text: This gives the very unintuitive error: You expect to return , i.e. a . It mysteriously returns an instead. Because has a clone impl, it too, can be cloned (really, copied), returning a reference of the same lifetime. This is an operation you rarely want to do explicitly, except when dealing with generics. This error can crop up when you've forgotten to implement on , and have a reference (which could have been silently inserted using , as in the code above). However, it's not very obvious what's happening here. It can also crop up We should hint that itself isn't cloneable and thus we fell back to cloning here. This could be a lint on hitting the clone impl for references, but lints run too late. I'm not sure how this can be implemented, since we need to see the source of a value and that's a bit tricky.
cc
Interesting. This does seem like it would require some pretty special-case code to achieve, but I agree it'd be a nice case to capture.
A relatively easy way to catch most instances of this is to Pick up the expression which has a type error like this If it is a method call, check if that method call is a clone() call resolving to If it is a variable, find the variable's def If the def is a local def, look at the init expr, check if it's a bad clone This will miss things, but I think the majority of such bugs will be due to this. As it stands this feels like an incredibly easy case to hit (we've all forgotten to decorate structs).
cc
CC
As reported in : This reports:
Current output is even worse for the original report: The last comment's code is marginally different:
Current output: The last case should suggest constraining . Edit: that was easier than I thought (we already had the suggestion machinery): <img width="511" alt="Screen Shot 2022-12-13 at 6 41 23 PM" src="https://user-"
Code change:
<ins> // Regression test for #72051, hang when resolving regions. // check-pass // edition:2018 pub async fn query<'a>(_: &(), _: &(), _: (&(dyn std::any::Any + 'a),) ) {} fn main() {} </ins>

Related discussion:
text: () Errors: Backtrace: modify labels: +I-hang +T-compiler +C-bug +A-lifetimes
somewhat minimized: To replicate this I needed: async two other arguments by ref at least one arg must not be bound to , compiles quickly the problematic argument must be contain an indirection: compiles fine. and also freeze. and a trait object containing at least one non marker trait explicitly bound to . and are both ok
repro is a regression in 1.43. It compiles immediately with 1.39 through 1.42.
I am currently bisecting this using
regression in modify labels: -E-needs-bisection
FYI who had context on .
Code change:
``` ptr::read(&v as *const _ as *const SomeType) // `v` transmuted to `SomeType` ``` <ins> Note that this does not move `v` (unlike `transmute`), and may need a call to `mem::forget(v)` in case you want to avoid destructors being called. </ins> "##, E0152: r##"

Related discussion:
text: The message for E0139 suggests replacing with . Actually performing such a replacement will result in double drops, since the version consumes but the version does not. (It presumably needs a or something.)
Code change:
``` ptr::read(&v as *const _ as *const SomeType) // `v` transmuted to `SomeType` ``` <ins> Note that this does not move `v` (unlike `transmute`), and may need a call to `mem::forget(v)` in case you want to avoid destructors being called. </ins> "##, E0152: r##"

Related discussion:
text: On currently nightly, I get: () Yet the description for this error was merged weeks ago:
cc , in the future when adding new diagnostics mods be sure to add a call
Code change:
} } <del> fn type_bound( &self, ty: Ty<'tcx>, visited: &mut SsoHashSet<GenericArg<'tcx>>, ) -> VerifyBound<'tcx> { match *ty.kind() { ty::Param(p) => self.param_bound(p), ty::Projection(data) => self.projection_bound(data, visited), ty::FnDef(_, substs) => { // HACK(eddyb) ignore lifetimes found shallowly in `substs`. // This is inconsistent with `ty::Adt` (including all substs), // but consistent with previous (accidental) behavior. // See https://github.com/rust-lang/rust/issues/70917 // for further background and discussion. let mut bounds = substs .iter() .filter_map(|child| match child.unpack() { GenericArgKind::Type(ty) => Some(self.type_bound(ty, visited)), GenericArgKind::Lifetime(_) => None, GenericArgKind::Const(_) => Some(self.recursive_bound(child, visited)), }) .filter(|bound| { // Remove bounds that must hold, since they are not interesting. !bound.must_hold() }); match (bounds.next(), bounds.next()) { (Some(first), None) => first, (first, second) => VerifyBound::AllBounds( first.into_iter().chain(second).chain(bounds).collect(), ), } } _ => self.recursive_bound(ty.into(), visited), } } </del> fn param_bound(&self, param_ty: ty::ParamTy) -> VerifyBound<'tcx> { debug!("param_bound(param_ty={:?})", param_ty);

Related discussion:
text: <!-- 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: Both asserts don't pass. Adding bound on makes it compile. We are requiring all the for closures and generators to outlive here: This is wrong and inconsistent with the logic in <!-- 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. --Build using the Nightly version: 1.63.0-nightly (2022-05-24 ) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details label T-compiler A-lifetimes A-closures A-generators claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Error: Parsing assign command in failed: ...'bot assign' ''... Please let know if you're having trouble with this bot.
Code change:
<ins> // ignore-emscripten no asm! support #![feature(asm)] fn main() { unsafe { asm! {"mov $0,$1"::"0"("bx"),"1"(0x00)} //~^ ERROR: invalid value for constraint in inline assembly } } </ins>

Related discussion:
text: Binder(<[type error] as ToBytes) This only happens if there are two erroneous functions, if I take out it works fine. It seems like I was trying to do this wrong in the first place since the first function gives an error . Not sure what the right way to do this is. <details<summaryTraceback</summary</details
Tried to reduce it and found a similar case with the same ICE:
Compiler triage: Seems likely to be caused by the need for lazy norm. Marking as p-medium for now.
The ICE doesn't appear on the latest nightly, marked as E-needstest
Code change:
let span = self.mark_span_with_reason(DesugaringKind::Await, dot_await_span, None); let gen_future_span = self.mark_span_with_reason( DesugaringKind::Await, <del> await_span, </del> <ins> full_span, </ins> self.allow_gen_future.clone(), ); let expr = self.lower_expr_mut(expr);

Related discussion:
text: This code: produces: Which is invalid. Looks like the span of the desugaring of uses only the part, instead of the span of the entire expression. This results in invalid suggestions when used by the code in .
I'm not entirely sure if this means that desugaring should use a bigger span, or if the suggestion diagnostic needs to be interpreted differently.
hmm.. is the only case where the desugared expr's span doesn't cover the whole piece of code it comes from? That doesn't sound right. If wonder if the expr should have the bigger span by default, and then async-specific code could grab the tighter span for diagnostics that need to point at the operator.
Some of the desugaring only uses the span, but the parts relevant for diagnostics like this do use the full span. Not sure if there's a problem there too.
I thought I might have accidentally introduced this bug in , but right after that PR was merged, the output was correct: So something changed in the last two months in what spans are used for await desugarings, it seems.
actually I think it was introduced in in , cc Do you need someone to fix this? I'm happy to put up a quick PR.
Yeah, looks like it: I just finished bisecting, which pointed at a rollup involving .
this was introduced in the PR linked earlier to try and improve other errors. It is tricky because reducing the span to only incurs these kind of bugs. On the other hand, the errors that got improved there became much less noisy, so I wouldn't want to revert the whole change. My fix above will solve this issue, but I'm sure there will be others in the future :-/
Code change:
pub fn output(cmd: &mut Command) -> String { let output = match cmd.stderr(Stdio::inherit()).output() { Ok(status) => status, <del> Err(e) => fail(&format!("failed to execute command: {}", e)), </del> <ins> Err(e) => fail(&format!("failed to execute command: {:?}nerror: {}", cmd, e)), </ins> }; if !output.status.success() { panic!("command did not execute successfully: {:?}n

Related discussion:
text: Rustbuild now prints which is very not helpful.
I've hit this one too: When there's a stale in Rust's root directory, bootstrap reads paths from there and tries to convert them into windows format using (which it, of course, can't find since we are not running in msys shell). The error message comes from in buildhelper (called from ).
Code change:
return; }; <del> let doc = item.doc_value(); if doc.is_empty() { return; } if let Some(item_id) = item.def_id() { check_redundant_explicit_link_for_did(cx, item, item_id, hir_id, &doc); } if let Some(item_id) = item.inline_stmt_id { check_redundant_explicit_link_for_did(cx, item, item_id, hir_id, &doc); </del> <ins> let hunks = prepare_to_doc_link_resolution(&item.attrs.doc_strings); for (item_id, doc) in hunks { if let Some(item_id) = item_id.or(item.def_id()) && !doc.is_empty() { check_redundant_explicit_link_for_did(cx, item, item_id, hir_id, &doc); } </ins> } }

Related discussion:
text: We've recently begun testing Bevy against the beta toolchain, where it has incorrectly raised an lint against . is not imported in this file, yet rustdoc believes that it is. (See the imports .) As a temporary workaround, I've created to ignore the error. Here is that first failed. In case it expires, here's . Look at . I can reproduce it on using by running the following command: The is optional, but it makes the command finish quicker. I'll continue testing to see if I can create a minimum reproducible example. :
I've created a minimal reproduction in my -repro branch of my fork. Go to the  folder and run . I've managed to squish it down to this:
I've created a reproduction that removes the dependency on Bevy . I've simplified it down to this:
I bisected it, and this bug appears to first be introduced in . I could not reproduce it in .
Code change:
<ins> // check-pass trait Factory { type Product; } impl Factory for () { type Product = (); } trait ProductConsumer<P> { fn consume(self, product: P); } impl<P> ProductConsumer<P> for () { fn consume(self, _: P) {} } fn make_product_consumer<F: Factory>(_: F) -> impl ProductConsumer<F::Product> { () } fn main() { let consumer = make_product_consumer(()); consumer.consume(()); } </ins>

Related discussion:
text: The compiler seems unable to determine that two types are equal. I tried this code: I expected the program to compile and run without issue, because is , so the call should be fine. Instead, I got this error message: The problem exists on stable 1.42 and nightly 1.44
It somehow compiles if you replace the associated type with a type parameter:
cc /
Possibly relevant rustc log entries: Seems like the will resolve the inference variable to yield , but for some reason is unable to normalize that further.
It seems like the opaque type has a substs with only in it; on first glance I'd have expected the projection there, but the docs on do explain this: So it seems like the is what was inserted for the type parameter, making . I'm not sure why this is represented like it is, but it seems like we need more info to be able to look at the real substs of the opaque type.
Duh, I forgot how opaque types work. Not sure where would be stored (? It's empty at this point according to log), but it's definitely not in the type, so this output makes sense.
This is fixed on nightly.
Code change:
check_expr_with_expectation_and_lvalue_pref( fcx, &**oprnd, expected_inner, lvalue_pref); let mut oprnd_t = fcx.expr_ty(&**oprnd); <del> if !ty::type_is_error(oprnd_t) && !ty::type_is_bot(oprnd_t) { </del> <ins> if !ty::type_is_error(oprnd_t) { </ins> match unop { ast::UnBox => { <del> oprnd_t = ty::mk_box(tcx, oprnd_t) </del> <ins> if !ty::type_is_bot(oprnd_t) { oprnd_t = ty::mk_box(tcx, oprnd_t) } </ins> } ast::UnUniq => { <del> oprnd_t = ty::mk_uniq(tcx, oprnd_t); </del> <ins> if !ty::type_is_bot(oprnd_t) { oprnd_t = ty::mk_uniq(tcx, oprnd_t); } </ins> } ast::UnDeref => { oprnd_t = structurally_resolved_type(fcx, expr.span, oprnd_t);

Related discussion:
text: Taking a look.
Probably the best fix for now is to disallow deref of outright. I'll work up a PR that fixes this and a few other ICEs surrounding .
This is fixed with a test, closing.
Code change:
#![allow(rustc::untranslatable_diagnostic)] use either::Either; <del> use hir::ClosureKind; </del> <ins> use hir::{ClosureKind, Path}; </ins> use rustc_data_structures::captures::Captures; use rustc_data_structures::fx::FxIndexSet; use rustc_errors::{codes::*, struct_span_code_err, Applicability, Diag, MultiSpan};

Related discussion:
text: No response No response No response
I thought the intent with was to use it in a passthrough style, so you can insert it into existing expressions ie. becomes . In which case, maybe the lint should be for not using the value resulting from evaluating .
Not sure about the majority of users but for me is a convenience over . I use it without using the return value almost all of the time.
Probably a common thing to do, sure, but if we're talking about adding a lint, why not nudge the user in the direction of the intended and documented usage? You could at least do both: "insert into an existing expression or pass it a borrow" etc.
The fix in will only report a hint when there is already a happened. For example this code: before this fix the error is: with the fix, since there is already a error, the lint will try to find out the original macro, and suggest a borrow: The suggestion is not 100% right, since if we change it to , we need one more extra fix now(the return type is not expecting a reference), but there is a different issue, at least we have already moved one step on. If the original code is: Then suggest a borrow is a great and correct hint.
Similar in the scenario of function argument: original error is: new errors from the fix:
Would not also be a good hint? The suggestion wouldn't compile anyway right? Because would need to change to take ? Without involved, the compiler does indeed suggest that: Once that's addressed (whichever way it's done), once again becomes transparent, and eg. or works. does not, however, and I see why a "consider borrowing" hint would be good there. However, if you make the change first and leave as-is, the resulting error does not include the suggestion to change , which is unhelpful. (I agree that the message is even less helpful though, I'm not disputing that.)
Yes, it's a good hint, but from the implementation view of a hint, it's much harder to analyze the following code from the error point and then construct a new expression. Even it seems an easy thing for humans. You are right, the suggestion is not 100% right, we may need an extra follow-up fix after applying the hint, which is also a common thing in rustc diagnostics.
Code change:
<del> error[E0658]: `#[thread_local]` is an experimental feature, and does not currently handle destructors. There is no corresponding `#[task_local]` mapping to the task model (see issue #29594) </del> <ins> error[E0658]: `#[thread_local]` is an experimental feature, and does not currently handle destructors. (see issue #29594) </ins> --> $DIR/feature-gate-thread_local.rs:18:1 | 18 | #[thread_local] //~ ERROR `#[thread_local]` is an experimental feature

Related discussion:
text: I will like to fix this. What should be the better warning message here? Or I just need to remove the last sentence?
It seems fine to just remove the sentence.
Fixed by
Code change:
/// let num_trailing = unsafe { cttz_nonzero(x) }; /// assert_eq!(num_trailing, 3); /// ``` <del> #[rustc_const_unstable(feature = "const_cttz", issue = "none")] </del> <ins> #[rustc_const_stable(feature = "const_cttz", since = "1.53.0")] </ins> pub fn cttz_nonzero<T: Copy>(x: T) -> T; /// Reverses the bytes in an integer type `T`.

Related discussion:
text: Tracking issue for trailingzeros and leadingzeros for non zero types as introduced by . The feature gate for the issue is . On many architectures, this functions can perform better than trailingzeros/leading_zeros on the underlying integer type, as special handling of zero can be avoided.
It seems on my (common) architecture it doesn't give an advantage: : : So the question is: is this NonZero method worth keeping? Are the architectures where it gives a performance advantage common enough?
but as you show in your example if you want to make a distributable binary and due to this not set the target-cpu there is a big difference
The architecture I'm using is quite standard. A distributable binary could probably use it as "universal target". I don't know much common is going to be an instruction like tzcnt in the future. If you think a similar instruction will be sufficiently uncommon then please ignore my comments here :-)
merge cc
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [ ] [x] [x] [x] [x] [x] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
started to make the stabilization PR but hit a problem I think that constcttz needs to be stabilized for this to be stabilized from //! If an intrinsic is supposed to be used from a with a attribute, //! the intrinsic's attribute must be , too. Such a change should not be done //! without T-lang consulation, because it bakes a feature into the language that cannot be //! replicated in user code without compiler support.
Code change:
<ins> error[E0668]: malformed inline assembly --> $DIR/issue-62046.rs:8:9 | LL |         asm!("nop" : "+r"("r15")); |         ^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to previous error For more information about this error, try `rustc --explain E0668`. </ins>

Related discussion:
text: Was working on bug and tried to compile the program below. The inline assembly may be bogus: I make no guarantees of its correctness. crashed with this output: : (but also happened on a nightly from late May)
The inline assembly is in fact bogus. Here's a minimal example that crashes the compiler. The problem is likely using the string operand (by mistake, because I'm dumb).
<details<summarybacktrace</summary</details
modify labels: I-ICE T-compiler A-inline-assembly C-bug
Thank you!