jiebi/CodeConvo huggingface dataset:
Code change:
#[license = "MIT/ASL2"]; #[crate_type = "dylib"]; #[crate_type = "rlib"]; <del> #[doc(html_logo_url = "http://www.rust-lang.org/logos/rust-logo-128x128-blk.png", </del> <ins> #[doc(html_logo_url = "http://www.rust-lang.org/logos/rust-logo-128x128-blk-v2.png", </ins> html_favicon_url = "http://www.rust-lang.org/favicon.ico", html_root_url = "http://static.rust-lang.org/doc/master")];

Related discussion:
text: It's currently very bright and distracting (IMO). (Sorry :( ) Current scheme, for future triage/comparison purposes: !
I think I should reconsider my career in graphic design.
I'm looking at this.
(The relevant file is , if you're lost. :) )
BTW I was wondering, why not just use for src line numbering? Probably more optimized/idiomatic in the browser.
Also, it's pretty much impossible to have consistency between rustdoc and the old codemirror (tutorial) since both parsers behave very differently. would it be possible to pass the standalone documentation through rustdoc?
Doesn't this mean every line is a new tag? Also, it possibly screws with copy-paste and making the formatting consistent. This bug is specifically about the colour scheme of rustdoc since it's so wild. Also, about using rustdoc for everything.
My preference for the highlighting scheme is bold for keywords, green for macros, red for strings (the current color is fine), gray for comments (would be nice if code within comments were highlighted). I'd also like to hear more suggestions before we change it.
Something I hacked up a few days ago: ! (The macro colour wasn't "optimised" at all.)
No, it would look like this: I think it would be better to use that since that's the browser native numberings. No it doesn't. The identifier of a list aren't inlined with the content. is an example.
Oh, awesome. It does seem like a good idea, if you can get that to work.
Another note: current rustdoc parsing could be improved, i.e. the "ident" class corresponds to variable names, function names, paths, parameters... could be more split if you ask me.
The highlighting is performed by just by the token types the lexer (with a little bit of extra logic for attributes, macros and $ non-terminals in macros) and so does not have that information.
Code change:
verbose_help); } <ins> fn print_wall_help() { println!(" The flag `-Wall` does not exist in `rustc`. Most useful lints are enabled by default. Use `rustc -W help` to see all available lints. It's more common to put warning settings in the crate root using `#![warn(LINT_NAME)]` instead of using the command line flag directly. "); } </ins> fn describe_lints(sess: &Session, lint_store: &lint::LintStore, loaded_plugins: bool) { println!(" Available lint options:

Related discussion:
text: It would be nice if turned on all warnings, like how other compilers work.
At least with and , doesn't turn on all the warnings. I don't think turning all on the warnings is ever going to be useful because lots are going to be very domain specific (ones like already are). clang has a fairly useless to turn on all warnings, and to turn on all those included by , and also many more that are considered to be useful. Rust already has all the warnings viewed as useful and not too subjective on by default.
Oh, wow! Thanks for the detailed, thoughtful response. I'll definitely look into each of those options.
(FWIW the warnings are listed in and are almost all on by default)
I think there should be a catch-all lint group, that objectively enables all lints. Whenever programmers decide subjectively to allow lints in some instances, they may then do that on a case-by-case basis. And if an implemented lint simply does not make sense at all then it should be improved/removed. The existing lint group apparently does not include all built-in lint groups, contrary to the output of (): can this issue be reopened?
Reopening. However, I think we shouldn't have any sort of "enable all lints" option; rustc's lints are already all intended to have no or very few false positives (and as such are enabled by default where that makes sense). Could you talk about which specific lints are missing from the default warnings built-in list? I'm not personally aware of any. I'm also somewhat concerned that a or similar option would be confusing to some extent because "all" wouldn't include clippy lints (and probably can't, or at least not easily -- though I don't know the details here).
Issue triage: no longer prints , so that was fixed at some point. (it now prints ) I think it might be useful to have a message explaining why doesn't exist, point the user toward to see all available errors, and suggest adding a for a more thorough lint check. This would help beginners coming from other languages to 1) understand that most useful warnings are turned on by default, 2) tell the user that exists, and 3) show the user that warnings can be controlled from inside the source code, rather than the command line. If there's interest in doing this, I could make a PR.
Code change:
Command::new("mkdir").arg("./").output().unwrap() }; <del> assert!(status.code() == Some(1)); </del> <ins> assert!(status.code().is_some()); assert!(status.code() != Some(0)); </ins> assert_eq!(stdout, Vec::new()); assert!(!stderr.is_empty()); } #[test] <del> #[cfg_attr(any(target_os = "vxworks", target_os = "android"), ignore)] </del> <ins> #[cfg_attr(any(target_os = "vxworks"), ignore)] </ins> fn test_finish_once() { let mut prog = if cfg!(target_os = "windows") { Command::new("cmd").args(&["/C", "exit 1"]).spawn().unwrap() } else { <del> Command::new("false").spawn().unwrap() </del> <ins> shell_cmd().arg("-c").arg("false").spawn().unwrap() </ins> }; assert!(prog.wait().unwrap().code() == Some(1)); } #[test] <del> #[cfg_attr(any(target_os = "vxworks", target_os = "android"), ignore)] </del> <ins> #[cfg_attr(any(target_os = "vxworks"), ignore)] </ins> fn test_finish_twice() { let mut prog = if cfg!(target_os = "windows") { Command::new("cmd").args(&["/C", "exit 1"]).spawn().unwrap() } else { <del> Command::new("false").spawn().unwrap() </del> <ins> shell_cmd().arg("-c").arg("false").spawn().unwrap() </ins> }; assert!(prog.wait().unwrap().code() == Some(1)); assert!(prog.wait().unwrap().code() == Some(1)); } #[test] <del> #[cfg_attr(any(target_os = "vxworks", target_os = "android"), ignore)] </del> <ins> #[cfg_attr(any(target_os = "vxworks"), ignore)] </ins> fn test_wait_with_output_once() { let prog = if cfg!(target_os = "windows") { Command::new("cmd").args(&["/C", "echo hello"]).stdout(Stdio::piped()).spawn().unwrap() } else { <del> Command::new("echo").arg("hello").stdout(Stdio::piped()).spawn().unwrap() </del> <ins> shell_cmd().arg("-c").arg("echo hello").stdout(Stdio::piped()).spawn().unwrap() </ins> }; let Output { status, stdout, stderr } = prog.wait_with_output().unwrap();

Related discussion:
text: To enable test on android bot and test/run-pass/rtio- It looks to me RtioProcess does not work properly on android.
logs are
Hm this may be an FFI issue with libuv. I realized during my uv rewrite that libuv is giving us an int64t exit status and we think it's a cint. Once lands this may be fixed.
Hmm, this issue number has propagated to several more tests that are cfg-disabled on android. (Some of which are now failing when I mixed in a Boehm/BDW conservative GC into the runtime, in particular .)
Also, has landed, so it would be good to determine if these tests now work on Android.
Triage: I have no idea how to test this, but a lot has changed in a year (especially the removal of green & libuv), so these may be magically fixed; if someone can check.
Triage: is gone, but all these tests in are still ignored for android.
I tried to run these tests with but they all failed with , which seems suspect (at least for the tests that invoke , , , etc.). Is there a better way to test? I have an android device available.
Code change:
expanded_cache: FxHashMap::default(), primary_def_id: Some(def_id), found_recursion: false, <ins> found_any_recursion: false, </ins> check_recursion: true, tcx: self, };

Related discussion:
text: I tried this code: I expected running to produce an error like: It does, but takes time exponential in the number of calls, although doesn't appear to use any extra memory. In the time take looks like: I believe it's also exponential in the number of calls in . The reason I had code like this was because I was using nom's parser combinators which results in lots of nested closures. I spotted it because this caused rust-analyzer to hang because cargo clippy hung (it looks like check was the issue), I had to kill clippy to fix it. I bisected this (with cargo-bisect-rustc) to find the regression in , which contained the following bors commits: merge of - Centril:rollup-rzvry15, r=Centril merge of - tmandry:rollup-0k6jiik, r=tmandry merge of - Manishearth:clippyup, r=Manishearth merge of - tanriol:explain_borrow-use-context-dominators, r=nagisa merge of - ehuss:update-cargo-books, r=alexcrichton modify labels: +regression-from-stable-to-stable -regression-untriaged
what version of rust are you using? Is this also present on nightly?
Good question! This repros on the latest nightly () and on stable (1.53.0 2021-06-17).
Regression means that it was linear, or exponential, but smaller?
I didn't looks to still be exponential just much quicker, and with a smaller base (~2 vs ~14):
looks related
Bisected to innocent-looking commit . Removing the caching from in master does indeed fix the issue. I haven't looked at the how or why or where that causes (other) problems though. cc
Hmm, the only thing that looks expensive there is the hashing - I wonder if it's hashing over and over again without ever getting a cache hit? Hashing has a fixed cost, but can be an arbitrary length:
cuts down on time for this testcase and others with invalid recursive opaque types by bailing out early if a recursion is found.
Code change:
expanded_cache: FxHashMap::default(), primary_def_id: Some(def_id), found_recursion: false, <ins> found_any_recursion: false, </ins> check_recursion: true, tcx: self, };

Related discussion:
text: This fixes the regression but the check time is still exponential in the recursion: #wraps|time (s) ---|--- 23|9.2 24|18.3 25|36.6 Not sure if that matters in practice though.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
That's the same as before the regression, right? I definitely think that's a change worth making :) I expect the doubling will have a completely different cause.
Yes, same ballpark.
Code change:
Box::new(MaybeUninit::uninit()) } <del> // FIXME: add a test for a bigger box. Currently broken, see // https://github.com/rust-lang/rust/issues/58201. </del> <ins> // https://github.com/rust-lang/rust/issues/58201 #[no_mangle] pub fn box_uninitialized2() -> Box<MaybeUninit<[usize; 1024 * 1024]>> { // CHECK-LABEL: @box_uninitialized2 // CHECK-NOT: store // CHECK-NOT: alloca // CHECK-NOT: memcpy // CHECK-NOT: memset Box::new(MaybeUninit::uninit()) } </ins> // Hide the `allocalign` attribute in the declaration of __rust_alloc // from the CHECK-NOT above, and also verify the attributes got set reasonably.

Related discussion:
text: The following code generates some really awful LLVM IR: The same happens with . Cc who made me write these tests, and
Feels like an LLVM limitation to me. It should be replacing the with a (or a of poison when that becomes available).
For reference: LLVM is capable of optimizing a memcpy of undef alloca away, this just runs into the usual limitation that all of memcpyopt doesn't work across BBs.
This is such a long-standing issue. Seems like it might be wise to have someone working on fixing this.
Someone has already worked on this, see It's a bit hard to track, but unfortunately this got reverted again (multiple times). I suspect that this is only going to get really resolved once memcpyopt moves to memssa -- which someone has also worked on in the past (), but which never really went anywhere.
The alloca and memcpy are no longer present on nightly, as a result of .
The FIXME in the test is still there, needs a test.
Code change:
use rustc_hir as hir; use rustc_hir::def::{DefKind, Res}; use rustc_hir::def_id::{DefId, DefIdMap, LocalDefId, LocalDefIdSet}; <del> use rustc_hir::intravisit::{walk_item, Visitor}; </del> <ins> use rustc_hir::intravisit::{walk_body, walk_item, Visitor}; </ins> use rustc_hir::{Node, CRATE_HIR_ID}; use rustc_middle::hir::nested_filter; use rustc_middle::ty::TyCtxt;

Related discussion:
text: <!-- 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. --Consider the following code is local to and inaccessible, and should not be documented. Instead, rustdoc currently documents the module at the same level as . <!-- 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. --: </details
cc does this have to do with those changes you made to item collection?
Very likely. I won't be able to fix it until next week though. EDIT: I suspect it broke from
I just realized that this is broken on stable, too, so I think the cause may be older than that?
Oh. I'm at least happy to realize that I didn't break it recently. Thanks for the report. Will fix it monday.
Code change:
<ins> error[E0308]: mismatched types --> $DIR/bad-type-in-vec-push.rs:11:17 | LL |     vector.sort(); |     ------ here the type of `vector` is inferred to be `Vec<_>` LL |     result.push(vector); |            ---- ^^^^^^ expected integer, found struct `Vec` |            | |            arguments to this method are incorrect | = note: expected type `{integer}` found struct `Vec<_>` note: associated function defined here --> $SRC_DIR/alloc/src/vec/mod.rs:LL:COL error[E0308]: mismatched types --> $DIR/bad-type-in-vec-push.rs:18:12 | LL |     x.push(""); |       ---- ^^ expected integer, found `&str` |       | |       arguments to this method are incorrect | note: associated function defined here --> $SRC_DIR/alloc/src/vec/mod.rs:LL:COL error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

Related discussion:
text: I tried this code on nightly: I expected to see this happen: compiler does not panic. Instead, this happened: compiler panics and suggests I open a bug report. I initially posted to , but says this is a different issue, despite panicking on the same line in . (Though I'm realizing now that might be the proximal cause but not very related to the root cause.) : <details<summaryPanic message</summary<p</p</detailsThanks all for maintaining Rust, by the way.
Thanks!
searched nightlies: from nightly-2022-12-01 to nightly-2023-01-21 regressed nightly: nightly-2023-01-07 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
It's , i'll fix it unless someone beats me to it since I'm busy this weekend
Hi it's Justin from Commure :wave:. I found a compiler panic you made :grinning:
sorry for causing you trouble
Code change:
} fn run(self, builder: &Builder<'_>) { <del> // This gets called by `promote-release` // (https://github.com/rust-lang/rust-central-station/tree/master/promote-release). </del> let mut cmd = builder.tool_cmd(Tool::BuildManifest); if builder.config.dry_run { return;

Related discussion:
text: Seems like no nightly was released today. That might be related to Unfortunately I don't think I have access to the logs. Cc
Logs are missing on the server, let me start a manual release...
Well that is odd. You wouldn't know what commit is is using? ( file in the tarball, if I recall correctly.)
Is there a way for me to download the "dist" artifacts for better testing? Right now I am manually grabbing a bunch of files from https://s3-us-west- (and we only get dir listing for alt builds there it seems so I am using those). That's not very convenient at all.
Apparently not all commits are pushed to toolstate ( vs ), for example the latest one () is missing in toolstate .
Reverting the cause in the meantime --
Alternatively we could land which will just skip of the toolstate is not found. That installs a toolchain based on these artifacts, but I don't think it gives me access to the tarballs. FTR, for now I did So we are only committing when the toolstate changed? Ouch. That kills my entire approach :(
It should print the URLs it's downloading though, and you can use to avoid it actually downloading stuff.
Code change:
impl ErrorIndex { pub fn command(builder: &Builder<'_>) -> Command { <del> // This uses stage-1 to match the behavior of building rustdoc. // Error-index-generator links with the rustdoc library, so we want to // use the same librustdoc to avoid building rustdoc twice (and to // avoid building the compiler an extra time). This uses // saturating_sub to deal with building with stage 0. (Using stage 0 // isn't recommended, since it will fail if any new error index tests // use new syntax, but it should work otherwise.) let compiler = builder.compiler(builder.top_stage.saturating_sub(1), builder.config.build); </del> <ins> // Error-index-generator links with the rustdoc library, so we need to add `rustc_lib_paths` // for rustc_private and libLLVM.so, and `sysroot_lib` for libstd, etc. let host = builder.config.build; let compiler = builder.compiler_for(builder.top_stage, host, host); </ins> let mut cmd = Command::new(builder.ensure(ErrorIndex { compiler })); <del> add_dylib_path( vec![ PathBuf::from(&builder.sysroot_libdir(compiler, compiler.host)), builder.rustc_libdir(compiler), ], &mut cmd, ); </del> <ins> let mut dylib_paths = builder.rustc_lib_paths(compiler); dylib_paths.push(PathBuf::from(&builder.sysroot_libdir(compiler, compiler.host))); add_dylib_path(dylib_paths, &mut cmd); </ins> cmd } }

Related discussion:
text: Steps: Checkout commit Have in . In particular, this implies Run Output (on the second run):
cc
For what it’s worth is just what I happened to get after running today. I mentioned it in case something changes later, it’s a coincidence that that commit happens to be related to downloading LLVM from Rust CI.
I think this is a duplicate of
That issue is closed, and its final comment points to this issue.
I just hit this on the following sequence. Do a fresh clone of Run Select option (b) "compiler: Contribute to the compiler itself" Run The build finished like so:
IMO the proper fix for this is to remove error-index's dependency on rustdoc, either by moving the relevant code out into a library that doesn't use rustc_private, or by duplicating the code altogether. There are other ways to solve this but they'll be more complicated and take longer to compile for no real benefit.
by making it invoke rustdoc-the-binary (through ), rather than using rustdoc-the-library.
you should be able to work around this by adding --stage 2 I think.
Thanks, that worked
I think you're right that the binary will be easier - parsing the markdown requires parsing doctests so that it can generate the "Run" button, and parsing doctests requires all of .
Code change:
<ins> #![feature(doc_alias)] #![feature(trait_alias)] pub struct Foo; pub trait Bar { const BAZ: u8; } impl Bar for Foo { #[doc(alias = "CONST_BAZ")] //~ ERROR const BAZ: u8 = 0; } impl Foo { #[doc(alias = "CONST_FOO")] // ok! pub const FOO: u8 = 0; pub fn bar() -> u8 { Self::FOO } } </ins>

Related discussion:
text: Now that has been merged, only a few checks remain to be in order to stabilize this feature. First, we need to actually perform those checks in the compiler directly instead of rustdoc. You mentioned other checks too ? This issue is part of .
We should reject on items that don't actually appear in the search index such as blocks and s.
Ok, makes sense! Last question: I remember you telling that you'd prefer this check in rustc directly instead of rustdoc. I can move things there, just wanted to check one last time before doing it.
Yeah, rustc validates some attributes in and it might make sense to validate the attribute there as well.
Since has been merged, we can close this issue.
We're still not rejecting on associated s in trait impls like:
Ok! Putting on hold then!
Code change:
fn test1() { let a: i32 = "foo"; //~^ ERROR: mismatched types <ins> let b: i32 = "f'oo"; //~^ ERROR: mismatched types </ins> } fn test2() {

Related discussion:
text: This is minimized from the dramatic forum thread . The following code is fine in nightly-2018-04-12 but breaks with nightly-2018-04-15. Oddly, lots of minor perturbations make it succeed. For example remove the two characters and it works. Or remove the single quote in the string and it works.
Alrighty-roo. As everything these days with hygiene, there's a couple of bugs here. With this one though I think only two! Everything has to do here with basically. AKA anything that runs through that falls off The usual reasons we think you fall off the "happy path" are due to things like inner attributes, , macro expansion, etc. None of that's present here! It should be the case that above can be losslessly converted to a based on what we've cached. Turns out though had a bug in it (surprise surprise!). There we're using to compare the resulting two token streams which eventually bottoms out in . As it turns out this isn't quite what we want! The implementation is structural, but the token stream we get when stringifying is slightly different than what we parsed. Here in the example you're using the literal string , but rustc stringifies this token as . Similarly if you replaced the string with something like it'll be stringified as . This means that the tokens are not literally byte-for-byte equal, which means we fall off the happy path! tl;dr the token stream of is not equivalent to the token stream . This causes us to fall off the happy path and used a stringified token stream. OK so in the case above we're falling off the happy path when we didn't expect to, but even still there's some weird bad hygiene behavior when we're not on the happy path. There's still something to fix! It turns out that there's also a regression due to (found via bisection). Before that PR this example would compile just fine, afterwards though it's hitting this error. can you help diagnose this and see what's going on? The reduced test case I have right now is: (note the inner attribute on to force using a non-cached token stream)
I've posted a fix for the "happy path" at will actually fix example above.
Code change:
fn test1() { let a: i32 = "foo"; //~^ ERROR: mismatched types <ins> let b: i32 = "f'oo"; //~^ ERROR: mismatched types </ins> } fn test2() {

Related discussion:
text: That PR does not, however, fix the regression from which is still reproducible with the example I gisted.
Any idea why my repro case above is fixed if you remove the tokens? It seems like should fall off the happy path just as much.
If you remove the tokens we're still on the stringification path (aka not the happy path). For whatever reason though the hygiene bug goes away. That's likely caused from a subtelty introduced in (or at least so I'm hoping). I don't know much about , so I'm hoping will be able to look at this and know what's going on!
I don't know much about , so I'm hoping will be able to look at this and know what's going on! I'll investigate.
is the commit causing the regression. Further investigation is in progress.
An issue recently popped up on Rocket () that appears to be identical to this one and is not resolved in any recent nightly. It's possible that the root cause is , however.