jiebi/CodeConvo huggingface dataset:
Change:
--> $DIR/numeric-cast.rs:52:18 | LL |     foo::<isize>(x_u8); <del> |                  ^^^^ expected `isize`, found `u8` | help: you can convert an `u8` to `isize` and panic if the converted value wouldn't fit | LL |     foo::<isize>(x_u8.try_into().unwrap()); |                  ^^^^^^^^^^^^^^^^^^^^^^^^ </del> <ins> |                  ^^^^ |                  | |                  expected `isize`, found `u8` |                  help: you can convert an `u8` to `isize`: `x_u8.into()` </ins> error[E0308]: mismatched types --> $DIR/numeric-cast.rs:55:18

Discussion:
() Errors: I would’ve expected something like: Edit: What actually should happen is the same as currently already with , i.e. it would look like modify labels: A-diagnostics, T-compiler, D-papercut, C-enhancement, E-easy <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Okay, lots of cases that already work got me confused into thinking this was fixed in nightly for a moment. What currently already works is the hint about converting where < where < What currently suggest even though works where < where ≤16 where ≤16
I reported a similar issue not long ago. Maybe it would be more robust and also more general to rewrite this suggestion code to actually look for the impl in question instead of having just a hard-coded list?
claim
I've created a PR augmenting the existing code to change the suggestions for the cases listed. However, I would like to explore the approach suggested(perhaps as part of a separate PR?). Any advice on how I could get the code to look for the impl so it can make the appropriate suggestion? Is the crate the right place to be looking at for this?
Yeah. I believe you'll need to create an and and then call , but there might be other/better ways to do this. You might want to ask for advice on Zulip.
Change:
<ins> error: unresolved link to `zip` --> $DIR/unused-extern-crate.rs:3:10 | LL | /// See [zip] crate. |          ^^^ no item named `zip` in scope | note: the lint level is defined here --> $DIR/unused-extern-crate.rs:2:9 | LL | #![deny(broken_intra_doc_links)] |         ^^^^^^^^^^^^^^^^^^^^^^ = help: to escape `[` and `]` characters, add '' before them like `[` or `]` error: aborting due to previous error </ins>

Discussion:
I'm running via on a small project with multiple crates via the workspaces feature, and I get the following error (I've sanitized the paths, project name and dependencies): ~ It always fails with random external dependencies or crates that are part of the workspace. It does succeed however for a crate without any dependencies. I've tried with Rust 1.43.0 and 1.43.1, on openSUSE Tumbleweed Linux, both from the distributions repository () and (). I've also tried with latest nightly with the same outcome. : ~ <details<summaryBacktrace</summary<p~ </p</details
I've tried to create a minimal example that would trigger the issue but failed to do so... Perhaps one of my dependencies generates the issue? (However in my workspace I also have one crate that depends only on another internal one (which itself has no further dependencies) and it still fails.) I'm willing to experiment if someone gives me some pointers!
OK, I've found the issue: create two libraries and , with nothing more than an edition 2018 and an empty as their code; make them part of the same workspace; make depend on ; add a in (the library that depends on ); At the following link there is a simple project that rebuilds all of the above: succeeds, meanwhile fails with the aforementioned error. It appears that by just adding (after the no implicit import prelude) is enough to make the documentation build. A second solution would be to add after the no import prelude annotation.
Possibly related to
Regression in nightly-2019-11-15 Most likely caused by <details<summaryFull bisection </summary</detailsThis also means you can't document librustdoc. <details<summaryBacktrace </summary</details
the cause is already known: But I don't know why you say librustdoc can't be documented, it's right here on the site: Make sure you're passing , it's stage 0 by default.
oh look, I knew I'd seen this bug before, apparently I just forgot. The fix for this is to turn the into a .
Change:
error[E0408]: variable `a` is not bound in all patterns <del> --> $DIR/resolve-inconsistent-names.rs:4:12 </del> <ins> --> $DIR/resolve-inconsistent-names.rs:13:12 </ins> | LL |        a | b => {} |        -   ^ pattern doesn't bind `a`

Discussion:
Given the example code: I get a really nice warning message about what I did wrong: However, if I change the main function to match multiple patterns: The error message is really confusing with no hint how to fix it: Please expand the error message for the second case to look a bit more like the first case.
Triage: no change. We need to supply the line in E0408.
so I thought I would implement the change you've proposed but have been thinking how best to restrict the kinds of cases where this help note would be appended to the error as I figured it may be rather noisy and/or confusing within the context of some false negatives. So during resolution we of course cannot look at the types to see if it's possible we're matching against an enum. But what do you think about having the help note kick in only if the binding starts with an upper case letter? I know this is a convention that should not really be a concern of the compiler but seeing that using it would only make the diagnostic note a bit more fine-grained, perhaps it's not a terrible idea?
we already do that in some places, like the parser to infer intent, but in this case how would you figure out that you want to suggest and without resolving ? I believe a more holistic solution would be to detect "variable not bound in all patterns" errors where all bindings are single idents, record that fact while throwing the current error and recovering as if there had been a single variable, and later when we have access to the machinery uses emit a warning suggesting and . It is a bit more involved but if we recover as if only had been present the current diagnostic should kick in suggesting (leaving without a suggestion). Edit: that won't work as things stand, as the warning won't be emitted today if there are errors, I think. That would also need to be changed to make it always be emitted :-/
no, I didn't mean to say we need to suggest possible variants. I too concluded that it's non-trivial with the current ordering of passes and the early bailout (indeed, type checking is impossible without resolution succeeding). I was going to add the help note you proposed back in May, just that I would make it dependent on bindings having a Variant-alike naming. From what you're saying there's a precedent in , so I guess this is an acceptable solution? I'll make a PR then.

sorry, I misunderstood. Go ahead, it sounds good.
no, it's likely me who wasn't clear enough. :) I submitted a PR.
Change:
return Err(FieldDoesNotImplementCopy(field.name)) } } <ins> struct_did </ins> } ty::ty_enum(enum_did, substs) => { let enum_variants = ty::enum_variants(tcx, enum_did);

Discussion:
Basically, it's now possible to write: and have everything work. This unfortunately means that doing something like with a will zero b, but not move it. /cc
I noticed this possibility too and was debating if this is a problem. It's not clear to me. Probably best to disallow it for now.
at the very least, it's causing incorrect behaviour at runtime, since it's zeroing out types like a move, but not forbidding the use of them like a copy.
Looks unsafe to me: Program received signal SIGSEGV, Segmentation fault. 0x0000555555598e5c in ()
I agree that combining it with zeroing is unsafe. If zeroing did not occur, or we did not zero for types that were copy, there wouldn't necessarily be a problem.
Anyhow, it's easiest to forbid it for now. We can always make it legal later if someone comes up with a persuasive use case. Idempotent destructors seem like a bit of an odd thing.
Change:
// pretty-mode:expanded // pp-exact:asm.pp <ins> // only-x86_64 </ins> pub fn main() { let a: i32;

Discussion:
The test is failing on AArch64. We should avoid having x8664-specific registers in that test. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc this is one of the tests that are failing on AArch64.
cc
I think it's just a matter of marking the test as
claim
Change:
return walked; } } <ins> // ZSTs do not need validation unless they're uninhabited if mplace.layout.is_zst() && !mplace.layout.abi.is_uninhabited() { return Ok(()); } </ins> self.walk_aggregate(mplace, fields) }

Discussion:
Test case: I left it compiling for just over half an hour, and it sat at constant memory usage and 100% of a CPU core for the entire time. Originally tested on . Checking through some different versions, these all take over a minute (I didn't bother sitting around for the full 30 minutes): Going back a little further it works and compiles in about a second on: Going back even further it ICEs with on: (this may be a duplicate of one of the existing large array compile time issues, but I didn't find one it fit exactly with, especially given it worked on at least two stable releases).
I've tried to compile this with , but it's been running for two hours and it didn't complete, so I had to cut it off. Maybe someone else can try? I think my computer is getting old :D So I tried compiling using the compiler for the last commit (installed with ): Here's what I got: <details<summary<strongStandard output</strong(if that even matters)</summary<p</p</details<details<summary<strongStandard error</strong</summary<p</p</detailsThis last line: Is emitted in here: So I believe this is a const eval bug? cc do you have any idea what may be happening?
Hm, not off the top of my head. Cc I take it it keeps going after that last line without outputting anything any more? Then that's just the last thing it completed, which might or might not have anything to do with the next thing it is doing. Could you use to capture a backtrace of what code it is running then? (Let me know if you need help with that.)
is the LLDB output for the command with latest nightly ().
Okay so this is interning walking every single field of that array... and taking forever to do that, obviously.
Letting it run a bit longer gave me an additional frame:
How did you originally find this? Did it impact a real code you had?
Assigning .
the context was , I was just trying to find out whether you could have a ZST array with length , so no, not real code.
Alright, it is fine being then
For arrays and slices we could make interning check the relocation map for relocations within the array, compute the indices which have relocations and only look at those indices.

This way we don't have to walk all elements, but only those that interning cares about. Not sure what validation will do after interning is finished, maybe that'll also run forever? I thought we had some optimizations in there. Oh yea, and interning can skip any zst type in general.
Change:
} } <ins> fn emit_deprecated_safe_fn_call(&self, span: Span, kind: &UnsafeOpKind) -> bool { match kind { // Allow calls to deprecated-safe unsafe functions if the caller is // from an edition before 2024. &UnsafeOpKind::CallToUnsafeFunction(Some(id)) if !span.at_least_rust_2024() && self.tcx.has_attr(id, sym::rustc_deprecated_safe_2024) => { self.tcx.emit_node_span_lint( DEPRECATED_SAFE, self.hir_context, span, CallToDeprecatedSafeFnRequiresUnsafe { span, function: with_no_trimmed_paths!(self.tcx.def_path_str(id)), sub: CallToDeprecatedSafeFnRequiresUnsafeSub { left: span.shrink_to_lo(), right: span.shrink_to_hi(), }, }, ); true } _ => false, } } </ins> fn requires_unsafe(&mut self, span: Span, kind: UnsafeOpKind) { let unsafe_op_in_unsafe_fn_allowed = self.unsafe_op_in_unsafe_fn_allowed(); match self.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: will become in Rust 2024, the above code is using Rust 2021, so this should compile with no issue. Instead, this happened: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<pNot needed </p</detailsI think the root cause is the lint , commenting it out would make the code compile: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Thanks for the report! That should not happen. We did a so I don't know how this is even possible... any ideas? This seems to be some bad interaction with .
claim Hmmm, weird that crater run didn't catch this.
I posted a PR fixing this: . Does crater maybe restrict lints?
I don't think it does. Is this code part of the "nix" crate?
If you are asking if this problem originates from the nix crate, then yes, see
I am wondering whether the nix crate as published on fails to build with latest nightly due to this issue.
I think yes, the has been in Nix for a long time. One should be able to reproduce the build failure on a UNIX platform other than: I am currently on Linux, will try reproducing it on my mac tomorrow.
Looks like crater tested nix 0.26.4 and that failed already before the removevar/setvar change (). That's due to the which makes the build fail even when there are just warnings. I guess we can add this to the list of why having deny(warnings) in the code is considered bad practice.
I created an issue and a PR against nix-rust.
Yeah, we can reproduce this on macOS
The reason this was missed is a combination of and
WG-prioritization assigning priority (). label -I-prioritize +P-high
Fix already exists, just needs a review: .
Change:
pub fn type_has_metadata(&self, ty: Ty<'tcx>) -> bool { use syntax_pos::DUMMY_SP; <del> if ty.is_sized(self.tcx, ty::ParamEnv::empty(traits::Reveal::All), DUMMY_SP) { </del> <ins> if ty.is_sized(self.tcx.at(DUMMY_SP), ty::ParamEnv::empty(traits::Reveal::All)) { </ins> return false; }

Discussion:
One example is the method on . Internally it creates a , when it could simply be taking exactly that as an argument. In miri I had to write which just feels a little riddiculous (taking apart the , just to have the method construct it back). There's probably many other similar methods and functions that should be taking a
Can I take this one if no one is working on that ?
it's all yours!
Change:
// needs drop. let adt_has_dtor = |adt_def: ty::AdtDef<'tcx>| adt_def.destructor(tcx).map(|_| DtorType::Significant); <del> let res = drop_tys_helper(tcx, query.value, query.param_env, adt_has_dtor, false).next().is_some(); </del> <ins> let res = drop_tys_helper(tcx, query.value, query.param_env, adt_has_dtor, false) .filter(filter_array_elements(tcx, query.param_env)) .next() .is_some(); </ins> debug!("needs_drop_raw({:?}) = {:?}", query, res); res } <ins> /// HACK: in order to not mistakenly assume that `[PhantomData<T>; N]` requires drop glue /// we check the element type for drop glue. The correct fix would be looking at the /// entirety of the code around `needs_drop_components` and this file and come up with /// logic that is easier to follow while not repeating any checks that may thus diverge. fn filter_array_elements<'tcx>( tcx: TyCtxt<'tcx>, param_env: ty::ParamEnv<'tcx>, ) -> impl Fn(&Result<Ty<'tcx>, AlwaysRequiresDrop>) -> bool { move |ty| match ty { Ok(ty) => match *ty.kind() { ty::Array(elem, _) => tcx.needs_drop_raw(param_env.and(elem)), _ => true, }, Err(AlwaysRequiresDrop) => true, } } </ins> fn has_significant_drop_raw<'tcx>( tcx: TyCtxt<'tcx>, query: ty::ParamEnvAnd<'tcx, Ty<'tcx>>,

Discussion:
I tried this code: I expected it to compile successfully. Instead, this happened: It most recently worked on 1.72 Regressed in cc Originally reported in cc modify labels: +regression-from-stable-to-beta -regression-untriaged
WG-prioritization assigning priority (). label -I-prioritize +P-high
Change:
function Invoke-Application($application, $arguments) { $process = Start-Process -NoNewWindow -PassThru $application $arguments <ins> # WORKAROUND: Caching the handle is necessary to make ExitCode work. # See https://stackoverflow.com/a/23797762 $handle = $process.Handle </ins> $process.WaitForExit() <ins> if ($null -eq $process.ExitCode) { Write-Error "Unable to read the exit code" Exit 1 } </ins> Exit $process.ExitCode }

Discussion:
The  shell script does not return with an exit code if the build fails. The object doesn't appear to be an integer. cc This may be an important issue since something could potentially fail in CI without failing the build. Noticed in CI when something funky happened. Fortunately the metrics don't get created when a test fails (I think), but there may be other situations where it isn't working correctly. This looks like it was in .
This is weird. I do remember doing a fair bit of testing of that PR.
PowerShell is always the odd one, with it's 5+ streams and .NET integrations and structured pipelines. Honestly, it doesn't surprise me that much that PowerShell does not care about exit codes, since the way to declare an error in PowerShell is to print something to the Error stream (IIRC).
Oh it did work originally. But then I broke it. There's a defect when using instead of the parameter where ExitCode isn't set.
Change:
#[derive(Clone, Debug, Hash, PartialEq, Eq)] pub(crate) enum UrlFragment { Item(DefId), <ins> /// A part of a page that isn't a rust item. /// /// Eg: `[Vector Examples](std::vec::Vec#examples)` </ins> UserWritten(String), }

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:
[[package]] name = "pulldown-cmark" <del> version = "0.0.14" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "bitflags 0.8.2 (registry+https://github.com/rust-lang/crates.io-index)", ] [[package]] name = "pulldown-cmark" </del> version = "0.0.15" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [

Discussion:
generates different HTML under and not. Not only does this trigger what's effectively a spurious warning, but it doesn't render correctly either. cc , marking this as p-high
This was fixed by google/pulldown-cmark rustdoc just needs to update its version of pulldown-cmark.
The thread in that issue says it was released in 0.0.15. we're pulling in 0.0.14 for rustdoc, but also 0.1.0 for mdbook. I'll see if i can update the dependency for rustdoc and pull it in.
updates Pulldown for rustdoc and fixes this.
I am not sure this actually fixes the warnings, as they use different IDs and such. I'm testing this locally right now though; expect an update in ~20 minutes
Change:
<ins> #![feature(type_alias_impl_trait)] //! This test used to ICE rust-lang/rust#124891 //! because we added an assertion for catching cases where opaque types get //! registered during the processing of subtyping predicates. type Tait = impl FnOnce() -> (); fn reify_as_tait() -> Thunk<Tait> { Thunk::new(|cont| cont) //~^ ERROR: mismatched types //~| ERROR: mismatched types } struct Thunk<F>(F); impl<F> Thunk<F> { fn new(f: F) where F: ContFn, { todo!(); } } trait ContFn {} impl<F: FnOnce(Tait) -> ()> ContFn for F {} fn main() {} </ins>

Discussion:
https://crater- https://crater- https://crater- https://crater- https://crater- https://crater- probably cc
Yeah Matthias also found . Think it hasn't been fixed b/c oli is on holiday -- I assume he will investigate when he's back next week.
MCVE in
WG-prioritization assigning priority (). I'll mark this as because it seems an unintended breaking change and therefore should probably be fixed before entering into stable. label -I-prioritize +P-critical

<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: opaque types got hidden types registered from within subtype predicate: Alias(Opaque, AliasTy { args: [], defid: DefId(0:25 ~ ice[ee90]::Tait::{opaque}) }) vs Continuation', 'error: internal compiler error: opaque types got hidden types registered from within subtype predicate: Alias(Opaque, AliasTy { args: [], defid: DefId(0:25 ~ ice[ee90]::Tait::{opaque}) }) vs Continuation' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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: [typeck] type-checking [typeofopaque] computing type of opaque [typeof] computing type of [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate -- label +F-typealiasimpl_trait
bit smaller
Change:
<ins> // check-pass #![feature(inherent_associated_types)] #![allow(incomplete_features)] struct Foo<T>(T); impl<'a> Foo<fn(&'a ())> { type Assoc = &'a (); } fn bar(_: for<'a> fn(Foo<fn(Foo<fn(&'a ())>::Assoc)>::Assoc)) {} fn main() {} </ins>

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</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Hm, maybe not really a new (this month) regression but I also can't find any obvious duplicates right now...
searched toolchains nightly-2022-11-28 through nightly-2023-05-09 Regression in nightly-2022-12-05 Regression in cc
label F-inherentassociatedtypes
I'm pretty sure this can be fixed by erasing all regions no matter their de Bruijn index via instead of . This would "regress" but eh, I guess that's fine for now.
claim