jiebi/CodeConvo huggingface dataset:
Change:
target_os = "vxworks", target_os = "horizon", target_os = "emscripten", <del> target_os = "aix" </del> <ins> target_os = "aix", target_os = "freebsd", </ins> ))] #[cfg_attr(target_family = "wasm", allow(unused))] // might remain unused depending on target details (e.g. wasm32-unknown-emscripten) pub unsafe fn register_dtor(t: *mut u8, dtor: unsafe extern "C" fn(*mut u8)) {

Discussion:
Apologies if this isn't the right place, it isn't obvious to me if this originates in rustc or should be upstreamed to FreeBSD. My limited understand of the warnings however suggests it could be a misuse of s on our end. The following comment from seems relevant: I can't reproduce this on latest stable, just latest nightly so far.
Bisected with : regressed nightly: nightly-2024-01-24 searched commit range: regressed commit: I think it is probably ( which is awkward because all that change did was enable thread-local support on FreeBSD.
Can reproduce too, however no problem on netbsd (reading ). It might be valuable to get an insight of what might happen in the system side of things.
Rustc doesn't dlclose any of the libraries it dlopen's. And if you don't use proc macros or a codegen backend other than the default LLVM, it doesn't dlopen any library.
ktrace for the curious: <details<summarykdump</summary</details
Change:
<ins> fn generic<const N: u32>() {} trait Collate<const A: u32> { type Pass; fn collate(self) -> Self::Pass; } impl<const B: u32> Collate<B> for i32 { type Pass = (); fn collate(self) -> Self::Pass { generic::<{ true }>() //~^ ERROR: mismatched types } } fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'called on a value'', 'thread 'rustc' panicked at 'called on a value'' 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 [checkmatch] match-checking -- label +F-constgenerics +F-constevaluatablechecked
Slightly minimized with fewer errors: The compiler seems to have trouble figuring out whether the type of matches the returned type <details<summaryProgram output</summary</summary

<!-- 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<strongICE location label +F-fn_delegation
Adding more methods in trait creates more ICE :eyes: <details<summary<strongBacktrace</strong</summary<p</p</details
Change:
<ins> // aux-build:issue-66159-1.rs // extern-private:issue_66159_1 // The issue was an ICE which meant that we never actually generated the docs // so if we have generated the docs, we're okay. // Since we don't generate the docs for the auxilliary files, we can't actually // verify that the struct is linked correctly. // @has issue_66159/index.html //! [issue_66159_1::Something] </ins>

Discussion:
/cc
So the explosion is that somehow the crate index in the is broken, or at least not entirely right. Interestingly if you add to the then it no longer ICEs (but has the same ) Edit: So this looks like it's somehow a bug when trying to resolve it as a global name (both and prevent the iCE)
Maybe it's linked to ? If so, it's not in rustdoc but below.
I believe I've worked out approximately what's going on: Rustdoc freezes the compiler state (resolver, etc) as part of the setup to ready the instance. Since was made optional, and crate names are automatically part of the global scope, people stopped necessarily telling the compiler about the crates in their code. If a comment references a path in this manner, but the code itself doesn't, then the resolver frozen into the doesn't have that crate's metadata loaded into it. When we then ask the resolver to resolve a new path (e.g. ) it goes ahead and loads the crate into a different instance of the than will be used when we then try and use the later. It feels like the moment a is d it should also be locked so that it can never be modified again. It's also possible that rustdoc could be forced to enter the right context so that we never do this wrongly, but that's beyond me right now. Given that, , I feel this is probably either a bug in how is handling the resolver, or else a change in how the resolver behaves which either needs fixing, or changing in to cope.
My gut feeling is that we probably need to stop capturing/cloning the resolver as we do here: and instead try and find a resolver as part of the closure here: Of course, it looks like a has an immutable copy of the resolver's outputs, and no access to the resolver itself, urgh, and we have no easy way to inject changes into the context at this point.
I wonder why that type can be cloned in the first place...

I found an ICE when trying to document the [spirit-log][1] crate on the latest . Skimming through the backtrace, it looks like accessed an invalid index while traversing links within . Steps to reproduce: [1]:
Taking a look.
Actually, it's failing outside of rustdoc so I prefer to let someone else handle it. cc
I think this might be a bug (or at least mismatch between how uses the resolver infrastructure and how it's meant to work). See my comment here:
Change:
return; } <del> // check_submodule let checked_out_hash = output(helpers::git(Some(&absolute_path)).args(["rev-parse", "HEAD"])); // update_submodules </del> <ins> let submodule_git = || helpers::git(Some(&absolute_path)); // Determine commit checked out in submodule. let checked_out_hash = output(submodule_git().args(["rev-parse", "HEAD"])); let checked_out_hash = checked_out_hash.trim_end(); // Determine commit that the submodule *should* have. </ins> let recorded = output(helpers::git(Some(&self.src)).args(["ls-tree", "HEAD"]).arg(relative_path)); let actual_hash = recorded

Discussion:
To reproduce, I am in a worktree without (i.e., not the "main" worktree). I have a pre-commit hook set up as follows Now I change something trivial (e.g. remove a trailing in some comments) and commit. That does the following After a second or two I get suspicious and hit Ctrl-C. Now it looks like bootstrap has done something with the (previously clean) cargo submodule So let's and see what's up Eh... so the files are rustc files? Why are those being in ? Something is going seriously wrong here.
I think this only happens with . I attempted to reproduce it about 25 times without success.
Yes indeed, this does not happen in my folder (the main checkout, where lives), but it happens in worktree folders.
Adding some debug logging, it seems like some truly strange things are happening... This is the HEAD commit of the outer repository! I think what's happening is that some environment variables are set inside the git hook which overwrite the . x.py relies on just setting the working directory to determine which git dir to use, but e.g. GITDIR takes precedence over that. I tried setting instead of using and that does seem to help.
Change:
#[stable(feature = "nonzero", since = "1.28.0")] pub use core::num::{NonZeroU8, NonZeroU16, NonZeroU32, NonZeroU64, NonZeroU128, NonZeroUsize}; <ins> #[stable(feature = "signed_nonzero", since = "1.34.0")] pub use core::num::{NonZeroI8, NonZeroI16, NonZeroI32, NonZeroI64, NonZeroI128, NonZeroIsize}; </ins> #[cfg(test)] use crate::fmt; #[cfg(test)] use crate::ops::{Add, Sub, Mul, Div, Rem};

Discussion:
The signed variants are not re-exported in here: We should duplicate that line and re-export them. cc -- this will likely slip into 1.34, but we will backport the fix into 1.35
Change:
) .unwrap(); let mut hidden_type = infcx.resolve_vars_if_possible(decl.hidden_type); <ins> // Check that RPITs are only constrained in their outermost // function, otherwise report a mismatched types error. if let OpaqueTyOrigin::FnReturn(parent) | OpaqueTyOrigin::AsyncFn(parent) = infcx.opaque_ty_origin_unchecked(opaque_type_key.def_id, hidden_type.span) && parent.to_def_id() != body.source.def_id() { infcx .report_mismatched_types( &ObligationCause::misc( hidden_type.span, infcx.tcx.hir().local_def_id_to_hir_id( body.source.def_id().expect_local(), ), ), infcx.tcx.mk_opaque(opaque_type_key.def_id.to_def_id(), opaque_type_key.substs), hidden_type.ty, ty::error::TypeError::Mismatch, ) .emit(); } </ins> trace!( "finalized opaque type {:?} to {:#?}", opaque_type_key,

Discussion:
Messing around with a Haskell-like implementation of , I encountered two presumably similar ICEs (would think they're the same, but the error messages are obviously different). The other one is . I'm pretty sure this should be an error, based on the reasoning that returns an opaque type, so, while the output of might be , it also might not (and in this case, isn't), and since only accepts s, should be an error. Note that this implementation throws the ICE even without the main method, but I'm leaving it there for contrast to the other ICE. : Same ICE on nightly: <details<summary<strongBacktrace</strong</summary<p</p</details
This regressed in
I was able to "weaponize" this into a transmute, lol: So the issue here is that, at least in the case of RPITs, we are not checking for opaque type mismatches in closures correctly. The closure, in this example, is able to incorrectly constrain even though in the enclosing function, we define . During mir borrowck, we never check these two together, so we never report a type mismatch. I think I have a fix, though.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Change:
let used_links_bor = &mut used_links; let mut assoc_consts = v .iter() <ins> .filter(|i| i.inner_impl().trait_.is_none()) </ins> .flat_map(|i| get_associated_constants(i.inner_impl(), used_links_bor)) .collect::<Vec<_>>(); if !assoc_consts.is_empty() {

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: I would expect not to appear as its own item in the rustdoc sidebar for the struct. This would be consistent with the behavior of methods and associated types from trait impls, which also don't appear as their own item in the sidebar. Instead, this happened: The constant is listed under "Associated Constants" in the left-hand sidebar of the rustdoc page for . This is inconsistent with how methods from trait impls appear in documentation. ! <!-- 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. --:
This was intentionally in .
The inclusion of associated consts from inherent impls is intentional. But is it intentional that associated consts from trait impls also appear in the sidebar (even though methods from trait impls do not)? (I'm filing this bug because for a crate I'm developing, the current behavior makes the sidebar extremely messy. Restricting the list of associated constants to those from inherent impls would make navigating the documentation for my crate much more pleasant.)
I think the behavior proposes makes sense.
Change:
// revisions: wasm32_wasi_preview2 // [wasm32_wasi_preview2] compile-flags: --target wasm32-wasi-preview2 // [wasm32_wasi_preview2] needs-llvm-components: webassembly <del> // revisions: x86_64_apple_darwin // [x86_64_apple_darwin] compile-flags: --target x86_64-apple-darwin // [x86_64_apple_darwin] needs-llvm-components: x86 // revisions: x86_64_apple_ios // [x86_64_apple_ios] compile-flags: --target x86_64-apple-ios // [x86_64_apple_ios] needs-llvm-components: x86 // revisions: x86_64_apple_ios_macabi // [x86_64_apple_ios_macabi] compile-flags: --target x86_64-apple-ios-macabi // [x86_64_apple_ios_macabi] needs-llvm-components: x86 // revisions: x86_64_apple_tvos // [x86_64_apple_tvos] compile-flags: --target x86_64-apple-tvos // [x86_64_apple_tvos] needs-llvm-components: x86 // revisions: x86_64_apple_watchos_sim // [x86_64_apple_watchos_sim] compile-flags: --target x86_64-apple-watchos-sim // [x86_64_apple_watchos_sim] needs-llvm-components: x86 </del> // revisions: x86_64_fortanix_unknown_sgx // [x86_64_fortanix_unknown_sgx] compile-flags: --target x86_64-fortanix-unknown-sgx // [x86_64_fortanix_unknown_sgx] needs-llvm-components: x86

Discussion:
Right now I have to run with applied, but when I do several tests fail, eg: tests/assembly/targets/targets- more are visible in
I think this test should check for instead of . I believe that currently this test is actually matching something like , which is not emitted on Solaris since I assume the intention was to look for , but that's one of the section types for which an explicit is normally omitted.
Okay, just looking for doesn't work, because apparently targets-elf, despite the name, currently also includes the MachO targets.
Change:
} let loc = cx.lookup_debug_loc(scope_data.span.lo()); <del> let file_metadata = file_metadata(cx, &loc.file.name, debug_context.defining_crate); </del> <ins> let file_metadata = file_metadata(cx, &loc.file, debug_context.defining_crate); </ins> let scope_metadata = unsafe { Some(llvm::LLVMRustDIBuilderCreateLexicalBlock(

Discussion:
shows a pretty big regression between and . I don't know if this is expected, but I'm putting this out there in case others see the dent in perf charts and wonder what had happened. <hr/EDIT( we how have a for . , the other PR in the range, (but only for a small subset of runs).
cc
The range is so the candidates are: "Make the rustc respect the flag in incremental mode." "Add hash of source files in debug info" EDIT: oops, missed - so it's likely . Slow MD5 implementation? I'm curious, why does (merge commit for ) not have its own perf run? Is there a way to trigger one now?
is in the queue:
It looks like this was caused by . I'll start investigating why. I timed several compilations of locally in debug with and without .
For the record, from . I'll update the issue description to minimize potential confusion. Two things I'm seeing: are way worse regressions than , you can focus on the worse ones to get better contrast in measurements (e.g. even has "patched incremental" runs slowed down a lot, unlike many others, being another example I guess) detailed profile (if you click the percentage for a run) shows a lot of LLVM differences, e.g. for , and most of the regressions are , with effectively no ones, so I think we might be able to get away without a revert, just adding a flag controlling whether LLVM sees these hashes (assuming that's the source of the slowdown)
We have (), which at a glance looks right. looks like noise, and so does , so I believe this confirms the fix is complete. For the cost of MD5 hashing compared to SipHash, based on the changes to runs in the original regression, it looks insignificant.
Change:
fn item_function(w: &mut fmt::Formatter, cx: &Context, it: &clean::Item, f: &clean::Function) -> fmt::Result { <del> try!(write!(w, "<pre class='rust fn'>{vis}{unsafety}{abi}{constness}fn  </del> <ins> try!(write!(w, "<pre class='rust fn'>{vis}{constness}{unsafety}{abi}fn  </ins> {name}{generics}{decl}{where_clause}</pre>", vis = VisSpace(it.visibility), <ins> constness = ConstnessSpace(f.constness), </ins> unsafety = UnsafetySpace(f.unsafety), abi = AbiSpace(f.abi), <del> constness = ConstnessSpace(f.constness), </del> name = it.name.as_ref().unwrap(), generics = f.generics, where_clause = WhereClause(&f.generics),

Discussion:
Doc inclusion / doc reexport does not show properly (example: std::cell::Cell::new). Reexport metabug: rustdoc: Pain points of reexports const fn tracker:
Change:
&lld_install.join("bin").join(&src_exe), &gcc_ld_dir.join(exe("ld", target_compiler.host)), ); <ins> builder.copy( &lld_install.join("bin").join(&src_exe), &gcc_ld_dir.join(exe("ld64", target_compiler.host)), ); </ins> } // Similarly, copy `llvm-dwp` into libdir for Split DWARF. Only copy it when the LLVM

Discussion:
has progressed to the point where there is now a flag for linux builds. On a lark, I tested what happens on macos. Surprisingly, it wasn't immediately rejected. Unsurprisingly, it exploded. I'm not 100% sure if macos and linux are similar enough environments that the same mechanism should just work, but I think it should? <details<summarybuild log </summary</details
Oh interesting, ok so with it's blowing up in build scripts, but it seems to build (something with no dependencies or build scripts) fine!
(I do not have a readily available linux env to test if this failure mode is uniquely macos or just the usual "build-scripts and plugins have weird interactions with compiler flags" problem)
Using gets farther on rust-minidump's , but still blows up at the final link: <details<summarybuild log </summary</details<details<summaryfailing cc invocation broken up into lines</summary</details
Maybe your lld is too old? I can build my workspace with:
There is one binary lld and various symbolic links with different names. You have to pass for OSX and for linux. You are probably passing the wrong flavour, i.e. gnu.
Change:
} bb5: { <del> _9 = move ((_1 as Ok).0: i32); </del> <ins> _9 = ((_1 as Ok).0: i32); </ins> _2 = ControlFlow::<Result<Infallible, i32>, i32>::Continue(_9); goto -> bb3; }

Discussion:
Right: Wrong: The first argument to is partially moved. GVN causes the second argument to use the partially moved value:
I can't provoke the miscompilation on beta using this example (just had to replace with to make it build), so I don't think there's any need to rush to fix this. (Some part of GVN is used in the beta that's about to become stable, but it looks like it doesn't have this bug in it)
Cc
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
<del> Subproject commit a71a0083937671d79e16bfac4c7b8cab9c8ab9bb </del> <ins> Subproject commit 3b8b6aa8b689971d3b8776cefe3d809501e1b8ff </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!
Why did this get closed? https://rust-lang- says Miri is still broken.
Oh whoops. I misinterpreted the PR linking to this.
Change:
<ins> error: expected type, found `"test"` --> $DIR/diagnostics-parenthesized-type-arguments-issue-120892-1.rs:11:9 | LL |   foo::( |      --- while parsing this parenthesized list of type arguments starting here ... LL |     baz("test"), |         ^^^^^^ expected type | help: consider removing the `::` here to call the expression | LL -   foo::( LL +   foo( | error: aborting due to 1 previous error </ins>

Discussion:
Given an invalid call such as: The following diagnostic is issued: This gets much worse on multiline calls: Which just prints out a diagnostic nowhere near the error: Ideally this should mention something about either missing a missing turbofish (e.g. ), or a missing identifier (e.g. ). This would at least get the error pointing to the correct spot. Latest playground nightly (2024-02-09) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Oh, wow, it didn't even occur to me until now that the expression is syntactically valid .< Edit: Wow, even is syntactically well-formed.
This should pretty easy to fix, basically if we fail to parse a type here we should first of all attach a label to the saying something akin to while parsing this list of parenthesized type arguments starting here and we should suggest removing the trailing path separator if the is , the parenthesized generics aren't followed by or and if the list of non-types we encountered can be successfully parsed as a list of expressions (using a snapshot parser). Furthermore, if the is we can try to reparse the list as a list of patterns and provide the same structured suggestion. I will gladly mentor & review any PR for this.
claim
Hello , is this issue still open for mentoring? I can see that already claimed the issue, but there seems to be no progress.
I read the code but no time to finish it at the moment. You can do it.
Change:
tcx.sess.delay_span_bug( DUMMY_SP, &format!( <del> "missing generic parameter for `AnonConst`, parent {:?}", parent_node </del> <ins> "missing generic parameter for `AnonConst`, parent: {:?}, res: {:?}", parent_node, res </ins> ), ); tcx.types.err

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 --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
managed to reduce the test case a bit.
Also happens for this code using a function instead of an associated type:
claim
initial example fixed by , associated function fixed by instead
Change:
/// assert_eq!(res, Poll::Ready(Some(Err(0)))); /// ``` #[stable(feature = "poll_map", since = "1.51.0")] <ins> #[inline] </ins> pub fn map_err<U, F>(self, f: F) -> Poll<Option<Result<T, U>>> where F: FnOnce(E) -> U,

Discussion:
I noticed that in one of my project, inlining [] manually reduces some binary size, then I noticed is not marked . Since both [] and [] are marked , I wonder whether this is an oversight. I failed to reproduce the binary size reduction effect with an example code, but maybe the reason behind inlining and also applies to ? How about [] and []? []: []: []: []: []:
That's surprising. Can you share your project?
Unfortunately, it is a private project, I cannot share it.
Ah okay. I find it suspicious that these functions aren't inlining already. Did you try building your project against a modified standard library with to those functions? Do you still get a code size improvement from manual inlining if you compile with and/or in your release profile? The functions in question ought to already be eligible for inlining, but by default the release profile has multiple codegen units per crate, which can result in surprising failures to inline things. How big are these functions once they are compiled in your crate? The third-party tool can help out here, can you share the output of (of course trimming that down a bit if there are type names in there you don't want to fully disclose) If for whatever reason these functions end up looking big to LLVM after other things are inlined into them, that may explain what's going on here, and your manual inlining has effectively changed in what order LLVM considers inlining things.
I have done some tests on my project, using to check for symbols: Using , does not get inlined; Using , gets inlined; Using and , add to standard library source code, gets inlined; All configurations above are using and . reports that each is about 68 to 96 bytes.
What about and to the standard library code, but without using ? If that configuration gets these functions inlined I think this is worth doing because it unlocks additional useful optimizations for users, but if the optimization is gated behind it's a bit less certain if this is a win. Do you or any other LLVM folks have insight into why would be impactful here? Are we relying on the hint part of its behavior?
It seems that changing standard library source code only works with . Do I need to compile a customized version of Rust in order to test it?
That's what I do. It's a very slow workflow.