jiebi/CodeConvo huggingface dataset:
Change:
use rustc_ast::expand::allocator::AllocatorKind; use rustc_data_structures::svh::Svh; use rustc_data_structures::sync::{self, MetadataRef}; <ins> use rustc_hir::def::DefKind; </ins> use rustc_hir::def_id::{CrateNum, DefId, LOCAL_CRATE}; use rustc_hir::definitions::{DefKey, DefPath, DefPathHash}; use rustc_macros::HashStable;

Discussion:
Found in the crater run: ICEs: ` This ICE happens on: but only shows a compiler error.
Assigning as and removing .
This is because an integration gets checked, which relies on the feature to be enabled. Once it is enabled, does not fail anymore, and yet the ICE persists . I'll thus kindly ask for this to be "re-prioritized", if possible, thanks. modify labels: +I-prioritize
Assigning and removing as in the prioritization working group.
ping cleanup This needs mcve and bisection
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking 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
searched nightlies: from nightly-2020-07-20 to nightly-2020-08-25 regressed nightly: nightly-2020-07-28 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summary
Minimized:
Change:
<ins> // Tests that HRTBs are correctly accepted -- https://github.com/rust-lang/rust/issues/50301 // check-pass trait Trait where for<'a> &'a Self::IntoIter: IntoIterator<Item = u32>, { type IntoIter; fn get(&self) -> Self::IntoIter; } struct Impl(Vec<u32>); impl Trait for Impl { type IntoIter = ImplIntoIter; fn get(&self) -> Self::IntoIter { ImplIntoIter(self.0.clone()) } } struct ImplIntoIter(Vec<u32>); impl<'a> IntoIterator for &'a ImplIntoIter { type Item = <Self::IntoIter as Iterator>::Item; type IntoIter = std::iter::Cloned<std::slice::Iter<'a, u32>>; fn into_iter(self) -> Self::IntoIter { (&self.0).into_iter().cloned() } } fn main() { } </ins>

Discussion:
(Sorry about the non-informative title, I couldn't come up with a useful description.) As discovered towards the end of , the following code () fails to compile: I get the following error message: Changing the definition of to makes the program compile, but it seems like it should be accepted as it is.
This program is no longer rejected, neither in 1.36, nor in nightly-2019-08-07.
modify labels: E-needstest
Change:
CompareImplMethodObligation, } <del> #[derive(Clone)] </del> <ins> #[derive(Clone, PartialEq, Eq)] </ins> pub struct DerivedObligationCause<'tcx> { /// The trait reference of the parent obligation that led to the /// current obligation. Note that only trait obligations lead to

Discussion:
That's a mouthful! To exemplify: This doesn't compile with , even though it does without it. Note that the only difference between the two configurations is that the function on is a free function instead of a default method. With , this fails with: Tested on
cc me
I've been running into very similar errors all day while updating my libs to the latest nightly. Here's an example of a method that works fine along with one that does not (simplest example I could come up with).
This example works now. I think this was a dup of
I just updated to master and I'm still running into the same error - perhaps my error is a separate issue?
Edwardw's PR does seem to fix my issue however, perhaps it addresses something extra?
The original issue is still present if the example on the first post is compiled with . I tested on , which contains Edit: just compiled . Still reproducible
Change:
<ins> error: constant expression depends on a generic parameter --> $DIR/issue-72819-generic-in-const-eval.rs:7:47 | LL | where Assert::<{N < usize::max_value() / 2}>: IsTrue, |                                               ^^^^^^ | = note: this may fail depending on what value the parameter takes error: aborting due to previous error </ins>

Discussion:
Amusingly the following ICEs while has a compiler error that hints at the const generic actually getting resolved. () Errors:
Also happens on stable without the feature gate
Triage: This is no longer ICE and emits an error correctly by . Marking as E-needs-test.
Change:
<ins> // compile-flags: --extern zip=whatever.rlib #![deny(broken_intra_doc_links)] /// See [zip] crate. //~^ ERROR unresolved pub struct ArrayZip; </ins>

Discussion:
I'm running via on a small project with multiple crates via the workspaces feature, and I get the following error (I've sanitized the paths, project name and dependencies): ~ It always fails with random external dependencies or crates that are part of the workspace. It does succeed however for a crate without any dependencies. I've tried with Rust 1.43.0 and 1.43.1, on openSUSE Tumbleweed Linux, both from the distributions repository () and (). I've also tried with latest nightly with the same outcome. : ~ <details<summaryBacktrace</summary<p~ </p</details
I've tried to create a minimal example that would trigger the issue but failed to do so... Perhaps one of my dependencies generates the issue? (However in my workspace I also have one crate that depends only on another internal one (which itself has no further dependencies) and it still fails.) I'm willing to experiment if someone gives me some pointers!
OK, I've found the issue: create two libraries and , with nothing more than an edition 2018 and an empty as their code; make them part of the same workspace; make depend on ; add a in (the library that depends on ); At the following link there is a simple project that rebuilds all of the above: succeeds, meanwhile fails with the aforementioned error. It appears that by just adding (after the no implicit import prelude) is enough to make the documentation build. A second solution would be to add after the no import prelude annotation.
Possibly related to
Regression in nightly-2019-11-15 Most likely caused by <details<summaryFull bisection </summary</detailsThis also means you can't document librustdoc. <details<summaryBacktrace </summary</details
the cause is already known: But I don't know why you say librustdoc can't be documented, it's right here on the site: Make sure you're passing , it's stage 0 by default.
oh look, I knew I'd seen this bug before, apparently I just forgot. The fix for this is to turn the into a .
Change:
cargo.arg("--all-targets"); } <del> // Enable internal lints for clippy and rustdoc // NOTE: this doesn't enable lints for any other tools unless they explicitly add `#![warn(rustc::internal)]` // See https://github.com/rust-lang/rust/pull/80573#issuecomment-754010776 cargo.rustflag("-Zunstable-options"); </del> let _guard = builder.msg_check(&concat!(stringify!($name), " artifacts").to_lowercase(), target); run_cargo( builder,

Discussion:
When working on Miri I noticed "portable-atomics" gets rebuilt every time I switch between a check-build and actutally running tests. This boils down to being different between the two invocations: in check builds it contains but in test builds it does not. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Cc
HEAD: ! Seems working fine here.
I'll have to try if I can till reproduce. But note that I mentioned "test build" above, so this would be vs .
Yeah I can still reproduce the problems with those invocations. (It's not the latest master but recent enough: .) Sorry for not giving the exact commands in the issue description.
I missed the tests part, sorry. I just reproduce it too. I will be working on it by the coming week. claim
Change:
<del> #![feature(const_generics)] #![crate_name = "foo"] // ignore-tidy-linelength pub enum Order { Sorted, Unsorted, } // @has foo/struct.VSet.html '//pre[@class="rust struct"]' 'pub struct VSet<T, const ORDER: Order>' // @has foo/struct.VSet.html '//h3[@id="impl-Send"]/code' 'impl<const ORDER: Order, T> Send for VSet<T, ORDER>' // @has foo/struct.VSet.html '//h3[@id="impl-Sync"]/code' 'impl<const ORDER: Order, T> Sync for VSet<T, ORDER>' pub struct VSet<T, const ORDER: Order> { inner: Vec<T>, } // @has foo/struct.VSet.html '//h3[@id="impl"]/code' 'impl<T> VSet<T, { Order::Sorted }>' impl <T> VSet<T, {Order::Sorted}> { pub fn new() -> Self { Self { inner: Vec::new() } } } // @has foo/struct.VSet.html '//h3[@id="impl-1"]/code' 'impl<T> VSet<T, { Order::Unsorted }>' impl <T> VSet<T, {Order::Unsorted}> { pub fn new() -> Self { Self { inner: Vec::new() } } } </del>

Discussion:
When playing around with const generics, I found some weird generated docs: How to reproduce: and go to the documentation on the VecSet struct (inside the vecset module), and find the auto impls.
My guess is that rustdoc just doesn't yet handle const generics properly
Support for const generics in rustdoc has not been tested very thoroughly at all (I don't think there are any tests in the test suite for it at all yet). We also have a number of issues with pretty-printing consts (). That said, I imagine this would not be too difficult to fix: we're getting the right parameter — we're just debug printing it instead of pretty-printing it.
Change:
return; } <del> let basic_blocks = body.basic_blocks_mut(); </del> <ins> let basic_blocks = body.basic_blocks.as_mut(); let source_scopes = &body.source_scopes; </ins> let mut replacements: Vec<_> = (0..num_blocks).map(BasicBlock::new).collect(); let mut used_blocks = 0; for alive_index in reachable.iter() {

Discussion:
This can be seen here: To reproduce:
Last passing run was so this regressed between 2022-06-30 and 2022-07-02.
Minimized a reproducer. : : Execution:
label regression-untriaged
Bisection says searched nightlies: from nightly-2022-06-29 to nightly-2022-07-03 regressed nightly: nightly-2022-07-03 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsSo,
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Unfortunately while this fixes the minimal reproducer, it doesn't fix the full case. Would you prefer I file a new bug, or should this one be re-opened? To reproduce:
It's not very minimized, but slightly better. : : Empty
searched nightlies: from nightly-2022-07-07 to nightly-2022-07-22 regressed nightly: nightly-2022-07-09 searched commits: from to regressed commit:
Interesting, I had assumed based on the matching panic message that it'd have the same regressing commit.
Happy to report that with the latest nightly we're back to green on nightly. Thanks much
Thanks the first fix was enough for Suricata :-)
Thanks so much, pydantic-core has been pinned to but is not back on nightly.
Change:
<ins> // aux-build:issue-98697-reexport-with-anonymous-lifetime.rs // ignore-cross-compile // When reexporting a function with a HRTB with anonymous lifetimes, // make sure the anonymous lifetimes are not rendered. // // https://github.com/rust-lang/rust/issues/98697 extern crate issue_98697_reexport_with_anonymous_lifetime; // @has issue_98697/fn.repro.html '//pre[@class="rust fn"]/code' 'fn repro<F>() where F: Fn(&str)' // @!has issue_98697/fn.repro.html '//pre[@class="rust fn"]/code' 'for<' pub use issue_98697_reexport_with_anonymous_lifetime::repro; </ins>

Discussion:
The correct behavior is for both crates' docs to render as: <img src="https://user-" height="100"However, recent versions of nightly rustdoc render as the above, while rendering incorrectly as: <img src="https://user-" height="100"I believe this is a bug because that is not valid syntax in Rust.
bisects to in nightly-2022-06-23 ( &mdash;
Example affecting the standard library docs: not affected. <img src="https://user-" height="100"- broken. <img src="https://user-" height="100"
Change:
// ignore-tidy-filelength "#; <ins> /// This is a shim for the ARM (32-bit) architecture, which is no longer supported by windows-rs. const ARM_SHIM: &str = include_str!("arm_shim.rs"); </ins> fn main() -> io::Result<()> { let mut path: PathBuf = std::env::args_os().nth(1).expect("a path to the rust repository is required").into();

Discussion:
In the WinAPI definitions have been replaced by windows-bindgen generated bindings. However, the project does not generate metadata for ARM32-specific items, hence the generated bindings lack a few types like and on this platform. It effectively breaks for Rust.
Unfortunately, 32-bit ARM is not being supported by Microsoft going forward. What we could do is insert our own definitions in , copied from before the changes.
Besides the issue with ARM, all UWP targets actually have problems with linkage as well. Previously the APIs forbidden on UWP are gated behind fine-grained conditional compilation flags, but it is no longer the case with generated ones. I got this when building the UWP app that links again a Rust staticlib. !
Iirc, the functions were never gated. But we loaded them lazily (and panicked if they didn't load). This did allow UWP targets to compile. No idea if they actually ran. I'm not sure who's responsible for these targets.
I think you are correct. I can reproduce the link errors with toolchain . Let me file another issue after I pinpoint the underlying problem.
Oh wait, as staticlib? You currently need to make sure to link all the libraries it depends on. You can get them using .
This will fail Windows App Cert Kit tests. !
In that case I'm surprised that lazy loading worked.
WG-prioritization assigning priority (). label -I-prioritize +P-low
Change:
// current compilation session, the crate is guaranteed to be the same // (otherwise, we would compute a different `DefPathHash`). let raw_def_id = self.get_raw_def_id(&hash)?; <ins> debug!("def_path_hash_to_def_id({:?}): raw_def_id = {:?}", hash, raw_def_id); </ins> // If the owning crate no longer exists, the corresponding definition definitely // no longer exists. let krate = self.try_remap_cnum(tcx, raw_def_id.krate)?; <ins> debug!("def_path_hash_to_def_id({:?}): krate = {:?}", hash, krate); </ins> // If our `DefPathHash` corresponded to a definition in the local crate, // we should have either found it in `local_def_path_hash_to_def_id`, or // never attempted to load it in the first place. Any query result or `DepNode`

Discussion:
This seems to be an incremental error‽ We need an external crate for this to work. Haven't managed it to work in an internal mod only :/ Also this only happens with . Haven't managed to get it running with sadly extern crate (let's call it f) code Then just remove and add afterwards again (or the other way round, it doesn't matter). This script does it for you: <!-- 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<pand with RUST_BACKTRACE=full the LLVMing assert vanishes </p</details
searched nightlies: from nightly-2020-12-08 to nightly-2020-12-10 regressed nightly: nightly-2020-12-10 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: </detailscc
Assigning as discussed as part of the and removing .
I've fixed the issue locally, and I'm working on a PR.
Opened
Change:
#![feature(const_arguments_as_str)] #![feature(const_array_from_ref)] #![feature(const_array_into_iter_constructors)] <del> #![feature(const_assume)] </del> #![feature(const_bigint_helper_methods)] #![feature(const_black_box)] #![feature(const_caller_location)]

Discussion:
The feature gate for the issue is . It makes usable in const contexts. Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label. <!-- Include each step required to complete the feature. Typically this is a PR implementing a feature, followed by a PR that stabilises the feature. However for larger features an implementation could be broken up into multiple PRs. --- [x] Implemented in [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide]) [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide]) [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev- <!-- Include any open questions that need to be answered before the feature can be stabilised. --<!-- Include a list of all the PRs that were involved in implementing the feature. --
Do you want to stabilize the feature? I was asked to use in const context here:
WG-const-eval has confirmed that this is fine: Feel free to send in a PR flipping the stability attribute. It's an unstable intrinsic so we aren't really committing to anything.
Change:
let explicit_link = dest.to_string(); let display_link = link_data.resolvable_link.clone()?; <del> let explicit_len = explicit_link.len(); let display_len = display_link.len(); if (explicit_len >= display_len && &explicit_link[(explicit_len - display_len)..] == display_link) || (display_len >= explicit_len && &display_link[(display_len - explicit_len)..] == explicit_link) </del> <ins> if explicit_link.ends_with(&display_link) || display_link.ends_with(&explicit_link) </ins> { match link_type { LinkType::Inline | LinkType::ReferenceUnknown => {

Discussion:
Reduced from the source code of : <!-- 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</detailsWould have been introduced by since that PR the lint.. cc label -T-compiler +T-rustdoc
Change:
for pretty_printer_file in &pretty_printer_files { inputs.push(mtime(&rust_src_dir.join(pretty_printer_file))); } <del> let mut entries = config.run_lib_path.read_dir().unwrap().collect::<Vec<_>>(); while let Some(entry) = entries.pop() { let entry = entry.unwrap(); let path = entry.path(); if entry.metadata().unwrap().is_file() { inputs.push(mtime(&path)); } else { entries.extend(path.read_dir().unwrap()); } } </del> <ins> inputs.extend(collect_timestamps(&config.run_lib_path)); </ins> if let Some(ref rustdoc_path) = config.rustdoc_path { inputs.push(mtime(&rustdoc_path)); inputs.push(mtime(&rust_src_dir.join("src/etc/htmldocck.py")));

Discussion:
If I modify a file in the rustc source code (), is smart enough to rerun all tests. However, if I modify something in , then still ignores the tests that completed successfully in the previous run. Steps to reproduce: tests: . For example, replace the function in  with: tests again: Expected output: some tests fail. Actual output:
I would be interested in fixing this issue myself if someone could give me some guidance on how to do that. The main thing that I do not understand is how understands that was changed. It seems that it does not use files for this because they include only the hash of the configuration options which do not include version. cc
The most likely culprit (that ignores the test files) is in module. It is called from and will set the flag for the test depending on its output.
That being said, I find it hard to see how to adjust compiletest itself to take the dependencies into account. rustbuild should probably have some sort of dependency edge and delete the stamp files if/when stuff like compiletest changes.
Compiletest source code has only 9 files. Would it be acceptable to check that their timestamps are newer than the timestamp of the stamp file? PR:
Change:
None => ( tcx.associated_items(did) .in_definition_order() <del> .filter_map(|item| { if associated_trait.is_some() || item.vis.is_public() { Some(item.clean(cx)) </del> <ins> .filter(|item| { // If this is a trait impl, filter out associated items whose corresponding item // in the associated trait is marked `doc(hidden)`. // If this is an inherent impl, filter out private associated items. if let Some(associated_trait) = associated_trait { let trait_item = tcx .associated_items(associated_trait.def_id) .find_by_name_and_kind( tcx, item.ident(tcx), item.kind, associated_trait.def_id, ) .unwrap(); // corresponding associated item has to exist !tcx.is_doc_hidden(trait_item.def_id) </ins> } else { <del> None </del> <ins> item.vis.is_public() </ins> } }) <ins> .map(|item| item.clean(cx)) </ins> .collect::<Vec<_>>(), clean::enter_impl_trait(cx, |cx| { clean_ty_generics(cx, tcx.generics_of(did), predicates)

Discussion:
Minimal reproducible example (on stable and nightly): Document crate and take a look at the generated pages of and : You should be able to actually see the associated type in the block despite being marked as hidden. You probably need to click (expand) first. The block I refer to is in section Implementors on the trait page and in section Trait Implementations on the implementor's page. It should be noted that even though wrongly shows up in those blocks, it is indeed not shown in the code block at the start of the trait page – at the “definition site” if you will (compared to the “use sites” – the blocks). It is crucial that the trait and the type are defined inside of an external crate. If they were defined in the “current” crate, this bug would not occur: The hidden associated items would not be shown. You can check this for yourself by documenting on its own and viewing its documentation separately, or by re-exporting the crate from (e.g. with ) and then documenting : On the page for , the associated item is hidden On the page for the re-export , however, the associated item is displayed after a CI job failed because the linkchecker complained about broken links in the standard library when documenting it with a modified rustdoc. The broken links are not relevant for this bug, they are mere symptoms of it: If everything was properly hidden, no broken links would ever be generated. This bug currently affects the standard library documentation (for stable and nightly) as mentioned in the linked comment. In this case, the trait is  the type is  the associated type that shouldn't be shown is crate “alpha” is crate “beta” is label T-rustdoc A-cross-crate-reexports <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim