jiebi/CodeConvo huggingface dataset:
Code change:
_ => self.is_free(), } } <ins> pub fn is_var(self) -> bool { matches!(self.kind(), ty::ReVar(_)) } </ins> } /// Type utilities

Related discussion:
text: Sorry, this is not necessarily the smallest possible example. Please let me know if this is unhelpful and I'll come up with something more concise. Given the following code: The output in current stable (1.63.0) is: (Please note the "expected closure with ... found closure with ..." hint.) From 1.64 onwards, the expected/found hint is omitted: To me the 1.63 behaviour is preferable to that from 1.64+ as it can often be non-obvious where the differences lie.
searched nightlies: from nightly-2022-06-01 to nightly-2022-08-11 regressed nightly: nightly-2022-07-23 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Looks like it was caused by , which is pretty big diagnostics PR in that rollup. cc
Of course I caused it.
label -E-needs-bisection
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Code change:
<ins> error: higher-ranked subtype error --> $DIR/issue-30906.rs:15:5 | LL |     test(Compose(f, |_| {})); |     ^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>

Related discussion:
text: Reproduction branch: When applying the change from the last commit I get a panic in my code during the call to . <details<summaryBacktrace</summary</details
Cannot reproduce on my linux. Can you provide a small ? Is that possible? Maybe without all the externals :/
I can reproduce a very similar problem (appears to involve the same origin and failing assertion of ) compiling rust-lang/regex with and compiler flags: For me, setting to 2 or greater is required to present this failure. <details<summarybacktrace</summary<code<preRUSTBACKTRACE=1 cargo build Compiling regex v1.1.2 (/home/kent/rust/regex) thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32', stack backtrace: 0: std::sys::unix::backtrace::tracing::imp::unwindbacktrace at 1: std::syscommon::backtrace::print at 2: std::panicking::defaulthook::{{closure}} at at 3: std::panicking::defaulthook at 4: rustc::util::common::panichook 5: std::panicking::rustpanicwithhook at 6: std::panicking::beginpanic 7: syntax::sourcemap::SourceMap::bytepostofilecharpos 8: syntax::sourcemap::SourceMap::lookupcharpos 9: <rustccodegenssa::mir::FunctionCx<'a, 'tcx, Bx::scopemetadataforloc 10: <rustccodegenssa::mir::FunctionCx<'a, 'tcx,
Code change:
<ins> error: higher-ranked subtype error --> $DIR/issue-30906.rs:15:5 | LL |     test(Compose(f, |_| {})); |     ^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>

Related discussion:
text: Bx::debugloc 11: rustccodegenssa::mir::codegenmir 12: rustccodegenssa::base::codegeninstance 13: rustccodegenssa::monoitem::MonoItemExt::define 14: rustccodegenllvm::base::compilecodegenunit::modulecodegen 15: rustc::depgraph::graph::DepGraph::withtask 16: rustccodegenllvm::base::compilecodegenunit 17: rustccodegenssa::base::codegencrate 18: <rustccodegenllvm::LlvmCodegenBackend as rustccodegenutils::codegenbackend::CodegenBackend::codegencrate 19: rustc::util::common::time 20: rustcdriver::driver::phase4codegen 21: rustcdriver::driver::compileinput::{{closure}} 22: <std::thread::local::LocalKey<T::with 23: rustc::ty::context::TyCtxt::createandenter 24: rustcdriver::driver::compileinput 25: rustcdriver::runcompilerwithpool 26: <scopedtls::ScopedKey<T::set 27: rustcdriver::runcompiler 28: syntax::withglobals 29: rustmaybecatchpanic at 30: <F as alloc::boxed::FnBox<A::callbox 31: std::sys::unix::thread::Thread::new::threadstart at at at 32: <unknown33: clone query stack during panic: end of query stack error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: rustc 1.34.0-nightly ( 2019-02-26) running on x86_64-unknown-linux-gnu note: compiler flags: -Z mir-opt-level=2 -C debuginfo=2 -C incremental --crate-type lib </pre</code</details
With the help of , I've found a tiny test that reproduces this crash on Linux and Mac:
Got another one: <details</detailsHappens when compiling regex tests with and calling on every span found in the mir of the functions needing codegen.
According to glaicer, the ICE from this example has been gone.
can you confirm that your example does not crash on nightly anymore?
Code change:
<ins> error: higher-ranked subtype error --> $DIR/issue-30906.rs:15:5 | LL |     test(Compose(f, |_| {})); |     ^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>

Related discussion:
text: Has been fixed in
is likely the part of the rollup fixing it.
Shouldn't a testcase be instead of closing this?
A similar crash that still happens:
Code change:
<ins> error: higher-ranked subtype error --> $DIR/issue-30906.rs:15:5 | LL |     test(Compose(f, |_| {})); |     ^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>

Related discussion:
text: I realize it's kinda nonsensical, but here:
Why didn't WF catch this?
That's because only checks statics/constants.
Still reproducible with .
This ought to be a mostly easy fix. The problem is that the well formedness check, which ought to be rejected this code, is ignoring things in an : They fall through to this `` case: We would need to add support for the HIR item: which in turn has a number of items: which are defined here: presumably we want the to check that the types of are well-formed, roughly analogous to how we current check normal static items: (We probably want similar checks on foreign item fns, though?) One tricky part might be compatibility, we may need to turn this into a compatibility lint in case there is lots of broken code in the wild.
I am trying to fix this bug, and need help moving forward. function is modified to accept a and a , yet it doesn't report any additional errors and the ICE prevails. Test file: Commit: Should I create a pull request or is it too early?
Looks like suggestions are incomplete ( does not require ). Also, I left a comment on your commit about how you can avoid adding . I suspect the only reason regular s are required to be is they have an initializer (and that, not the type, requires ), i.e. for we have these errors:
Oddly, the PR that were previously posted to fix this (PR , following on PR ) was subsequently closed as inactive ... but the bug itself seems like it may have been resolved in the meantime?
I'm going to assume this was fixed. Tagging as E-needstest, but if someone wants to take the time, it'd be even better to bisect to where this was fixed, and see if a regression test for this was at that time.
Compiler no longer panics, tested with
Code change:
fn expect_aborted(status: ExitStatus) { dbg!(status); let signal = status.signal().expect("expected child process to die of signal"); <ins> #[cfg(not(target_os = "android"))] </ins> assert!(signal == libc::SIGABRT || signal == libc::SIGILL || signal == libc::SIGTRAP); <ins> #[cfg(target_os = "android")] { // Android signals an abort() call with SIGSEGV at address 0xdeadbaad // See e.g. https://groups.google.com/g/android-ndk/c/laW1CJc7Icc assert!(signal == libc::SIGSEGV); // Additional checks performed: // 1. Find last tombstone (similar to coredump but in text format) from the //    same executable (path) as we are (must be because of usage of fork): //    This ensures that we look into the correct tombstone. // 2. Cause of crash is a SIGSEGV with address 0xdeadbaad. // 3. libc::abort call is in one of top two functions on callstack. // The last two steps distinguish between a normal SIGSEGV and one caused // by libc::abort. let this_exe = std::env::current_exe().unwrap().into_os_string().into_string().unwrap(); let exe_string = format!(">>> {this_exe} <<<"); let tombstone = (0..100) .map(|n| format!("/data/tombstones/tombstone_{n:02}")) .filter(|f| std::path::Path::new(&f).exists()) .map(|f| std::fs::read_to_string(&f).expect("Cannot read tombstone file")) .filter(|f| f.contains(&exe_string)) .last() .expect("no tombstone found"); println!("Content of tombstone:n{tombstone}"); assert!( tombstone.contains("signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadbaad") ); let abort_on_top = tombstone .lines() .skip_while(|l| !l.contains("backtrace:")) .skip(1) .take_while(|l| l.starts_with("    #")) .take(2) .any(|f| f.contains("/system/lib/libc.so (abort")); assert!(abort_on_top); } </ins> } fn main() {

Related discussion:
text: Instead of having UB, I think it would be fine to only check the number of overall current panics calls (as stored in ignoring ). If it is higher than 2, assume we have a recursion (results in false positives in case two or more threads panic at the same time). ==In case we have two panics going on in parallel by two threads there is the chance that we don't output , but it prevents UB. Also, when one thread calls it will often happen that the second thread will be killed soon and outputs nothing at all. In other cases (only one thread panics), there should be no difference. A change could look like that (high probability I've missed something!): This change passes all tests of for targets and QNX on AArch64.
Would you please try to test the fix above to check if it solves the issue on Android as well?
On most Unix it's UB to touch TLS after fork. Even if we have static TLS, accessing it might cause [^1] to be be called, and that function has paths where it allocates memory, takes locks, etc. That is, this is probably not a specific issue with QNX/Android. [^1]: At least on ELF, although I believe this is broadly true for Mach-O as well.
Code change:
use crate::TargetSelection; use crate::{t, VERSION}; <ins> use std::env::consts::EXE_SUFFIX; </ins> use std::fmt::Write as _; <del> use std::path::{Path, PathBuf}; </del> <ins> use std::fs::File; use std::path::{Path, PathBuf, MAIN_SEPARATOR}; </ins> use std::process::Command; use std::str::FromStr; use std::{

Related discussion:
text: I tried this code on a fresh git clone of rust-lang/rust: I expected to see this happen: setup works without errors. Instead, this happened: x.py gives an error: This feature was introduced in and worked at that time. do you have time to look into this? The original bug report was from Nazar Mokrynskyi , not sure their github username. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Yes, I'll take a look over the next few days.
Hello. Is there a workaround for this issue for now? I got But when I ran , I got .
OK. After reading the zulip thread, I figured out how to work around it. After running , succeeded.
claim
Code change:
<ins> // Regression test for #89469, where an extra non_snake_case warning was // reported for a shorthand field binding. // check-pass #![deny(non_snake_case)] #[allow(non_snake_case)] struct Entry { A: u16, a: u16 } fn foo() -> Entry {todo!()} pub fn f() { let Entry { A, a } = foo(); let _ = (A, a); } fn main() {} </ins>

Related discussion:
text: Here's a minimized version of the code I'm working with: Compiling this on stable or nightly gives a warning on the indicated line, despite the attribute on . A similar issue was reported before in , and addressed in a follow-up PR , but it seems to be cropping up again here, maybe because a non-ASCII field name is involved. It was agreed in that punning of non-snake-case fields in patterns should not produce an additional warning, so I think this is a bona fide bug. (Incidentally, on stable the same warning appears twice in the compiler output, but this duplication seems to be fixed on nightly.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It's actually unrelated to the non-ASCII field names; reduced: claim
Thanks
Code change:
<ins> error[E0283]: type annotations needed --> $DIR/issue-80816.rs:49:38 | LL |     let guard: Guard<Arc<usize>> = s.load(); |                                      ^^^^ | note: multiple `impl`s satisfying `ArcSwapAny<Arc<usize>>: Access<_>` found --> $DIR/issue-80816.rs:35:1 | LL | impl<T> Access<T> for ArcSwapAny<T> { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ... LL | impl<T> Access<T> for ArcSwapAny<Arc<T>> { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ note: required for `Arc<ArcSwapAny<Arc<usize>>>` to implement `Access<_>` --> $DIR/issue-80816.rs:31:45 | LL | impl<T, A: Access<T>, P: Deref<Target = A>> Access<T> for P { |                                             ^^^^^^^^^     ^ help: try using a fully qualified path to specify the expected types | LL |     let guard: Guard<Arc<usize>> = <Arc<ArcSwapAny<Arc<usize>>> as Access<T>>::load(&s); |                                    ++++++++++++++++++++++++++++++++++++++++++++++++++ ~ error: aborting due to previous error For more information about this error, try `rustc --explain E0283`. </ins>

Related discussion:
text: A code attached below used to compile with rustc 1.48 (stable) and stopped to work with 1.49 (stable). Two thing help to make the code compile: 1) comment out 2) explicitly deref . To compile code below one need to add to dependencies. Maybe this is due to some conflict between ArcSwap instance method and Access load method? I tried this code: I expected to see this happen: It should compile properly (it worked with rustc version 1.48 and earlier versions as well). Instead, this happened: I got compilation error It most recently worked on: Rust 1.48 :
searched nightlies: from nightly-2020-10-01 to nightly-2020-11-14 regressed nightly: nightly-2020-10-07 searched commits: from to regressed commit: () <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Assigning as discussed as part of the and removing .
:
The examples now print actionable feedback for the user, in the form of errors complaining about multiple applicable impl's. For example, the now prints: So I think this might just need a regression test. label: E-needs-test
Code change:
pub use self::stdio::set_output_capture; #[stable(feature = "rust1", since = "1.0.0")] pub use self::stdio::{stderr, stdin, stdout, Stderr, Stdin, Stdout}; <ins> #[unstable(feature = "stdio_locked", issue = "none")] pub use self::stdio::{stderr_locked, stdin_locked, stdout_locked}; </ins> #[stable(feature = "rust1", since = "1.0.0")] pub use self::stdio::{StderrLock, StdinLock, StdoutLock}; #[unstable(feature = "print_internals", issue = "none")]

Related discussion:
text: Given the following code: The current output is: I think it's typical for a newcomer to want to get a iterator by chaining method calls like . There's no obvious reason why that shouldn't work. The examples in the documentation do typically show being assigned to a variable prior to calling its method, but don't explain why that's necessary. I think the "borrow" terminology is misleading, but there might not be a concise way to describe what's actually going on to the user. The "temporary value is freed at the end of this statement" is probably correct. The "creates a temporary which is freed while still in use" is probably more correctly "creates a temporary that is required to outlive (or live exactly as long as) the result of...", followed by a pointer to the method invocation, with text of " method call". Maybe it should also point out the lifetime argument in the return type. I tried and failed to find a satisfactory explanation of what exactly was borrowing from the temporary value produced by . When I looked through the library source code, the only references in were those created by locking a , and the in question is static. I'm guessing the existence of a borrow is assumed rather than inferred from analyzing the function body of . The assumption might be the result of the anonymous lifetime argument on the output type from , which imposes a requirement that the doesn't outlive (or has the same lifetime as?) the value that is the receiver of . The correct fix might be to change the locked stdin handles to all use lifetimes, but I will probably file that as a separate issue.
label +A-borrow-checker +A-lifetimes +D-confusing +D-incorrect +D-newcomer-roadblock
IMO the intent is clear here. Without changing the API, why exactly is Rust unable to lift 'a &'static X to 'static & 'static X, if X also contains only 'static lifetimes? I don't think raw references have a meaningful dropper; borrowck is able to freely resolve any derived lifetimes on impls that don't depend on anything else to 'static; I'm pretty sure under current rules we should be able to substitute latter for earlier and get exactly the same behaviour.
This is due to .
Code change:
pub use self::stdio::set_output_capture; #[stable(feature = "rust1", since = "1.0.0")] pub use self::stdio::{stderr, stdin, stdout, Stderr, Stdin, Stdout}; <ins> #[unstable(feature = "stdio_locked", issue = "none")] pub use self::stdio::{stderr_locked, stdin_locked, stdout_locked}; </ins> #[stable(feature = "rust1", since = "1.0.0")] pub use self::stdio::{StderrLock, StdinLock, StdoutLock}; #[unstable(feature = "print_internals", issue = "none")]

Related discussion:
text: is declared as follows: Because there is only one input lifetime (the elided lifetime of ), it is assigned to the output lifetime , which is why the lock can live at most as long as the temporary.
Thanks. I think this might be a bug in libstd (using instead of as the return type), but I'll file that separately. What I think is a diagnostic inaccuracy is that the error message refers to a borrow, when, by inspection of the library source code, no borrow is taking place in . (Unless I'm missing something?) What I think is happening is that the compiler is enforcing that lives no longer than the temporary produced by , and is misleadingly calling that a borrow in the error message.
As a simplified example: The error message refers to a borrow even when the output type of does not refer to at all!
that's because of the elision rules: on the declaration you're implicitly telling the compiler that the lifetime of the borrow matches the lifetime of the type. .
Thanks. I think the error messages could use a little more detail about how something that the borrow checker sees as a borrow may be an artifact of lifetime constraints in a function signature rather than an actual borrow in the function body. It certainly surprised me the first time I ran into it. (Maybe only in the explanatory text in the compiler error index. It looks like E0597 could also benefit from that detail, because it's a similar case, and an example in E0716 produces E0597.)
Shorter example, probably better suited for an example in the compiler error index:
Code change:
} } } <del> hir::ItemKind::Macro(ref macro_def) => { self.update_reachability_from_macro(item.def_id, macro_def); } </del> // Visit everything, but foreign items have their own levels. hir::ItemKind::ForeignMod { items, .. } => { for foreign_item in items {

Related discussion:
text: EDIT (ehuss) Reproduction: Clone <!-- 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 --
We are seeing this too on rustc 1.60.0-nightly ( 2022-01-10) running on aarch64-apple-darwin
label +I-prioritize
cc This seems to have regressed starting with .
I'm taking a look
I can reproduce and I did find some differences in the access level table. seems to be missing when it's supposed to be Reachable in the good version. I'll investigate further Updates: Actually, the whole Impl seems to be missing. It should be marked as Reachable but is not even there. claim
Marking as , as .
Same on Mac, on x86_64-apple-darwin as well, same toolchain version (rustc 1.60.0-nightly ( 2022-01-10))
As an update for those watching: currently, the best workaround is to use an older nightly. The good news is that a fix PR is open (), with people working on getting it in shape to be merged.
Code change:
}).peekable(); if let doctree::Plain = s.struct_type { if fields.peek().is_some() { <del> write!(w, "<h2 id='fields' class='fields'>Fields</h2>")?; </del> <ins> write!(w, "<h2 id='fields' class='fields section-header'> <a href='#fields'>Fields</a></h2>")?; </ins> for (field, ty) in fields { let id = derive_id(format!("{}.{}", ItemType::StructField,

Related discussion:
text: A page like has many things that could be useful to link to. These should be possible to link to by clicking on: [x] The header [x] 's on a page. [x] at the top On it's hit or miss: [x] Examples [x] Associated Types [x] Required Methods [x] Implementors On [x] Provided Methods I don't have any big use cases but when I want to link to these for something like this bug I can't link to any specific line. I gotta say go to vec page, scroll 75% to bottom. Squint hard to see it.
Just ran into this today; I'd really like to have links from the impls in the Implementors section to the source containing the impl.
Triage: we always need more links....
Update: Headers written in docs and (most) auto-generated headers are either fully hyperlinked or have a "section marker" symbol that shows up on hover. Major auto-generated page headers have links in the top of the sidebar of the page. Impl blocks do not have hyperlinks (yet); that's
Since got merged and closed out , that was the last major request on this issue, so i'll close this out. If you think of something else that needs a hyperlinked header, feel free to open a new issue or reopen this one.
Code change:
<ins> // Regression test for #84632: Recursion limit is ignored // for builtin macros that eagerly expands. #![recursion_limit = "15"] macro_rules! a { () => (""); (A) => (concat!("", a!())); (A, $($A:ident),*) => (concat!("", a!($($A),*))) //~^ ERROR recursion limit reached //~| HELP consider adding } fn main() { a!(A, A, A, A, A); a!(A, A, A, A, A, A, A, A, A, A, A); } </ins>

Related discussion:
text: I tried this code: I expected to see this happen: An error message about exceeding some recursion limit Instead, this happened: Tested on stable 1.51.0 + <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Note that the crash also occurs without . Based on testing with Godbolt, this doesn't seem to be a regression, or at least not a recent one.
Assigning as part of the prioritization working group discussion and removing . modify labels -I-prioritize +P-medium
Issue might be in this line: Calls , which then calls : And sets to , which would result in stack overflow because the recursion limit is never reached.
claim
Bug is confusing to track down, so I am no longer working on this. For people who are interested, here is the log when the loop is encountered: release-assignment
The issue is part of a bigger problem, that seems to ignore the recursion limit. This snippet below compiles successfully instead of reporting an error:
Seems to be a regression between and by testing on Godbolt. I suspect from caused the regression, but I'm not sure. label regression-untriaged