jiebi/CodeConvo huggingface dataset:
Change:
recently started saying something like this several times on almost every invocation:
Probably caused by Cc
is there any way for us to make that warning an error? Ideally this wouldn't pass CI...
It was done to fix CI in RLS repo and has no effect on Rust. Why should it be a hard error?
It's worth noting that functionally it doesn't change anything - the section in the RLS manifest should always point to the version checked in the submodule. I'll update the RLS. I understood that this use case might be useful to support in some way - my intent was to patch the dependency from the crate PoV to emphasize that pulling Rustfmt from git is a temporary measure and a regular dependency should be used eventually there, rather than trying to globally patch the rustfmt (which is already done by the final Rust virtual manifest).
It should be a hard error or silenceable -- we shouldn't have warnings on master.
AFAIK it's hardcoded. I've suggested introduction of lints in , to build upon . The largest implementation complexity I see with the cargo feature is in fact non-cargo lints because rustc prints the source of the lint level, and if cargo sets arguments, rustc would only see those and thus complain about arguments to the users. Maybe initially the feature could only allow lints, with rustc lints coming once it's figured out how to get rustc print the source of the lint level. It would be great to have this feature for as well so that one doesn't need to support in random compilation units.
Yeah it's hardcoded to warn:
any news on updating RLS? I can take care of removing the patch and bumping the submodule to a separate branch on rust-lang/rls if you'd like (the patch shouldn't be needed for rust-lang/rust, but I guess is needed upstream).
You don't need a separate branch. You only have to create a different file and then change ci to do sth like .
I guess that would work too, but personally that seems somewhat more complicated and more likely to lead to problems of only updating one of them.

Discussion:
[patch."https://github.com/rust-lang/cargo"] cargo = { path = "src/tools/cargo" } <del> [patch.crates-io] </del> <ins> [patch."https://github.com/rust-lang/rustfmt"] </ins> # Similar to Cargo above we want the RLS to use a vendored version of `rustfmt` # that we're shipping as well (to ensure that the rustfmt in RLS and the # `rustfmt` executable are the same exact version). rustfmt-nightly = { path = "src/tools/rustfmt" } <ins> [patch.crates-io] </ins> # See comments in `src/tools/rustc-workspace-hack/README.md` for what's going on # here rustc-workspace-hack = { path = 'src/tools/rustc-workspace-hack' }

<del> Subproject commit 942aa2b5d729a63f8b81592ab7b2720b63a884e9 </del> <ins> Subproject commit 48ef96dd00b90d950a122ca180923aba77efaf74 </ins>
Change:
I tried runnning I expected to see this happen: an error message similar to Instead, this happened: the tests ran and printed their output in json (mentioned in , cc )
See also . There are multiple issues with how this is handled.

Discussion:
"" }; <ins> // `libtest` uses this to know whether or not to support // `-Zunstable-options`. if !builder.unstable_features() { cargo.env("CFG_DISABLE_UNSTABLE_FEATURES", "1"); } </ins> let mut features = String::new(); // Cranelift doesn't support `asm`.
Change:
The tier 3 platform x86_64-linux-kernel has support for core + alloc, and we test it in CI at , so I think it should be marked **.
Thank you for your issue! We just moved the platform support table to the rustc book, so I'm going to transfer this issue to rust-lang/rust.
Hi, I'm Sasha, I've never contributed to Rust before, and I'd like to know if I can work on this issue. If I understand correctly, this issue is just about fixing the Tier 3 table in [the platform support file][platform-]. Is that correct? Are there some other details that should be discussed before? Edit: fixed link. [platform-]:
That sounds right to me, Welcome! Thanks for moving, apparently I checked right before it was moved :)

Discussion:
`thumbv4t-none-eabi` | * |  | ARMv4T T32 `x86_64-apple-ios-macabi` | ✓[^apple] |  | Apple Catalyst `x86_64-apple-tvos` | *[^apple] | | x86 64-bit tvOS <del> `x86_64-linux-kernel` | ? |  | Linux kernel modules </del> <ins> `x86_64-linux-kernel` | * |  | Linux kernel modules </ins> `x86_64-pc-solaris` | ? |  | `x86_64-pc-windows-msvc` | ✓ |  | 64-bit Windows XP support `x86_64-unknown-cloudabi` | ✓ |  | 64-bit CloudABI
Change:
The rustdoc help says However, in Rust lingo, or isn't a "type". is a type. And , and certainly aren't "types". IMO this should at least be qualified to something like "item type", but I think "item kind" would be even better.
Cc

Discussion:
} function getHelpElement() { <ins> buildHelperPopup(); </ins> return document.getElementById("help"); }

var infos = [ "Prefix searches with a type followed by a colon (e.g., <code>fn:</code>) to  <del> restrict the search to a given type.", "Accepted types are: <code>fn</code>, <code>mod</code>, <code>struct</code>,  </del> <ins> restrict the search to a given item kind.", "Accepted kinds are: <code>fn</code>, <code>mod</code>, <code>struct</code>,  </ins> <code>enum</code>, <code>trait</code>, <code>type</code>, <code>macro</code>,  and <code>const</code>.", "Search functions by type signature (e.g., <code>vec -&gt; usize</code> or 

popup.appendChild(container); insertAfter(popup, getSearchElement()); <ins> // So that it's only built once and then it'll do nothing when called! buildHelperPopup = function() {}; </ins> } onHashChange(null); window.onhashchange = onHashChange; <del> buildHelperPopup(); </del> }()); // This is required in firefox. Explanations: when going back in the history, firefox doesn't re-run
Change:
After is merged, usage of in this module: should be replaced by . The dependency from corresponding can be removed afterwards. It might make sense to request a perf run, as version uses parkinglot, while the standard one uses std mutex, but I expect the difference to not matter -- fast path is equivalent for both.
claim
is done! Though, I am not unsure if we maybe should wait until it tickles down to beta? Not sure how bootstraping works with libstd, I guess, we can just try and see if the build fails.
The compiler always builds with the in-tree standard library, so cfg(bootstrap) should never be necessary (beyond lints, and other compiler-implemented rather than library-implemented) details.
ping this is ready to be implemented.
I'll start soon! Sorry I got a bit overwhelmed with work. If in the next couple of days I haven't replied feel free to re-assign.
On it!
once this is merged, should other sub-crates that depend on also be updated? Like for example. Also, what about ? Some usage can probably be replaced by .
We definitely should actively remove oncecell crate from all rustc’s crates, because having two difference sources of the same data structure feels bad. Replacing lazystatic with std::lazy would also be good!
I'll try to take of it once this issue is fixed :+1:

Discussion:
"lazy_static", "libc", "measureme", <del> "once_cell", </del> "parking_lot 0.10.2", "rustc-hash", "rustc-rayon",

tracing = "0.1" jobserver_crate = { version = "0.1.13", package = "jobserver" } lazy_static = "1" <del> once_cell = { version = "1", features = ["parking_lot"] } </del> rustc_serialize = { path = "../rustc_serialize" } rustc_macros = { path = "../rustc_macros" } rustc_graphviz = { path = "../rustc_graphviz" }

#![feature(extend_one)] #![feature(const_panic)] #![feature(const_generics)] <ins> #![feature(once_cell)] </ins> #![allow(rustc::default_hash_types)] #[macro_use]

pub use std::cell::RefMut as LockGuard; pub use std::cell::RefMut as MappedLockGuard; <del> pub use once_cell::unsync::OnceCell; </del> <ins> pub use std::lazy::OnceCell; </ins> use std::cell::RefCell as InnerRwLock; use std::cell::RefCell as InnerLock;

pub use parking_lot::MutexGuard as LockGuard; pub use parking_lot::MappedMutexGuard as MappedLockGuard; <del> pub use once_cell::sync::OnceCell; </del> <ins> pub use std::lazy::SyncOnceCell as OnceCell; </ins> pub use std::sync::atomic::{AtomicBool, AtomicUsize, AtomicU32, AtomicU64};

#![doc(html_root_url = "https://doc.rust-lang.org/nightly/")] #![feature(nll)] <ins> #![feature(once_cell)] </ins> #![recursion_limit = "256"] #[macro_use]

#![feature(nll)] #![feature(generator_trait)] #![feature(generators)] <ins> #![feature(once_cell)] </ins> #![recursion_limit = "256"] mod callbacks;

#![feature(exhaustive_patterns)] #![feature(extern_types)] #![feature(nll)] <ins> #![feature(once_cell)] </ins> #![feature(option_expect_none)] #![feature(or_patterns)] #![feature(min_specialization)]

#![feature(crate_visibility_modifier)] <ins> #![feature(once_cell)] </ins> #![feature(or_patterns)] #[macro_use]
Change:
<!-- 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
It looks like it's correctly complied on rustc 1.48.0-nightly:
I dont think this should compile at all. After all, we cause UB, the value of the const generic does not comply with the rules of .
A str being valid utf-8 is not a language invariant, so this should not be UB to my knowledge. cc I do expect this to be the correct behavior, so marking as
We do have to compare the s to check for equality though, which might cause library ub so :shrug:
I think you are free to decide on your own invariant here -- assuming that two are equal if and only if the underlying are equal, it's your call whether you want to allow non-UTF-8 in types or not. What is the plan for other library types? Like, imagine a user defined a newtype around that must be even. The compiler cannot even know that such an invariant exists so it cannot be enforced. Equality checking anyway happens by comparing the underlying bytes. So if we follow that analogy, the non-UTF-8 should be fine, but we have to make sure that we use the right notion of equality.
:+1: yeah, see for more details here I guess One concern is that we probably want to print s in and in encodings, so we need to either deal with invalid utf there or forbid it entirely :thinking: Will have to keep that in mind before stabilizing parameters.
Yeah, you could either use (so any special treatment of is confined to the printing code) or make a very special compiler-understood type even for the type system itself (and reject non-UTF-8 strings early). The former seems more principled to me but that is just a slight preference.
won't work for symbol mangling, as otherwise two distinct types can have the same symbol: (current ICE is unrelated, as const generics is not yet fully supported there) Printing invalid utf8 as bytes might be simpler there :thinking: I guess cc about that
Oh, this is not just pretty-printing but needs to be injective? Then I guess some or so (for "invalid") would work.

Discussion:
<ins> // build-pass #![allow(incomplete_features)] #![feature(const_generics)] struct Bug<const S: &'static str>; fn main() { let b: Bug::<{ unsafe { // FIXME(const_generics): Decide on how to deal with invalid values as const params. std::mem::transmute::<&[u8], &str>(&[0xC0, 0xC1, 0xF5]) } }>; } </ins>

<ins> // check-pass #![feature(associated_type_defaults)] use std::io::Read; trait View { type Deserializers: Deserializer<Item = Self::RequestParams>; type RequestParams = DefaultRequestParams; } struct DefaultRequestParams; trait Deserializer { type Item; fn deserialize(r: impl Read) -> Self::Item; } fn main() {} </ins>
Change:
Enable "Directly go to item in search if there is only one result" option on Settings ! Search an unique item in search box generated by rustdoc, it will lead you to the doc of that item. Click the go back button in browser, the page will change to previous search result and go forward to the doc of the searched item. How to reproduce the issue: Go to std doc: Search for "PhantomData" Click the go back button in browser. : 1.47.0-nightly ( 2020-08-20) cc
Well, you can but since there is only one result, it puts you back haha. (Ok, we can consider it as bug, but it's a funny one)
The single search result page can be elided using the to disappear it, leaving the back button to take you to before the search. I believe this would be the desired behavior?
What about detecting the key release to check if there's a single item and redirect, instead of redirecting after calculating the results?

Discussion:
} function showResults(results) { <del> if (results.others.length === 1 && getCurrentValue("rustdoc-go-to-only-result") === "true") { </del> <ins> var search = getSearchElement(); if (results.others.length === 1 && getCurrentValue("rustdoc-go-to-only-result") === "true" // By default, the search DOM element is "empty" (meaning it has no children not // text content). Once a search has been run, it won't be empty, even if you press // ESC or empty the search input (which also "cancels" the search). && (!search.firstChild || search.firstChild.innerText !== getSearchLoadingText())) { </ins> var elem = document.createElement("a"); elem.href = results.others[0].href; elem.style.display = "none"; // For firefox, we need the element to be in the DOM so it can be clicked. document.body.appendChild(elem); elem.click(); <ins> return; </ins> } var query = getQuery(search_input.value);

"</div><div id="results">" + ret_others[0] + ret_in_args[0] + ret_returned[0] + "</div>"; <del> var search = getSearchElement(); </del> search.innerHTML = output; showSearchResults(search); var tds = search.getElementsByTagName("td");

} } <ins> function getSearchLoadingText() { return "Loading search results..."; } </ins> if (search_input) { search_input.onfocus = function() { putBackSearch(this);

var params = getQueryStringParams(); if (params && params.search) { var search = getSearchElement(); <del> search.innerHTML = "<h3 style="text-align: center;">Loading search results...</h3>"; </del> <ins> search.innerHTML = "<h3 style="text-align: center;">" + getSearchLoadingText() + "</h3>"; </ins> showSearchResults(search); }
Change:
Minimal test case: rustc output: Rust 0.7, Ubuntu 13.04, 64-bit.
Funny. This is because std exports an inner module called std that shadows std.
There are probably other lurking bugs due to this.
This evil inner module is still around. We couls probably just special case the macro injection via an attribute like .
This could probably use a similar fix as , something at the top of the file which says that the path to is.
Fixed by the privacy changes that meant that module in can be private. This works: Flagging as needstest.

Discussion:
<ins> // Copyright 2013 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. // Issue #7580 // error-pattern:fail works #[feature(globs)]; use std::*; fn main() { str::with_capacity(10); // avoid an unused import message fail!("fail works") } </ins>
Change:
Rustdoc highlights most links in blue, for example module links: ! But it does not highlight the links on the docs index page: ! Generally links are highlighted in blue (or some other color) on websites and the rest of Rustdoc highlights links so it would be more consistent to highlight these links. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
modify labels: C-bug C-enhancement T-rustdoc
Where did you find that link?
The index page is and the page that shows the modules is
Do you know how to get to the index page () with docs for other crates? I can't seem to find the "List of all crates" in docs for other projects.
I don't think this is actually generated by rustdoc. This looks like bootstrap is passing .
In which case this should be a feature request for bootstrap, not a bug report for rustdoc.
Hmm, but it's generated by Rustdoc here:
Oh interesting. It's still not on by default, you need to pass , but it's definitely a rustdoc issue.
claim

Discussion:
krates .iter() .map(|s| { <del> format!("<li><a href="{}index.html">{}</li>", ensure_trailing_slash(s), s) </del> <ins> format!( "<li><a class="mod" href="{}index.html">{}</a></li>", ensure_trailing_slash(s), s ) </ins> }) .collect::<String>() );
Change:
I'll jump straight into the minimum verifiable example: Try it out . Here is the standard error output: Being a complete beginner I don't really know what I can add to this report, and I have a workaround which I can use to avoid this problem. (I know what I can put in the place of ) Edit: () gives which seems not ideal.
Assigning as and removing .
There is a partial fix in , though it regresses diagnostics. I think it ought not to be too much work to address this, but I do not have time at the moment.
This ICEs since . modify labels: +regression-from-stable-to-stable

Discussion:
match it.kind { hir::ItemKind::Fn(..) => tcx.ensure().fn_sig(def_id), hir::ItemKind::OpaqueTy(..) => tcx.ensure().item_bounds(def_id), <ins> hir::ItemKind::Const(ty, ..) | hir::ItemKind::Static(ty, ..) => { // (#75889): Account for `const C: dyn Fn() -> _ = "";` if let hir::TyKind::TraitObject(..) = ty.kind { let mut visitor = PlaceholderHirTyCollector::default(); visitor.visit_item(it); placeholder_type_error(tcx, None, &[], visitor.0, false, None); } } </ins> _ => (), } }

static BAR: _ = "test"; //~ ERROR E0121 <del> fn main() { } </del> <ins> fn main() {} </ins>

<ins> // Regression test for #75889. const FOO: dyn Fn() -> _ = ""; //~ ERROR E0121 static BOO: dyn Fn() -> _ = ""; //~ ERROR E0121 fn main() {} </ins>

<ins> error[E0121]: the type placeholder `_` is not allowed within types on item signatures --> $DIR/issue-75889.rs:3:24 | LL | const FOO: dyn Fn() -> _ = ""; |                        ^ not allowed in type signatures error[E0121]: the type placeholder `_` is not allowed within types on item signatures --> $DIR/issue-75889.rs:4:25 | LL | static BOO: dyn Fn() -> _ = ""; |                         ^ not allowed in type signatures error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0121`. </ins>
Change:
As of , the lint is no longer working. /// let x = 1; /// I expected to see this happen: should issue Instead, this happened: No warnings emitted. This appears to have changed in . I don't see any discussion there about this, so I'm guessing it was unintentional. cc
This was definitely unintentional. I thought I a test for this ...
Hmm, it tests with but not with . Maybe the name_ of the lint wasn't registered?
The issue is . Compiletest runs with RUSTC_BOOTSTRAP set. I don't recall off the top of my head how to force a test to be stable.
Wait now I'm confused. I thought the point of this lint was that it only runs on nightly, because we're not sure if we want to stabilize it. cc
are you sure this used to work?
The lint has been on stable since 1.32. It is documented .
Got it, I mixed it up with . Yeah this is a bug then - the two lints should be treated differently.
Actually it looks like I introduced the opposite bug for - it now runs on beta when it shouldn't.
Assigning as and removing .

Discussion:
//! This pass is overloaded and runs two different lints. //! <del> //! - MISSING_DOC_CODE_EXAMPLES: this looks for public items missing doc-tests //! - PRIVATE_DOC_TESTS: this looks for private items with doc-tests. </del> <ins> //! - MISSING_DOC_CODE_EXAMPLES: this lint is **UNSTABLE** and looks for public items missing doc-tests //! - PRIVATE_DOC_TESTS: this lint is **STABLE** and looks for private items with doc-tests. </ins> use super::{span_of_attrs, Pass}; use crate::clean;

find_testable_code(&dox, &mut tests, ErrorCodes::No, false, None); <del> if tests.found_tests == 0 { </del> <ins> if tests.found_tests == 0 && rustc_feature::UnstableFeatures::from_environment().is_nightly_build() { </ins> if should_have_doc_example(&item.inner) { debug!("reporting error for {:?} (hir_id={:?})", item, hir_id); let sp = span_of_attrs(&item.attrs).unwrap_or(item.source.span());

|lint| lint.build("missing code example in this documentation").emit(), ); } <del> } else if rustc_feature::UnstableFeatures::from_environment().is_nightly_build() && tests.found_tests > 0 && !cx.renderinfo.borrow().access_levels.is_public(item.def_id) </del> <ins> } else if tests.found_tests > 0 && !cx.renderinfo.borrow().access_levels.is_public(item.def_id) </ins> { cx.tcx.struct_span_lint_hir( lint::builtin::PRIVATE_DOC_TESTS,
Change:
On stable 1.45.2, and From of : Possible related or duplicate issues are (doesn't seem to be as general) and (currently marked as solved). <details<summary<strongBacktrace on stable 1.45.2</strong</summary<p</p</details<details<summary<strongBacktrace on 1.47.0-beta.1 (2020-08-25 )</strong</summary<p</p</details<details<summary<strongBacktrace on 1.47.0-nightly (2020-08-25 )</strong</summary<p</p</details
Note that the function doesn't need to be public. Also, after reading the docstring that this example came from, it seems like an attempt is made to generate code, although no code should be emitted (the function can never be called, as the where clause can not be satisfied).
This regressed in 1.44.0.
ping cleanup-crew This issue could use a bisection to nail down where it starts. I think it regressed in between 1.43..1.44
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
Regression in searched nightlies: from nightly-2020-04-21 to nightly-2020-09-02 regressed nightly: nightly-2020-05-03 searched commits: from to regressed commit:
Assigning as and removing .
No longer ICEs since

Discussion:
<ins> // check-pass pub fn foo<'a>(s: &'a mut ()) where &'a mut (): Clone { <&mut () as Clone>::clone(&s); } fn main() {} </ins>
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! And nominating for compiler team prioritization.
The bot is wrong; it's not that broke Miri, it's

Discussion:
name = "cargo-miri" version = "0.1.0" dependencies = [ <del> "cargo_metadata 0.9.1", </del> <ins> "cargo_metadata 0.11.1", </ins> "directories", "rustc-workspace-hack", "rustc_version",

[[package]] name = "cargo_metadata" <del> version = "0.9.1" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "46e3374c604fb39d1a2f35ed5e4a4e30e60d01fab49446e08f1b3e9a90aef202" dependencies = [ "semver 0.9.0", "serde", "serde_derive", "serde_json", ] [[package]] name = "cargo_metadata" </del> version = "0.11.1" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "89fec17b16f1ac67908af82e47d0a90a7afd0e1827b181cd77504323d3263d35"

name = "miri" version = "0.1.0" dependencies = [ <del> "byteorder", </del> "colored", "compiletest_rs", "env_logger 0.7.1",

<del> Subproject commit 2d6d73fafe2f087354f7cea37297cd81316cae98 </del> <ins> Subproject commit c2a2e25d0b050d70d6a355f9b7545a991fc8783a </ins>