jiebi/CodeConvo huggingface dataset:
Change:
#[inline(always)] fn lookup(&self, key: &K) -> Option<(V, DepNodeIndex)> { <ins> // FIXME: lock_shard_by_hash will use high bits which are usually zero in the index() passed // here. This makes sharding essentially useless, always selecting the zero'th shard. </ins> let lock = self.cache.lock_shard_by_hash(key.index() as u64); if let Some(Some(value)) = lock.get(*key) { Some(*value) } else { None } }

Discussion:
Per-crate cache maps keyed on may be more efficient and/or allow us to use for queries keyed on instead of . We can use specialization (e.g. for splitting into and ), I think. cc
Sounds like a good idea if the lookup array ends up being densely populated enough. In general, we should provide a way to implement customized in-memory caching for specific queries.
Change:
<ins> panicked at $DIR/panic-in-message-fmt.rs:18:9: thread panicked while processing panic. aborting. </ins>

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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --The following occurs when running the tests Given the following code: When the tests are ran, the current output is: After figuring out what the actual issue is, the error message makes sense. But my debugging journey would have been more pleasant, if the source location of the panics were included in the message. Much like the location of "non-nested" panics are printed. <!-- The following is not always necessary. --Ideally the output should look like: At least include the source location of the "inner" panic, or ideally both. It also suggests to rerun pass with '--lib', which is a bit misleading. If above is not possible, at least print the name of the test that is failing. <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --
When run through instead of a test: () The full panic message and backtrace for the second panic is printed: <details<summaryOutput</summary</detailsI think when run as a test, the panic output is captured (as normal for a test), but is then not printed because of the abort. label -A-diagnostics -T-compiler +A-libtest (I'm not sure what the correct team assignment for this is...)
The output capturing mechanism has code to try to prevent capturing output from a double-panic: But the panic message is actually written into a string first:
re your prev. comment That doesn't happen anymore, with rust 1.75.0, it seems to be a regression, all I get is what the shows, even with rust nightly with RUST_BACKTRACE on: so, no stack trace.

The actual double panic stacktrace is inside that from: <details<summaryclick me to expand contents </summarybut to get the above output, I had to use a rust patch: </detailsIs it a regression ? Or am I missing something here. How was it able to print the stacktrace before (back in 2022 when you made the comment) but now can't ?! EDIT: Also, this means, it doesn't get to execute a potential user-set panic hook. EDIT2: I've confirmed that indeed the stacktrace is shown with EDIT3: Regression found, curiously 1 year and 10 days later: EDIT4: first glance appears to be but I'll try to double check.
Yeah indeed, today even in this just prints which is pretty barren. Not sure if it would make sense to try and catch panics during message formatting, and then still print a backtrace but without a message, or so. That may be what ; I am not entirely sure.
Change:
extern crate libc; <del> // By default the Rust runtime resets SIGPIPE to SIG_DFL before exec:ing child </del> <ins> // By default the Rust runtime resets SIGPIPE to SIG_DFL before exec'ing child </ins> // processes so opt-out of that with `#[unix_sigpipe = "sig_dfl"]`. See // https://github.com/rust-lang/rust/blob/bf4de3a874753bbee3323081c8b0c133444fed2d/library/std/src/sys/pal/unix/process/process_unix.rs#L359-L384 #[unix_sigpipe = "sig_dfl"]

Discussion:
I checked out the master branch and ran and the test failed: this was on
I am having the same problem on aarch64-apple-darwin. cc this started with .
I can't reproduce this in a clean ubuntu container. Can you? If not, probably something specific about your environments is causing this? The test did pass bors, after all.
This is also happening in dev-desktop-us-, where would be easy to reproduce I guess.
I think it might be an issue with caching, perhaps of the aux-bins. The following should reliably reproduce it:
If I do this, the test goes from failing to passing: So yeah, looks like a problem with cache invalidation of something in that directory.
Thanks for the reproducer. This fixes it for me: The failure is because there is an old .so file lying around: ./build/x8664-unknown-linux-gnu/test/ui/attributes/unixsigpipe/unixsigpipe- It should use: ./build/x8664-unknown-linux-gnu/test/ui/attributes/unixsigpipe/unixsigpipe- By removing the old and obsolete file, the test passes.
Change:
#[unstable(feature = "str_internals", issue = "none")] pub use validations::next_code_point; <ins> #[unstable(feature = "str_internals", issue = "none")] pub use validations::utf8_char_width; </ins> use iter::MatchIndicesInternal; use iter::SplitInternal; use iter::{MatchesInternal, SplitNInternal};

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: Program does not panic. Instead, this happened: Program panics with the error . <!-- 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<p</p</detailsTo clarify: This problem occurs with all trait implementations that don't override the default implementation, e.g. with this simple DelegatingWrite:
I see two distinct possibilites to resolve this: 1) Treat incomplete s not ending on a codepoint boundary as a bug and fix that in the stdlib. Also clarify in the docs that indivual calls must be passed complete UTF-8 sequences if a Windows terminal is attached. 2) In the vain of "Be liberal in what you accept" handle incomplete UTF-8 passed in via calls appropriately, as long as the sequence is completed properly in the next call(s).
Hm, so this is ultimately a bug in the buffer uses? It attempts to write 1024 bytes but only 1023 bytes can written in the first OS call. It then has a leftover byte, which I guess it tries to write by itself thus causing this error?
The logic which errors if incomplete UTF-8 is passed in at index 0 is in the std lib at . That is where the error message comes from. As far as I can see the stdio buffer implementation (in stable, it is in , apparently currently being revamped) can not know of the requirement that only complete UTF-8 may be written to the underlying Windows terminal so I think that it should be encapsulated in by just accepting and buffering incomplete UTF-8 when necessary.
I mean, a generic buffer can attempt to avoid small writes (say, less than 16 bytes) by copying those left over bytes to the front of the buffer and waiting for either another to refill the buffer or a to empty it. But I see what you mean. Introducing a small buffer to windows/stdio would fix the problem.
Change:
<ins> trait Trait { type Gat<'a: 'b, 'b: 'c, 'c>: 'c; } fn get_func<'a, T: Trait>(_: &'a str) -> fn(T::Gat<'a, '_, 'static>) { loop {} } fn test<T: Trait>() { let func = get_func::<T>(&String::new()); //~ ERROR temporary value dropped drop(func); } fn main() {} </ins>

Discussion:
Check out ICU4X (tested on commit ), and build : However this started happening in our nightly CI since (one nightly before this one). The PR must have landed in the recent past. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Working on bisection, so far I have this
regressed commit: <detailsbash cargo bisect-rustc --start 2023-10-28 --end 2023-10-30 </details
Regression is , cc
Change:
<ins> // Copyright 2015 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. // Ensure that both `Box<Error + Send + Sync>` and `Box<Error>` can be obtained from `String`. use std::error::Error; fn main() { let _err1: Box<Error + Send + Sync> = From::from("test".to_string()); let _err2: Box<Error> = From::from("test".to_string()); let _err3: Box<Error + Send + Sync + 'static> = From::from("test"); let _err4: Box<Error> = From::from("test"); } </ins>

Discussion:
There's an implementation of that allows the conversion of a to a , but it doesn't quite work when just using . The (perhaps subtle) error message is due to the compiler attempting to use the general implementation for . I was trying to return string errors from a function returning and ended up writing the following: This works well, but is really just boilerplate and not obviously suited to inclusion in any crate or library. Other solutions I thought of include: Adding to the standard library for cases like this. Altering the semantics for trait-resolution on types that parametrise over multiple traits. From what I've read, we don't yet have semantics for general additions of traits, only built-in ones. See .
This is somewhat intentional on the side of being conservative, but it seems pretty harmless to add.
Change:
fn main() { f(&2); } <ins> // EMIT_MIR issue_78192.f.InstCombine.diff </ins>

Discussion:
Previously: Now: <!-- 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
Inlining exposes a use of unnormalized local in a call terminator (not sure if this is more of an issue with inlining or a validator): Note: revision annotation doesn't work in an auxiliary file (so it isn't tested on CI with mir-opt-level=2). modify labels: +A-mir-opt-inlining
This ICEs again because the fix was reverted Can someone reopen please?
Due to this new requires to trigger. <details<summaryICE:</summary</details
(FWIW can also trigger this: )
fixes this for and , but it still ICEs with on its own or with mir-opt-level 1/2 cc
Change:
<ins> #![deny(broken_intra_doc_links)] //! [static@u8::MIN] //~^ ERROR incompatible link kind </ins>

Discussion:
I tried this code: I expected to see this happen: Rustdoc links to Instead, this happened: Rustdoc gets confused that means a function and thinks that the link is a primitive. <!-- 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. --: Relevant code: I think the fix is just to add as a match guard. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is blocking and made unnecessarily difficult.
claim
which arm do you mean to add the match guard to?
the one for telling if the resolved item is a primitive:
It looks like is in fact for
Oh hmm - the issue is that for primitives, rustdoc generates the anchor manually: I would try storing the of the associated item in instead, so you know later whether the anchor is a manual link () or whether it was generated by rustdoc.
Adding in here and adding the match guard seems to fix things, but also feels like a hack.
I mean, all of is a hack because other parts of rustdoc break when you store the associated item instead: If you can figure out a way to get rid of it, I'd love to do that, but it will require some pretty major refactors I think.
Change:
} else if python2 { PYTHON2 } else { <del> // We would have returned early if we found that python is installed ... // maybe this should panic with an error instead? PYTHON </del> <ins> // Python was not found on path, so exit eprintln!("Unable to find python in your PATH. Please check it is installed."); process::exit(1); </ins> } }

Discussion:
I was playing with a dev server config and forgot to put python in , leading to a confusing error message: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Mentoring instructions: change src/tools/x to have a better error in this case. note you'll have to manually reinstall it once that's done; we don't currently have an upgrade path for that tool which is one of the reasons we're planning to use shell scripts in
claim
claim
Change:
/// `failure` describes the required ordering for the load operation that takes place when /// the comparison fails. Using [`Acquire`] as success ordering makes the store part /// of this operation [`Relaxed`], and using [`Release`] makes the successful load <del> /// [`Relaxed`]. The failure ordering can only be [`SeqCst`], [`Acquire`] or [`Relaxed`] /// and must be equivalent to or weaker than the success ordering. </del> <ins> /// [`Relaxed`]. The failure ordering can only be [`SeqCst`], [`Acquire`] or [`Relaxed`]. </ins> /// /// **Note:** This method is only available on platforms that support atomic /// operations on `u8`.

Discussion:
Currently requires the failure ordering to "be equivalent to or weaker than a success ordering". On the other hand C11/C++11 requires only that "failure shall be no stronger than the success", which arguably means that one can write e.g. in C/C++ but not in Rust. Arguably, because neither C11 standard nor C++11 standard defines what it means for an ordering to be stronger from another. When the issue was raised in [LWG2445], the proposed and accepted resolution was to lift those restrictions altogether, leaving only requirement that "the failure argument shall not be nor ". It would be beneficial to remove success/failure ordering restrictions for reasons described in C++ proposal [P0418r2]. [LWG2445]: [P0418r2]: EDIT: Restrictions were lifted in clang & LLVM:
Blocked on The cmpxchg release acquire is accepted by LLVM but miscompiled on AArch64.
I'm about to send a PR that implements this.
I do have implementation ready as well, but that's fine, I can review instead :-).
I split it in a PR that renames the intrinsics first, and a separate PR for exposing the new ordering combinations afterwards.
Looks like llvm 12 doesn't support this: Can we make things conditionally fall back to a stronger ordering depending on the llvm version? I don't think we do anything like that in the library right now, but maybe the compiler already does things differently for different llvm versions?
Ah yes, some code checks . I suppose Builder::atomic_cmpxchg could check the same, and upgrade the ordering if necessary in that case.
Did exactly that in
To do: [x] Add codegen test. [x] Publicly expose the new orderings. [x] Update memory order lint to accept the new orderings.
Change:
cargo.rustdocflag("ena=https://docs.rs/ena/latest/"); let mut to_open = None; <ins> if self.crates.is_empty() { self.crates = INTERNER.intern_list(vec!["rustc_driver".to_owned()]); }; </ins> for krate in &*self.crates { // Create all crate output directories first to make sure rustdoc uses // relative links.

Discussion:
title. I ran and nothing opened, cc (havent actually checked that PR caused this). still works <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
whoops yeah this is definitely my fault :sweatsmile: needs to be
claim
What is in this context? Looks like it wants a and "rustcdriver" doesn't seem to do the trick.
you might need to add a temporary binding in a higher scope so you can assign a String to it
That gives me a panic over at
does fix it?
It fixes the panic, but it doesn't fix the main issue (nothing opens).
ok, you'll have to figure out why that didn't work and what the proper fix is.
Ok, some more investigation: the builder wants to open which is "rust/build/x8664-unknown-linux-gnu/compiler-" but this file doesn't exist. builds that file, except under rustcmain, however. That's not much help. Is the idea behind your suggested fix, to compile rustcdriver if nothing else is provided, or to open the (assumedly compiled) docs if nothing else is provided? Currently in that function, . If the former is true, then the fix would be to check for if and pass the arg to cargo that way. If the latter is true, then there's a further bug in that isn't being compiled when it's supposed to be. Forgive the newcomer questions! If anyone wants to fix this before me, feel free - I see the prioritize label :)
If == [], that means we should build all the compiler crates. Maybe we need to add back the logic that was there before, to treat rustc_driver as the root? I guess since they're all part of the larger workspace doesn't do the right thing by default like it does elsewhere.
Just to be sure: It should open this? !
Change:
printf("Available features for this target:n"); for (auto &Feature : FeatTable) printf("    %-*s - %s.n", MaxFeatLen, Feature.Key, Feature.Desc); <ins> printf("nRust-specific features:n"); printf("    %-*s - %s.n", MaxFeatLen, "crt-static", "Enables libraries with C Run-time Libraries(CRT) to be statically linked" ); </ins> printf("n"); printf("Use +feature to enable a feature, or -feature to disable it.n"

Discussion:
despite it being usable in . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
hi there. Are you still working on this? :)
couldn't find the time to look into this deeper, sorry. Feel free to pick it up.
The target features for a particular architecture are taken from llvm in line 341. The seems to be a rust-specific target feature that is not present in llvm feature table, I think its the only one right now. I have made a basic naive pr which just prints it out since I'm hoping to get feedback for improving it
Change:
name = "compiletest" version = "0.0.0" dependencies = [ <ins> "colored", </ins> "diff", "getopts", "glob",

Discussion:
When running on Linux and a failure happens, a really nice diff of the output vs rustdoc-nightly is produced which very clearly shows the issue. This does not work on Windows for multiple reasons. One the call to fails: Second, the output from rustdoc-nightly seems to exactly match that from the local compiler making it not possible to do manual diffs.
How do you diff directories recursively on Windows? On Linux I would be very surprised for not to be installed. Oh I just thought of something - do you have a rustup overide that defaults to your local toolchain? Right now compiletest assumes the default is nightly, I've been meaning to change it.
No, I only set overrides on specific projects (and rust-lang/rust is not one of them). My default is the stable compiler.
Git for Windows provides : Are you building Rust using Git Bash prompt?
I don't think it'd be a good idea to require testing rustdoc in the Git for Windows bash shell. I'd like for this to work in and PowerShell if possible.
Change:
// We have to ignore android because of this issue: // https://github.com/rust-lang/rust/issues/74847 // ignore-android <ins> // // We need to use inline assembly, so just use one platform // only-x86_64 </ins> // compile-flags:-g

Discussion:
The test is failing on AArch64's CI:
ping arm
Hey ARM Group! This bug has been identified as a good "ARM candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Just like with every LLVM update it might fix itself or get worse after
The test is causing an infinite loop due to the link register being updated during the call to zzz, that call is causing the link register to be the ret instruction after that call, the ret instruction then returns to the link register causing an infinite loop. Normally before the call the link register would be saved and then restored after the call, however due to this being a naked function that isn't happening. The emitted LLVM IR is just calling the function and that call isn't preserving anything so this could change in a future version of LLVM I suppose. Although with c++ and clang that code would fail to compile as you can only use asm inside a naked function. suggests it's a bug in rustc for allowing the code to compile, is that still your understanding? I also suspect it's why this was raised. I can get the test to pass, but I'm wondering if the test is actually correct in it's current state. EDIT: It's probably worth pointing out that the code in that test will segfault on x86_64
The test is definitely incorrect. Using anything other than inline asm in a naked function is UB.
Change:
/// This struct is used to wrap the `cache` and `tcx` in order to run `DocFolder`. struct CacheBuilder<'a, 'tcx> { cache: &'a mut Cache, <ins> /// This field is used to prevent duplicated impl blocks. impl_ids: FxHashMap<DefId, FxHashSet<DefId>>, </ins> tcx: TyCtxt<'tcx>, }

Discussion:
! All pointing to the same impl: ! label +T-rustdoc
Actually, the never type , the trait and are not needed: It occurs with any type and any parameterized trait. Minimal reproducible example: The number of duplicates depends on the number of public types accessible in the target crate.
Taking a look.
code: Gives: !
Change:
extern crate test; #[cfg(test)] #[rustc_test_marker = "m_test"] <ins> #[doc(hidden)] </ins> pub const m_test: test::TestDescAndFn = test::TestDescAndFn { desc: test::TestDesc {

Discussion:
I tried this code: I expected to see this happen: no errors Instead, this happened: : Very likely to be related
Looks like allowed missing docs on the generated function, but didn't test having any actual s. cc
Attempt fix in
Change:
$p.token.span, ExprKind::Block(block, None), ThinVec::new() )); } <ins> // N.B: `NtIdent(ident)` is normalized to `Ident` in `fn bump`. </ins> _ => {}, }; }

Discussion:
The CI for started to fail today with this error: It appears as though the compiler doesn't see and only sees as the range expression and then generates this error. The expression is inside a expansion. You can reproduce this by cloning the repo and building it: The build succeeds on the stable channel and much older releases, so this appears to be a regression in the nightly. Here's the version on my windows system, but note that this also fails on linux and macos too:
Regression introduced in
More specifically the bug is in: which is called to see whether what follows is a valid start of a range pattern end expression. This is strange tho... in the case of e.g.: the call to in is used successfully to parse but somehow that doesn't work for . cc
Similarly, with: this does not trigger "error: range patterns are not supported" but it should.