jiebi/CodeConvo huggingface dataset:
Change:
hir::Node::Item(item) => match item.kind { hir::ItemKind::Fn(_, _, owner_id) => tcx.hir().span(owner_id.hir_id), _ => { <del> bug!("Drop location span error: need to handle more ItemKind {:?}", item.kind); </del> <ins> bug!("Drop location span error: need to handle more ItemKind '{:?}'", item.kind); </ins> } }, hir::Node::Block(block) => tcx.hir().span(block.hir_id), <ins> hir::Node::TraitItem(item) => tcx.hir().span(item.hir_id()), hir::Node::ImplItem(item) => tcx.hir().span(item.hir_id()), </ins> _ => { <del> bug!("Drop location span error: need to handle more Node {:?}", owner_node); </del> <ins> bug!("Drop location span error: need to handle more Node '{:?}'", owner_node); </ins> } }; tcx.sess.source_map().end_point(owner_span)

Discussion:
Works even with calling just - no need for a project, and does not need as a dependency in . Bug exists on 1.59, 1.60, beta and nightly. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Do you have a codebase that can be shared instead? Unfortunately, it's kinda difficult to investigate this without seeing what triggered the ICE.
might be a duplicate of
I tried my hands at minimizing this, and it turned out way easier than I thought. Updated the original comment with reproduction code.
I subscribed to this thread for curiosity about ICEs on . Here's a smaller crashing program using
Managed to minimize it more:
you might be right, especially after I narrowed down the reproduction code.

<!-- 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. --code reduced from <!-- 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
another example: `
Change:
- [Documentation tests](documentation-tests.md) - [Linking to items by name](linking-to-items-by-name.md) - [Lints](lints.md) <del> - [Passes](passes.md) </del> - [Advanced features](advanced-features.md) - [Unstable features](unstable-features.md) <ins> - [Passes](passes.md) </ins> - [References](references.md)

Discussion:
From So not sure which way seems better? What do you think ?
Yeah I think we should document the new stuff and remove the docs for the deprecated stuff (perhaps mention that these deprecated features exist, but not document them in depth)
I've felt confused about this before: Why do we even let people customize which passes are run? That seems like unnecessary entanglement with rustdoc internals.
Also, there doesn't seem to be a flag. Are you thinking of ? If so, rustdoc says that's deprecated. Edit: It looks like is deprecated as well.
What is "the new stuff"? Do you mean things like ? Other than my confusion about that, I agree with Manish here. I think we should mention the deprecated features, but not document them extensively since they shouldn't be used anyway. If we extensively document deprecated features, we are wasting our time and our readers' time.
Yes. I do think the pass infra should stay mostly internal, with specific options being exposed via specific attributes. How we construct it internally should not be something the user should ever have to care about.
Change:
Rls, "src/tools/rls", "rls", stable=true, tool_std=true; RustDemangler, "src/tools/rust-demangler", "rust-demangler", stable=false, tool_std=true; Rustfmt, "src/tools/rustfmt", "rustfmt", stable=true, add_bins_to_sysroot = ["rustfmt", "cargo-fmt"]; <del> LlvmBitcodeLinker, "src/tools/llvm-bitcode-linker", "llvm-bitcode-linker", stable=false, add_bins_to_sysroot = ["llvm-bitcode-linker"]; </del> ); impl<'a> Builder<'a> {

Discussion:
The , which is enabled by default in the config, is recompiled everytime I try to run tests: The recompilation also causes further recompilation of (if I disable the bitcode linker, rustdoc is not recompiled).
cc
Oh, that's not good. Thanks for reporting. I will look at it tomorrow.
I have tracked it down to this . If I comment out that code it wont trigger the recompilation. From the documentation of ensure it say Also the definition of is done with the macro. That makes me think that it's related to something like the invalidating the caching. I'm currently exploring that a bit further.
The stuff above seems to work fine as building the (without rustdoc) works fine. The problem seems to be that and breaks the cache for each other. I suspect that means something is off in feature resolution between those modules.
I now know what the problem is. I will need some help to figure out the correct way to solve it. uses a very specifc cargo invocation which manually sets if a parallell compilation can be used. This causes common dependencies between the LLVM bitcode linker and Rustdoc to be rebuilt when one is called after the other. Since Rustdoc builds the bitcode linker (presumably through the step) this will always happen when is built. Is it correct/ethical of rustdoc to set like this? Or should rustflags be handled more centrally so every cargo invocation will end up with the same set of rustflags and this cache invalidation cannot occur? If it is important for rustdoc to use its own set of rustflags, should it then use a different build directory to other tools/steps using cargo?
I see that this in . Maybe she knows more about this?
We can't have same set of rustflags for every , in most cases we want the opposite; setting step specific rustflags. What about adding to tool?
That seems to work well in the scenario described above and in other scenarios I tested for. I think I just imagined that this was more frequently occurring problem if all tools share build folder and are able to set rustflags separately and adding this to would cause a conflict with something else (which it doesn't seem to do). Anyway, as this at least is fixing the apparent issue I'm creating a MR with this solution now
Change:
use rustc_hir as hir; use rustc_index::vec::Idx; use rustc_middle::ty::layout::{LayoutError, SizeSkeleton}; <del> use rustc_middle::ty::{self, Ty, TyCtxt}; </del> <ins> use rustc_middle::ty::{self, Ty, TyCtxt, TypeVisitable}; </ins> use rustc_target::abi::{Pointer, VariantIdx}; use super::FnCtxt;

Discussion:
Found with a <details<summaryBacktrace</summary</details<details<summaryBacktrace</summary</detailsRegression in nightly-2022-05-28, perhaps from () nightly: 2022-11-18 on playground with debug assertions: slightly newer, built locally from <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Might be a duplicate of
Should be an easy fix, just need to delay a bug if the transmute source/target has (non-region) infer vars and bail from the fn.
claim
Change:
}; could_refer_to(DefKind::Variant, variant_def_id, ""); <del> could_refer_to(kind, item.def_id, " also"); </del> <ins> could_refer_to(DefKind::AssocTy, assoc_ty_did, " also"); </ins> lint.span_suggestion( span,

Discussion:
In the following code, I can successfully refer to the private inherent associated type : I expected to see an error denying the access. If the associated item was a constant, this would indeed be the case: : label T-compiler requires-nightly A-associated-items A-visibility F-inherentassociatedtypes <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
} } <del> #[derive(Debug)] </del> struct ProhibitOpaqueVisitor<'tcx> { opaque_identity_ty: Ty<'tcx>, generics: &'tcx ty::Generics, <ins> tcx: TyCtxt<'tcx>, selftys: Vec<(Span, Option<String>)>, </ins> } impl<'tcx> ty::fold::TypeVisitor<'tcx> for ProhibitOpaqueVisitor<'tcx> {

Discussion:
Following the improvement for the diagnostic of the error reported in this issue , it would be nice (depending on how is prioritized) to have the same error message when instead of returning the function returns . When is returned I get a nice error message (on rustc 1.47): But if is used I get: with no suggestion to spell the type.
remove-assignment feel free to re-claim if you are working on this.
Change:
return; } let trait_ref = trait_predicate.to_poly_trait_ref(); <del> let (post_message, pre_message, type_def) = self </del> <ins> let (post_message, pre_message, type_def, file_note) = self </ins> .get_parent_trait_ref(obligation.cause.code()) .map(|(t, s)| { <ins> let (t, file) = self.tcx.short_ty_string(t); </ins> ( format!(" in `{t}`"), format!("within `{t}`, "), s.map(|s| (format!("within this `{t}`"), s)), <ins> file.map(|file| format!( "the full trait has been written to '{}'", file.display(), )) </ins> ) }) .unwrap_or_default();

Discussion:
Type errors (and others) use and similar to write types that are too long to disk, so the cli output is easier to read. Trait bound errors do not do that. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I created . What was not visible in the tweet but that you will see when you build the repo, is that the types in the error notes are even longer. That's a shame because hidden in that noise the compiler gives the solution to the error (pin).
You can just create a gist with the error generating logic line highlighted. Much more helpful?
I can give more context too. I was implementing a K8s operator using . I start by creating a and then running it with . This returns a . That stream yields an item every time the reconcile loops reconciles an item or returns an error. For testing, I iterate over the stream to check that it reconciles items the way I expect. . The solution is to pin the stream returned by .
how would i go about solving this? claim
you can look at how we do it here You have to do the same thing but at the very least in the places we print out types to string here:
You also need to ensure that the type-shortening is conditional, based on whether the user wants verbose output or not (similar to the existing logic for type errors).
already checks whether is enabled or not before shortening.
into: by the looks: is the same as and i can call the method on it, but in the formatting (that returns a tuple) im not sure how to call those functions (as t is a string, and calling the function returns a string and pathbuf. in the closure should i just ignore ? or is that a bad approach?
Change:
relative_from: Some("bar") ); <ins> tc!("foo/bar", "foobar", eq: false, starts_with: false, ends_with: false, relative_from: None ); </ins> tc!("foo/bar/baz", "foo/bar", eq: false, starts_with: true,

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 : I expected to see this happen: Different hashes since these represent different paths. Instead, this happened: The hashes are equal. This makes sense for redundant path separators (e.g. ), but not for all path separators. I a test case to the standard library — which fails. The relevant code is probably around which last changed in If I revert that commit, the error persists. It looks like the relevant change is , if I revert that commit the test passes. This was the solution I opted for downstream (in ) before performing this investigation. I tested this on stable (1.79.0), nightly (1.81.0), and on (). Discovered via
is not a cryptographic hash, so it does not promise a collision probability so low that practically all inputs map to distinct outputs. So if the correctness of your program relies on the absence of collisions then it's your program that's wrong, not . There may be some quality-of-implementation argument about avoiding collisions for data patterns that are likely to coexist. I'm not sure if it is the case here, I'll have to think about it. And even if it is then there also is the matter of making such a avoidance fast. The current code is optimized for speed.
I think that's a fair point, but the current implementation already goes out if its way to create equal hashes for paths like and — why is and different? It seems like a very surprising collision for a user to encounter. Thanks for taking a look!
The difference is that is a companion for . If things compare equal then they must hash the same because that's what hashmaps rely on. and do compare equally because normalizes the dot away. Therefore they must hash equally, which is why Hash must spend effort on that. Things comparing inequal does not require the Hash to be different. Instead it's only a matter of quality-of-implementation whether they produce distinct hashes, not a matter of correctness.
That's a great point, thanks for clarifying. I agree this is not a "correctness" problem, but more of a practical consideration for the hashing algorithm.
Change:
let fm = cm.new_filemap("blork.rs".to_string(), "first line.nsecond line".to_string()); fm.next_line(BytePos(0)); <del> assert_eq!(&fm.get_line(0),&"first line.".to_string()); </del> <ins> assert_eq!(fm.get_line(0), Some("first line.".to_string())); </ins> // TESTING BROKEN BEHAVIOR: fm.next_line(BytePos(10)); <del> assert_eq!(&fm.get_line(1), &".".to_string()); </del> <ins> assert_eq!(fm.get_line(1), Some(".".to_string())); </ins> } #[test]

Discussion:
When trying to build with I'm getting
Is there a temporary workaround? Thanks!
Most likely change the occurrences of (or ) to . Like .
I just tripped over this ICE in serde. I love c-reduce. It came up with the following code that reproduces the bug by reducing 203K down to this in 15 minutes: Here's the error:
Change:
LLVM version: 3.9 ``` <del> ## `-r`/`--input-format`: input format This flag is currently ignored; the idea is that `rustdoc` would support various input formats, and you could specify them via this flag. Rustdoc only supports Rust source code and Markdown input formats. If the file ends in `.md` or `.markdown`, `rustdoc` treats it as a Markdown file. Otherwise, it assumes that the input file is Rust. ## `-w`/`--output-format`: output format This flag is currently ignored; the idea is that `rustdoc` would support various output formats, and you could specify them via this flag. Rustdoc only supports HTML output, and so this flag is redundant today. </del> ## `-o`/`--output`: output path Using this flag looks like this:

Discussion:
From So not sure which way seems better? What do you think ?
Yeah I think we should document the new stuff and remove the docs for the deprecated stuff (perhaps mention that these deprecated features exist, but not document them in depth)
I've felt confused about this before: Why do we even let people customize which passes are run? That seems like unnecessary entanglement with rustdoc internals.
Also, there doesn't seem to be a flag. Are you thinking of ? If so, rustdoc says that's deprecated. Edit: It looks like is deprecated as well.
What is "the new stuff"? Do you mean things like ? Other than my confusion about that, I agree with Manish here. I think we should mention the deprecated features, but not document them extensively since they shouldn't be used anyway. If we extensively document deprecated features, we are wasting our time and our readers' time.
Yes. I do think the pass infra should stay mostly internal, with specific options being exposed via specific attributes. How we construct it internally should not be something the user should ever have to care about.
Change:
= note: see issue #37854 <https://github.com/rust-lang/rust/issues/37854> for more information = help: add `#![feature(exclusive_range_pattern)]` to the crate attributes to enable = note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date <ins> = help: use an inclusive range pattern, like N..=M </ins> error: aborting due to 4 previous errors

Discussion:
Came across this when a beginner was very confused about what was wrong with their ; the words "is experimental" and the link to the issue was not sufficient for their discovering what the problem/solution was. The suggested inclusive range pattern doesn't need to contain the actual matching value if producing it is hard or impossible, printing something like is still better than nothing. This issue may of course be ignored/closed if this nightly feature is just about ready to be stabilized or something. No response label +D-terse +C-enhancement +F-exclusiverangepattern <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<ins> // regression test for issue #121649. trait ToUnit<'a> { type Unit; } trait Overlap<T> {} type Assoc<'a, T> = <T as ToUnit<'a>>::Unit; impl<T> Overlap<T> for T {} impl<T> Overlap<for<'a> fn(&'a (), Assoc<'a, T>)> for T {} //~^ ERROR 13:17: 13:49: the trait bound `for<'a> T: ToUnit<'a>` is not satisfied [E0277] //~| ERROR 13:36: 13:48: the trait bound `for<'a> T: ToUnit<'a>` is not satisfied [E0277] fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '-Znext-solver=coherence -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'assertion failed: obligations.isempty()'', 'thread 'rustc' panicked at 'assertion failed: obligations.isempty()'' File: --auto-reduced (treereduce-rust): original: Version 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: [specializationgraphof] building specialization graph of trait [coherent_trait] coherence checking all impls of trait [analysis] running analysis passes on this crate --
cc
Probably due to the fact that doesn't preserve the flag.
should be fixed by
With the output is ...
should add the following as a test
Hello, I'm a beginner and I would like to contribute to Rust. Since this issue has been marked as "Easy," what is the desired behavior of this program and how can I approach it? Any help would be appreciated.
This is marked E-needs-test, so the only change here would be to add this test to the test suite, since the issue has been fixed.
Change:
use rustc_middle::hir::map::Map; use rustc_middle::hir::nested_filter; use rustc_middle::ty::TyCtxt; <ins> use rustc_parse::maybe_new_parser_from_source_str; use rustc_parse::parser::attr::InnerAttrPolicy; </ins> use rustc_session::config::{self, CrateType, ErrorOutputType}; <ins> use rustc_session::parse::ParseSess; </ins> use rustc_session::{lint, DiagnosticOutput, Session}; use rustc_span::edition::Edition; use rustc_span::source_map::SourceMap;

Discussion:
With following doctest, where the cfg attribute spans multiple lines, the final program is invalid: the wrapping method doesn't take into account the dangling line that closes the attribute. rust /// # #![cfgattr(not(dox), feature(cfgtargetfeature, targetfeature, /// # stdsimd))] /// /// fn foo() { /// let mut dst = [0]; /// addquickly(&[1], &[2], &mut dst); /// asserteq!(dst[0], 3); /// } ///
cc
cc
I don't see a message associated with the stack trace, is that missing?
The problem lies in how rustdoc parses doctests. It scans lines for crate-level attributes and statements, but it doesn't do anything more intelligent than checking the beginning of each line: We recently changed the parsing for and detection to use the libsyntax parser, but this initial scan is still a string-based search. The way to fix the test in the OP is to actually remove the part of it - rustdoc doesn't pass on any information into doctest compilation, so those features are going to be enabled regardless.
This is the associated message:
Change:
[[package]] name = "backtrace-sys" <del> version = "0.1.35" </del> <ins> version = "0.1.36" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "7de8aba10a69c8e8d7622c5710229485ec32e9d55fdad160ea559c086fdcd118" </del> <ins> checksum = "78848718ee1255a2485d1309ad9cdecfc2e7d0362dd11c6829364c6b35ae1bc7" </ins> dependencies = [ "cc", "compiler_builtins",

Discussion:
I'm running macOS 10.15.3. Starting in the 3/26 nightly, running applications and tests that panic with RUST_BACKTRACE=1 frequently results in a segfault: The backtrace from this shows libbacktrace: Since merged as part of which merged on March 25, there's a pretty clear candidate for the regression.
I found this as part of Servo's unit test suite, which now has intermittent segfaults in #[should_panic] tests on CI with nightlies since 3/26. I've also reproduced this by adding a panic!() in , but I haven't yet been able to create a standalone unit test that demonstrates the issue.
It looks like the code that is crashing was introduced as part of , which was brought in as part of the submodule update in
Here's a standalone testcase that reproduces the problem for me:
I have a suspicion that my testcase only works because of right now.
Can you open an issue on ?
Filed
reports that pulling in an updated backtrace-rs to rustc should fix this.
I think I am getting this on a stable rustc 1.44.0 ( 2020-06-01) on macOS 10.15.5. Initially, I caught a segfault for a test code that panics. when I tried to launch the same code under lldd it panicked properly (I tried a dozen of times). Then, another test run has led to a stall. /usr/bin/sample for the process showed this: which led me to this issue.
I think the fix for this isn't in 1.44, it should be in 1.45, though. Can you test to see if the issue is fixed on beta?
I tried to rebuild and re-run the test and I couldn't reproduce this issue again with beta!