jiebi/CodeConvo huggingface dataset:
Code change:
this.visit_ty(&ty); } } <del> GenericParamKind::Const { ref ty, .. } => { </del> <ins> GenericParamKind::Const { ref ty, default } => { </ins> let was_in_const_generic = this.is_in_const_generic; this.is_in_const_generic = true; walk_list!(this, visit_param_bound, param.bounds); this.visit_ty(&ty); <ins> if let Some(default) = default { this.visit_body(this.tcx.hir().body(default.body)); } </ins> this.is_in_const_generic = was_in_const_generic; } }

Related discussion:
text: Yeah I think in this case it helped uncover the bug, because of the fact it ICEd and showed us we weren't resolving the closure default.
I guess this example shows that this did help us uncover a bug, but kind of indirectly: This just didn't uncover a case where "lost" bound vars.
this is now fixed on beta
Code change:
} else { cmd = Command::new(&output_file); if doctest.is_multiple_tests { <del> cmd.arg("*doctest-bin-path"); cmd.arg(&output_file); </del> <ins> cmd.env("RUSTDOC_DOCTEST_BIN_PATH", &output_file); </ins> } } if let Some(run_directory) = &rustdoc_options.test_run_directory {

Related discussion:
text: The crater run for merged doctests () detected a large number of regressions due to tests examining the process arguments. (I don't have an exact number, but let's say ~50 projects.) Previously, there were no arguments, but now it gets arguments like which the user's CLI parsing code isn't expecting. For example, using something like  will now fail. It seems to be fairly common to have objects whose default constructor will parse the arguments from the command line. I'm not sure if or how we should resolve that. One idea is to use a different mechanism for passing in the test information (like via an environment variable).
I vaguely remember that using environment variables was discussed but can't find anything except mentioning it . Maybe it'd be a better approach indeed. Let me send a PR so we can make a crater run on it.
Code change:
fn f() -> bool { let c = false; <del> if c { </del> <ins> if c { //~ ERROR unnecessary parentheses </ins> println!("next"); } <del> if c { </del> <ins> if c { //~ ERROR unnecessary parentheses </ins> println!("prev"); } while false && true { <del> if c { </del> <ins> if c { //~ ERROR unnecessary parentheses </ins> println!("norm"); } } <del> while true && false { for _ in 0 .. 3 { </del> <ins> while true && false { //~ ERROR unnecessary parentheses for _ in 0 .. 3 { //~ ERROR unnecessary parentheses </ins> println!("e~") } } <del> for _ in 0 .. 3 { while true && false { </del> <ins> for _ in 0 .. 3 { //~ ERROR unnecessary parentheses while true && false { //~ ERROR unnecessary parentheses </ins> println!("e~") } }

Related discussion:
text: Update test file to use + annotations instead of (see https://rust-) The files need to update are: - <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
is the correct file name , not ? And what about this comment?
Is the problem fixed ? If not, I would like to work on it !
WIP PR has been closed due to inactivity so you can work on this.
I would like to be assigned to this issue. Am I supposed to do a new pull request ?
claim Go ahead!
Error: Parsing assign command in failed: claim Please let know if you're having trouble with this bot.
claim
Error: Parsing assign command in failed: claim Please let know if you're having trouble with this bot.
Hmm, it's odd, anyway, you can assign the issue to yourself by comment Ah, I mistaken the command, the collect one is , sorry.
claim
If I understood well the problem: I must replace all the by just , even if comment exist ? Because the output changes, I should modify the .stderr version I must change with in , and as should raise an error we add why add in the version ?
Code change:
<ins> fn foo<T: impl Trait>() {} //~^ ERROR expected trait bound, found `impl Trait` type fn main() {} </ins>

Related discussion:
text: When writing the current error is "expected one of these tokens", without any attempt to recover the parse. It should instead be closer to: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
What do you expect the suggestion from this code? here is a valid identifier, "expected one of these tokens" comes when the second identifier comes.
I think this case should remain as is. in particular is a shame because it is a valid type for the parser, but not a valid trait, and newcomers might not yet have a mental model for the distinction. I would say, when parsing a trait, if it can't be parsed, then try to parse a type in a snapshot (like we do in other parts of the parser), and if successful, emit a targeted error (trait expected but found type).
claim
Code change:
<ins> mod foo { pub struct B(()); } mod bar { use foo::B; fn foo() { B(()); //~ ERROR expected function, found struct `B` [E0423] } } mod baz { fn foo() { B(()); //~ ERROR cannot find function `B` in this scope [E0425] } } fn main() {} </ins>

Related discussion:
text: For this code: You get the following error message: The suggestion may be excused to be not 100% perfect, but here it suggests to add an use statement despite that same item being imported already. What I want is this exactly: that it removes stuff from the suggestion list that is already being imported. Note that changing the glob import to a non glob one doesn't change anything.
cc
Why is that even an error?
tuple structs have private fields by default, you can't construct instances of B outside of the foo module.
oh ^^ maybe we should simply modify this error message then to say that the "function" is private?
It already says "constructor is not visible here due to private fields". That's okay, but maybe you might have meant another B from another module or something. However, the candidate offered is not any better as its the same one you are attempting to use.
Reopening to track "removal of suggestion" work for pub tuple structs with private fields.
Code change:
prepare("rust-mingw"); } <del> builder.install(&xform(&etc.join("exe/rust.iss")), &exe, 0o644); builder.install(&etc.join("exe/modpath.iss"), &exe, 0o644); builder.install(&etc.join("exe/upgrade.iss"), &exe, 0o644); </del> builder.install(&etc.join("gfx/rust-logo.ico"), &exe, 0o644); <del> builder.create(&exe.join("LICENSE.txt"), &license); // Generate exe installer builder.info("building `exe` installer with `iscc`"); let mut cmd = Command::new("iscc"); cmd.arg("rust.iss").arg("/Q").current_dir(&exe); if target.contains("windows-gnu") { cmd.arg("/dMINGW"); } add_env(builder, &mut cmd, target); let time = timeit(builder); builder.run(&mut cmd); drop(time); builder.install( &exe.join(format!("{}-{}.exe", pkgname(builder, "rust"), target)), &distdir(builder), 0o755, ); </del> // Generate msi installer let wix = PathBuf::from(env::var_os("WIX").unwrap());

Related discussion:
text: The .exe installer tries to install to "C:Program Files (x86)Rust", even though it's the 64-bit version. It then fails to create the destination directory due to a permission error. The .msi installer correctly defaults to "C:Program FilesRust <channel<version", and has no problems with permissions, I would expect the .exe installer to have the same behaviour.
Rust should install to , just like Ant, Python, and many others. is the place for developer tools that have a known folder. is badly named (compare to ), poorly suited for command line tools, and clutters the already hideous PATH more than .
/cc
Neither Ant nor Python install to C:tools by default, and searching I can't find any reference to C:tools even being a thing? Both Python and Ant install to C:Python<Versionand C:ant, which is incredibly annoying, so please don't do that!
I might be mistaken, but installing both through stuck them in for me. I'd recommend anyone with a machine running Vista or later use chocolatey. And there's a trend in chocolatey to have packages extract to when they aren't self-contained enough for .
For an OS without much filesystem hierarchy, is a decent place for developer and command-line packages, similar to on some unices. But I'd much rather see a that actually obeyed chocolatey's conventions and extracted an archive to , with no installer/registry involvement. But Rust only and installers for windows. : And all packages that do this reduce PATH clutter, since chocolatey symlinks their executables into .
The idea was to deprecate the .exe installer once .msi is known to be working satisfactory.
Can we have a zip release too, that contains Rust and Cargo like the others? Linux and OS X have an archive release. Those are preferred in chocolatey because they don't involve the registry or any other Windows components.
We do produce tarballs for windows.
Seems like we should probably just stop producing the .exe's. That fix would go in
I don't see a cargo+rustc nightly tarball for windows, although I do see ones for linux and osx.
triage: We do not link to the .exe installer anymore, but we still produce them.
Code change:
prepare("rust-mingw"); } <del> builder.install(&xform(&etc.join("exe/rust.iss")), &exe, 0o644); builder.install(&etc.join("exe/modpath.iss"), &exe, 0o644); builder.install(&etc.join("exe/upgrade.iss"), &exe, 0o644); </del> builder.install(&etc.join("gfx/rust-logo.ico"), &exe, 0o644); <del> builder.create(&exe.join("LICENSE.txt"), &license); // Generate exe installer builder.info("building `exe` installer with `iscc`"); let mut cmd = Command::new("iscc"); cmd.arg("rust.iss").arg("/Q").current_dir(&exe); if target.contains("windows-gnu") { cmd.arg("/dMINGW"); } add_env(builder, &mut cmd, target); let time = timeit(builder); builder.run(&mut cmd); drop(time); builder.install( &exe.join(format!("{}-{}.exe", pkgname(builder, "rust"), target)), &distdir(builder), 0o755, ); </del> // Generate msi installer let wix = PathBuf::from(env::var_os("WIX").unwrap());

Related discussion:
text: I don't have access to windows at the moment to check if this bug has been resolved, but it's been a long time...
Grabbing the Windows download link from and swapping the for yields a functional link to the , which is nice. Testing on win7-x64, the MSI extracts with lessmsi, but the directory structure is somewhat unusual so there's no one-liner to get the Rust folder out. The best I came up with was: This yields a Rust install rooted at . However now that exists, multiple targets aren't really an issue anymore. Someone should make a Chocolatey package for
Can someone with access to Windows check what happens here today?
The latest version installs to instead, which works, but is a terrible default.
Triage: ! This seems... fine. I'm not sure if this should stay open or not; I'll let the relevant team (infra? compiler?) decide.
Code change:
| LL | unsafe extern "C" { | ^^^^^^ <ins> | = note: see issue #123743 <https://github.com/rust-lang/rust/issues/123743> for more information = help: add `#![feature(unsafe_extern_blocks)]` 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> error[E0658]: `unsafe extern {}` blocks and `safe` keyword are experimental --> $DIR/feature-gate-unsafe-extern-blocks.rs:9:5

Related discussion:
text: With the following code: We get this error: Making the block then gives: cc
:+1:, this should error in both cases but the diagnostics are misleading. Going to fix it. r?
Code change:
## missing_doc_code_examples <del> This lint is **allowed by default**. It detects when a documentation block </del> <ins> This lint is **allowed by default** and is **nightly-only**. It detects when a documentation block </ins> is missing a code example. For example: ```rust

Related discussion:
text: I wanted to try out the missingdoccodeexamples rustdoc lint, but it seems to be bugged. I tried following the example given in . Steps to reproduce: Create a new crate: Then edit the file: I would now expect to get a linting error when building the crate, since the add function is public, but does not have a code example. However, as well as and completes without any errors.
The lint only works on nightly, the docs should probably be updated.
These docs live in To fix this, add 'and is nightly-only' to the first sentence.
I created PR to update the documentation. Thanks for clarifying. :-)
Code change:
use std::cmp; <del> use std::string::String; use crate::clean::{self, DocFragment, Item}; </del> <ins> use crate::clean::{self, DocFragment, DocFragmentKind, Item}; </ins> use crate::core::DocContext; use crate::fold::{self, DocFolder}; use crate::passes::Pass;

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. --I tried this code: /// let example = Example::new() /// .first("hello") #[cfgattr(not(feature = "one"), doc = " .second("hello")n")] /// .third("hello") /// .build(); /// with I expected to see this: ! Instead, this happened: ! <!-- 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. --: running over the code gives me /// let example = Example::new() /// .first("hello") /// .second("hello") /// .third("hello") /// .build(); ///
As explained on discord, <strikethe attributes aren't applied to doc comments</strike(EDIT: they are applied, the problem seems to be that it results in two doc comments for rustdoc). However, your doc comment is split in two so the second half isn't considered as being inside a code block, explaining why you have this display. Even if shows it as one doc comment, rustdoc sees two of them. <strikeMaybe we should add a warning or something that attributes aren't applied to doc comments... What do you think ?</strike
How can an attribute get applied to a doc comment? Both are, under the hood, attributes, no? I would expect that to be equivalent to expecting to only derive Debug if is passed, which is not how that works. I'm guessing what is true is that attributes directly written don't actually merge with -style comments. Potentially relevant: , ,
Simplified reproducer rust //! foo(); #![doc = " bar();"] //! Checking with 1.31.0 it still ignores it (so likely not related), but checking with 1.21.0 (and 1.0.0) it worked as expected, so somewhere within that range (but I don't have any other versions installed at the moment to check).
Compilation broke somewhere between 1.23.0 (works) 1.24.0 (does not work) I tested it with rust //! let x = r#" #![doc = " bar();"] //! "#; //! assert_eq!
Code change:
use std::cmp; <del> use std::string::String; use crate::clean::{self, DocFragment, Item}; </del> <ins> use crate::clean::{self, DocFragment, DocFragmentKind, Item}; </ins> use crate::core::DocContext; use crate::fold::{self, DocFolder}; use crate::passes::Pass;

Related discussion:
text: (x, "n bar();n"); //!
They are not supposed to be applied to a doc comment I do not think that. Your example would make sense for which I also consider to be wrong, but I am talking about which should insert the attribute conditionally but that is not the point. It might help to illustrate my thought process; We have some kind of documented item: rust /// let example = Example::new() /// .first() /// .build(); /// and each of those is turned into a doc attribute rust"] #[doc = "let example = Example::new()"] #[doc = " .first()"] #[doc = " .build();"] #[doc = " In a later step those attributes would then be concatenated and parsed as markdown or whatever. I want to use this behavior to document items conditionally, depending on which features the crate user has enabled. One way to do this would be to do rust let example = Example::new() .first() .build(); rust let example = Example::new() .first() .second() .build(); but that would blow up the source code with many duplicate lines, where only some minor things were changed. So I thought that it might make more sense to conditionally include a doc comment like this: rust /// let example = Example::new() /// .first() #[cfgattr(feature = "one", doc = " .second()")] /// .build(); /// which would turn into rust"] #[doc = "let example = Example::new()"] #[doc = " .first()"] #[doc = " .second()"] #[doc = " .build();"] #[doc = " or rust"] #[doc = "let example = Example::new()"] #[doc = " .first()"] #[doc = " .build();"] #[doc = " depending on whether the feature is enabled. So the attribute should not be inserted and not applied to the following doc comment. The weird thing is that the manually expanded version is working as expected. rust"] #[doc = "let example = Example::new()"] #[doc = " .first()"] #[cfg_attr(feature = "one", doc = " .second()")] #[doc = " .build();"] #[doc = " but this is very unhandy to work with :/
I was randomly looking at passes for another reason and noticed what is likely the source of this issue.
Code change:
use std::cmp; <del> use std::string::String; use crate::clean::{self, DocFragment, Item}; </del> <ins> use crate::clean::{self, DocFragment, DocFragmentKind, Item}; </ins> use crate::core::DocContext; use crate::fold::{self, DocFolder}; use crate::passes::Pass;

Related discussion:
text: There are two relevant passes: runs second and removes leading columns of whitespace from the docs. This runs on a single "doc fragment" at a time, because of merging that normally means the entire documentation string, but since sugared and raw docs aren't merged they remain as separate fragments and use their own widths of leading whitespace to strip.
That also matches up with first released in 1.24 which introduced this distinction between doc kinds in order to fix , which IMO was user error in not matching the indent depth.
Code change:
Available passes for running rustdoc: check-custom-code-classes - check for custom code classes without the feature-gate enabled check_doc_test_visibility - run various visibility-related lints on doctests <ins> strip-aliased-non-local - strips all non-local private aliased items from the output </ins> strip-hidden - strips all `#[doc(hidden)]` items from the output strip-private - strips all private items from a crate which cannot be seen externally, implies strip-priv-imports strip-priv-imports - strips all private import statements (`use`, `extern crate`) from a crate

Related discussion:
text: I tried this code: with and . I expected to see this happen: No internal fields of the should be displayed as users won't be able to use the fields, making their appearance confusing and useless. Instead, this happened: The internal fields of the are displayed ! Real impact as can be seen . : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
labels +T-rustdoc +A-rustdoc-ui -needs-triage claim
Dupe of and more discussion there
Code change:
Available passes for running rustdoc: check-custom-code-classes - check for custom code classes without the feature-gate enabled check_doc_test_visibility - run various visibility-related lints on doctests <ins> strip-aliased-non-local - strips all non-local private aliased items from the output </ins> strip-hidden - strips all `#[doc(hidden)]` items from the output strip-private - strips all private items from a crate which cannot be seen externally, implies strip-priv-imports strip-priv-imports - strips all private import statements (`use`, `extern crate`) from a crate

Related discussion:
text: Using to document private types of the current workspace exposes external types private implementation details (in this case private fields). I would expect the expansion to limit itself to public fields. e.g. gives ! <details<summary<coderustc --version --verbose</code</summary<p</p</detailsr?
I suppose it's "ok" since you used the option. I'll add it to the next rustdoc team meeting agenda to be confirmed by the team.
Rendered output for anyone wondering: !
I'll summarize the exchange I had with Guillaume on matrix. First, the flag I'm talking about is the one you provide to . does not blindly pass the flag to but only for crates you own in your current workspace. That means that when documenting your workspace with . Private items, fields of your crates are shown contrary to your dependencies. Regarding design, it seems weird to me that aliased type expansion shows private implementation details of dependencies (e.g. for the given example). I would personally expect something like:
Code change:
mode: SolverMode, f: impl FnOnce(&mut GlobalCache<Self>) -> R, ) -> R; <ins> fn evaluation_is_concurrent(&self) -> bool; </ins> } pub trait Delegate {

Related discussion:
text: <!-- 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. --After adding to , I get the ICE. The resulting : The full project: <!-- 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. . --
Looks like another label: +T-types +WG-trait-system-refactor +regression-from-stable-to-nightly
Stable passes, beta passes. Nightly passes with either or Discovered with It does sporadically succeed, thus needing to clean and rerun the build to make sure. Either something is up with or it only barely exercises these conditions in the parallel frontend, even after cleaning and running the build 100 times. Meanwhile, fails something like ~50% of the time on my machine.
stable passes obviously, as -Zthreads this is a unstable nightly-only flag?
Hm, not actually obvious given that works, though I suppose that does mean it isn't a regression per se. :^)
oh I thought you knew by now that this is the forbidden env flag that should only ever be used for bootstrapping and nothing else and we should not even tell users about it. If you set the flag, your "stable" will also eat nightly-only features, but why would that make a "to-stable" regression if you explicitly tell the compiler "please act like you are NOT a stable release"? I don't think it make sense to backport fixes for untable nightly features into stable lol
who mentioned backports?
The label is used to gather regressions between release channels, which are then discussed whether they are backport-worthy or not. Is that not how the label is used?
I don't really think regression-from-stable-to-nightly nor regression-from-stable-to-stable are used for that at all? Probably regression-from-stable-to-beta is?
Code change:
mode: SolverMode, f: impl FnOnce(&mut GlobalCache<Self>) -> R, ) -> R; <ins> fn evaluation_is_concurrent(&self) -> bool; </ins> } pub trait Delegate {

Related discussion:
text: Pretty much what the title says, I've narrowed it down to and today's nightly with the following: I've attached some backtraces.
probably duplicate of but made more prevalent by next solver
Is it possible to provide a link to or a snippet of a reproducer? I know it probably happens to various crates, but it still would be nice to have something that reproduces.
See for an attached repro.
The repro case is basically the same as , but with other crates mentioned in the ICE logs from the issue comment.