jiebi/CodeConvo huggingface dataset:
Change:
let clippy_info = channel::GitInfo::new(&config, &src.join("src/tools/clippy")); let miri_info = channel::GitInfo::new(&config, &src.join("src/tools/miri")); let rustfmt_info = channel::GitInfo::new(&config, &src.join("src/tools/rustfmt")); <ins> let in_tree_llvm_info = channel::GitInfo::new(&config, &src.join("src/llvm-project")); let emscripten_llvm_info = channel::GitInfo::new(&config, &src.join("src/llvm-emscripten")); </ins> let mut build = Build { initial_rustc: config.initial_rustc.clone(),

Discussion:
Which means that programs that run from a build script, or from cargo in some other way, fail. Steps to Reproduce: a clang binary pointing to clang-8 installed and in your path. install nightly clone && cd $ test Actual results: /usr/bin/clang: relocation error: symbol ZTIN4llvm14FoldingSetBaseE version LLVM8 not defined in file libLLVM-8.so with link time reference Expected results: not so This only happens if ran from cargo, if I run the test executable manually then stuff works, so I suspect this is some LDLIBRARYPATH mungling that cargo or rustup do under the hood. This is technically a regression from , same problem does not exist with rust stable / beta and clang 7. There's a slight chance that there's an issue on how clang-8 is built in Fedora, so I also filed , but I think it's unexpected that clang when called from cargo / build scripts uses rust's , and probably should be avoided. cc
Is invoked from a build script? It is possible that cargo neglects removing the unnecessary or similar environment variables before invoking the script in question. EDIT: oh you wrote that in the report already. I remember there being an issue like this in cargo repo from a long long time ago, but cannot find it now.
cc
See also . We should probably set a custom suffix per . Maybe even include the Rust version to help avoid bootstrap issues like what commit saw. (cc
Yep, I think a suffix of rust version (or maybe LLVM submodule commit?) would be good. I think we'd appreciate a PR for something like that; I would expect it to be a matter of making the version suffix default be or something along those lines.
Sure, that sounds good, I can give that a shot.
I sent with a change that I hope will address this, but see there why I cannot confirm it will :)
triage: P-high, assigning to
Change:
<ins> // Copyright 2018 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. // run-rustfix #![allow(dead_code)] fn missing_discourses() -> Result<isize, ()> { Ok(1) } fn forbidden_narratives() -> Result<isize, ()> { Ok(missing_discourses()?) //~^ ERROR try expression alternatives have incompatible types //~| HELP try wrapping with a success variant } fn main() {} </ins>

Discussion:
Given this example: I get this error (): It seems like it should not be talking about =)
Ideally, I would think it should say something like "missing ", but that may be a separate bug -- i.e., maybe we should strive to just produce the same error you would get if you did
Change:
// Save any local changes, but avoid running `git stash pop` if there are none (since it will exit with an error). // diff-index reports the modifications through the exit status let has_local_modifications = !self.run_cmd( <del> BootstrapCommand::from(helpers::git(Some(&absolute_path)).args([ "diff-index", "--quiet", "HEAD", ])) .allow_failure() .output_mode(match self.is_verbose() { true => OutputMode::PrintAll, false => OutputMode::PrintOutput, }), </del> <ins> BootstrapCommand::from(submodule_git().args(["diff-index", "--quiet", "HEAD"])) .allow_failure() .output_mode(match self.is_verbose() { true => OutputMode::PrintAll, false => OutputMode::PrintOutput, }), </ins> ); if has_local_modifications { <del> self.run(helpers::git(Some(&absolute_path)).args(["stash", "push"])); </del> <ins> self.run(submodule_git().args(["stash", "push"])); </ins> } <del> self.run(helpers::git(Some(&absolute_path)).args(["reset", "-q", "--hard"])); self.run(helpers::git(Some(&absolute_path)).args(["clean", "-qdfx"])); </del> <ins> self.run(submodule_git().args(["reset", "-q", "--hard"])); self.run(submodule_git().args(["clean", "-qdfx"])); </ins> if has_local_modifications { <del> self.run(helpers::git(Some(&absolute_path)).args(["stash", "pop"])); </del> <ins> self.run(submodule_git().args(["stash", "pop"])); </ins> } }

Discussion:
To reproduce, I am in a worktree without (i.e., not the "main" worktree). I have a pre-commit hook set up as follows Now I change something trivial (e.g. remove a trailing in some comments) and commit. That does the following After a second or two I get suspicious and hit Ctrl-C. Now it looks like bootstrap has done something with the (previously clean) cargo submodule So let's and see what's up Eh... so the files are rustc files? Why are those being in ? Something is going seriously wrong here.
I think this only happens with . I attempted to reproduce it about 25 times without success.
Yes indeed, this does not happen in my folder (the main checkout, where lives), but it happens in worktree folders.
Adding some debug logging, it seems like some truly strange things are happening... This is the HEAD commit of the outer repository! I think what's happening is that some environment variables are set inside the git hook which overwrite the . x.py relies on just setting the working directory to determine which git dir to use, but e.g. GITDIR takes precedence over that. I tried setting instead of using and that does seem to help.
Change:
<ins> // Test that we don't ICE after trying to construct a cross-file snippet #63800. // compile-flags: --test #[macro_use] #[path = "move-error-snippets-ext.rs"] mod move_error_snippets_ext; struct A; macro_rules! sss { () => { #[test] fn fff() { static D: A = A; aaa!(D);         //~ ERROR cannot move } }; } sss!(); fn main() {} </ins>

Discussion:
When trying to compile the tests for my I get this error: <details<summary</summary</detailsMy understanding is that the compiler was trying to tell me about a borrow checker error; but I have no idea where to start minimizing this error(sorry).
I have managed to get it down to two files: It doesn't work with a in the , it has to be a different file. is then needed to trigger the ICE.
modify labels: I-ICE A-macros C-Bug T-compiler
cc
Seems to be related to 2018 edition? If I use the nightly-2018-10-01 and execute it doesn't ICE, but with it does ICE. well...
Most likely related to the fact that NLL is active in Rust 2018 then.
Bisecting: Somewhere in
Confirmed. gave me the ICE on 2015 as well (forgot that in the good ol' days nll was not a thing) Also confirmed, that edition 2015 does ICE with on and not on (like edition 2018 did above).
Also ICE with
Change:
// Our block must be a `assign desugar local; assignment` if let Some(hir::Node::Block(hir::Block { stmts: <del> [hir::Stmt { kind: hir::StmtKind::Local(hir::Local { source: hir::LocalSource::AssignDesugar(_), .. }), .. }, hir::Stmt { kind: hir::StmtKind::Expr(hir::Expr { kind: hir::ExprKind::Assign(..), .. }), .. }], </del> <ins> [ hir::Stmt { kind: hir::StmtKind::Local(hir::Local { source: hir::LocalSource::AssignDesugar(_), .. }), .. }, hir::Stmt { kind: hir::StmtKind::Expr(hir::Expr { kind: hir::ExprKind::Assign(..), .. }), .. }, ], </ins> .. })) = self.tcx.hir().find(blk.hir_id) {

Discussion:
, we should provide a structured suggestion as we already do when . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
seems easy enough, claim
Change:
<ins> #![feature(doc_notable_trait)] #![feature(lang_items)] #![feature(no_core)] #![no_core] #[lang = "owned_box"] pub struct Box<T>; impl<T> Box<T> { pub fn new(x: T) -> Box<T> { Box } } #[doc(notable_trait)] pub trait FakeIterator {} impl<I: FakeIterator> FakeIterator for Box<I> {} #[lang = "pin"] pub struct Pin<T>; impl<T> Pin<T> { pub fn new(x: T) -> Pin<T> { Pin } } impl<I: FakeIterator> FakeIterator for Pin<I> {} // @!has doc_notable_trait_box_is_not_an_iterator/fn.foo.html '//*' 'Notable' pub fn foo<T>(x: T) -> Box<T> { Box::new(x) } // @!has doc_notable_trait_box_is_not_an_iterator/fn.bar.html '//*' 'Notable' pub fn bar<T>(x: T) -> Pin<T> { Pin::new(x) } </ins>

Discussion:
The and documentation shows "notable traits" on the method, and any other methods that return a Pin or a Box: ! That's because these structs have "pass-through" implementations: if implements , then implements . If implements , then implements . Since returns , it gets the icon indicating a notable trait. These return types should not be annotated with the , since "notable traits" should be reserved for things that are actually notable - like the impl on . One way to achieve this: if the bounds for the impl include the "notable trait", don't consider that impl eligible for treatment.
Out of curiosity, I a to emit a list of which types get the "notable traits" annotation for which traits. Running this over std, emitting one line per instance, and going through , I get the below. For instance, shows up as a return type 183 times in the std docs, with a "notable trait" of iterator each time. The high count for iterator types is expected - it's because these get repeated on different pages for every item that implements Iterator. After the iterator types, slice's Read/Write impls and Box's Read/Write/Future/Iterator impls are the most frequent.
I got a PR implementing this solution, just need to clean it up. What's the best way to make a test for this? Just a regular rustdoc test?
Yep! Specifically one of the tests under src/test/rustdoc that generates documentation for a small example and then makes assertions on the output. Note that this is a bit of a tricky test since it's a negative assertion. So it would be easy for the test to pass but for unrelated reasons (for instance if we changed the HTML layout). To avoid that problem I recommend having two parts of the test, for two different items: one item that should have the annotation, and one item that should not have the annotation. That way if the HTML layout changes the test will fail.
any updates? BTW I think it would be reasonable to just special case "Box" and "Pin" by name and say they should never get the treatment.
Sorry, gotta rebase this, and I saw some weird regressions in the UI tests with this heuristic...
Ugh, sorry, probably won't get around to fixing this. I'll unclaim.
Change:
<ins> // check-fail struct Foo {} impl Foo { fn bar(foo: Foo<Target = usize>) {} //~^ associated type bindings are not allowed here } fn main() {} </ins>

Discussion:
<!-- 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
From
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-medium
Change:
// We've successfully resolved the import. Write the results in. let mut import_resolutions = module_.import_resolutions.borrow_mut(); <del> let import_resolution = &mut (*import_resolutions)[target]; </del> <ins> let import_resolution = import_resolutions.get_mut(&target).unwrap(); </ins> { let mut check_and_write_import = |namespace, result: &_, used_public: &mut bool| {

Discussion:
I believe we intend to eventually extend the index traits with the ability to override the syntax specifically using a trait like . This would allow hashmaps to be used like and have that insert the key, unlike today where will panic if is not already present. To pave the way, the simplest thing is to remove the operator from those collections where we would anticipate growing on demand. I believe that would be , , and possible and . Thoughts? cc
triage: P-backcompat-libs I-needs-decision (1.0 beta)
triage: P-backcompat-libs (1.0 beta)
I was just starting to prep a PR to resolve this by removing the impl, as you suggested. :)
Don't we want to keep the implementation on for example to do something like ?
Depending on the exact way that is done, it may not be possible to provide both modes of use. That is, we want to be able to write -- which we cannot today -- but it's not clear that you can do that and also support examples like the one you gave. In particular, that involves adjusting inference to determine whether or not a deref is in play. For now, removing these impls will give us the most freedom when we do incorporate .
It seems weird to have this and insert -- insert has a return value, though. This would be a super-annoying ergonomic regression in the interim. What's the expected timeline for something like IndexSet? 1.1?
Oh actually upon reflection most usages I know are Index, not IndexMut. Not as awful a regression.
It should be possible to move in, out, and take references with the operator. If that's not possible with the current design then the current design has to be changed instead of committing to yet another subpar design until 2.0.
sounds powerful and interesting, is there any RFC for it now?
It feels odd that does not support . I don't buy the argument that would be confused with - no other container supports insertion via the syntax. Now if you would add some hypothetical and support insertion into a via , then someone would just get confused that they can't use to insert into a .. (doesn't really makes sense, but what if entries are default constructible!) Not even talking about the pandora box of accidentally inserting elements into the container. Imho we should keep consistent as an accessor to get references to data already existing in the container.
Change:
<ins> #[derive(Clone)] struct P<T> { x: T, y: f64, } impl<T> P<T> { fn y(&self, y: f64) -> Self { P{y, .. self.clone() } } //~^ mismatched types [E0308] } fn main() {} </ins>

Discussion:
<!-- 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. --The following code: triggers a panic in the compiler (see below). All works as expected if I write . <!-- 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
Output on stable: (An awkward but correct error - without , the compiler uses autoref to resolve as which returns .) searched nightlies: from nightly-2021-10-16 to nightly-2021-11-28 regressed nightly: nightly-2021-11-10 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: </details label regression-from-stable-to-beta
Probably ?
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
I think this is a duplicate of , and I also put up a fix in (along with both in and in ) which has been waiting for a review for quite some time.. Not sure which one of our PRs should be approved, but at least one of them should :^) -- re: , I agree with Aaron that this is the simpler and more targeted fix for the bug, so I'll just close mine after this gets approved probably. (edit: made it clearer who I was referring to in the original comment - lol, sorry)
thanks for the note! I'll also add (as a self-reminder) that in Aaron also that might be a better fix.
Change:
#[cfg(not(target_os = "l4re"))] { <ins> if let Some(_g) = self.get_groups() { //FIXME: Redox kernel does not support setgroups yet #[cfg(not(target_os = "redox"))] cvt(libc::setgroups(_g.len().try_into().unwrap(), _g.as_ptr()))?; } </ins> if let Some(u) = self.get_gid() { cvt(libc::setgid(u as gid_t))?; } if let Some(u) = self.get_uid() { // When dropping privileges from root, the `setgroups` call <del> // will remove any extraneous groups. If we don't call this, // then even though our uid has dropped, we may still have // groups that enable us to do super-user things. This will // fail if we aren't root, so don't bother checking the // return value, this is just done as an optimistic // privilege dropping function. </del> <ins> // will remove any extraneous groups. We only drop groups // if the current uid is 0 and we weren't given an explicit // set of groups. If we don't call this, then even though our // uid has dropped, we may still have groups that enable us to // do super-user things. </ins> //FIXME: Redox kernel does not support setgroups yet #[cfg(not(target_os = "redox"))] <del> let _ = libc::setgroups(0, ptr::null()); </del> <ins> if libc::getuid() == 0 && self.get_groups().is_none() { cvt(libc::setgroups(0, ptr::null()))?; } </ins> cvt(libc::setuid(u as uid_t))?; } }

Discussion:
already offers and methods to control the user identity of the child process (calling respectively). For complete control of Unix credentials, there should also be a way to call and the concept of the supplementary group list are; I would expect this not to be a portability concern.) This feature would eliminate a use of and an unsafe block (to call ) from the program I'm currently writing, which is a port to Rust of a setuid C program. For illustration, this function exists in the C version: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I would be prepared to consider a PR to add .
claim
Change:
<ins> fn main() { env!("EXISTING_ENV"); option_env!("EXISTING_OPT_ENV"); option_env!("NONEXISTENT_OPT_ENV"); option_env!("ESCAPEnESCAPE"); } </ins>

Discussion:
This is still in 's build script: But the use site has been moved here: This means that won't be rebuilt when that env var changes. For the record, I haven't seen a bug from this, was just curious where may be used and spotted the mismatch. cc
Found another one: is used in but it's still mentioned by . cc Could we automate ensuring this? e.g. by searching for in tidy.
Yeah, we can try I guess. Not sure :) Maybe the right solution is that Cargo would, other than some whitelist, remove unknown variables from rustc's environment -- and the whitelist can be expanded via the build script env-tracking.
hmm I wonder if abusing the file format (from ) or encoding this extra info in a comment, would be a good idea.
You mean such that if you use we automatically tell Cargo to rebuild on changes? (That's ). But yeah, I think that would be good. Ideally this would be "well-integrated" vs. the current state of everyone having to remember to do it.

(As discussed with on IRC.) Rustc should have an option to obtain a list, as part of building, of every environment variable that was requested via the or macros (tagged accordingly with "required" or "optional"), as well as providing a way to instrument intrinsics like called by scripts. This will make it more feasible to detect (and lint about) the usage of environment variables only set by newer build bits (e.g. Cargo) without an appropriate versioned dependency; for instance, it'd be possible to say "you use the environment variable without a dependency on a version of Cargo that supplies . This would also help people doing reproducible builds to see what environment variables might affect a build. This will never be perfect; it can't capture variables read from native code or from code that goes out of its way to bypass the normal mechanism (e.g. calling .) However, this would still catch many common cases.
Just following up to say that this is an accurate reflection of what we discussed. As said, it's part of a larger goal to detect usage of newer Cargo features on older versions of Cargo and let the user know which version of Cargo they need to upgrade to. For keys in , it's enough to simply keep a list of when a particular key was (since Cargo is the one parsing ). But if Cargo adds an environment variable, we need some compiler help to detect that the environment variable was used from Rust code.
I believe this may be a dupe of
They're related, though I think seems more narrow in scope.
Change:
} <del> pub fn namespace_to_str(ns: Namespace) -> ~str { </del> <ins> pub fn namespace_error_to_str(ns: NamespaceError) -> &'static str { </ins> match ns { <del> TypeNS  => ~"type", ValueNS => ~"value", </del> <ins> NoError     => "", ModuleError => "module", TypeError   => "type", ValueError  => "value", </ins> } }

Discussion:
Code like Generates the error Which is wrong. is not a type, it's a module.
Change:
<ins> // This test ensure that #[doc(hidden)] is applied correctly in enum variant fields. // Denotes a field which should be hidden. pub struct H; // Denotes a field which should not be hidden (shown). pub struct S; // @has issue_88600/enum.FooEnum.html pub enum FooEnum { // @has - '//*[@id="variant.HiddenTupleItem"]//code' 'HiddenTupleItem(_)' // @count - '//*[@id="variant.HiddenTupleItem.field.0"]' 0 HiddenTupleItem(#[doc(hidden)] H), // @has - '//*[@id="variant.MultipleHidden"]//code' 'MultipleHidden(_, _)' // @count - '//*[@id="variant.MultipleHidden.field.0"]' 0 // @count - '//*[@id="variant.MultipleHidden.field.1"]' 0 MultipleHidden(#[doc(hidden)] H, #[doc(hidden)] H), // @has - '//*[@id="variant.MixedHiddenFirst"]//code' 'MixedHiddenFirst(_, S)' // @count - '//*[@id="variant.MixedHiddenFirst.field.0"]' 0 // @has - '//*[@id="variant.MixedHiddenFirst.field.1"]' '1: S' MixedHiddenFirst(#[doc(hidden)] H, S), // @has - '//*[@id="variant.MixedHiddenLast"]//code' 'MixedHiddenLast(S, _)' // @has - '//*[@id="variant.MixedHiddenLast.field.0"]' '0: S' // @count - '//*[@id="variant.MixedHiddenLast.field.1"]' 0 MixedHiddenLast(S, #[doc(hidden)] H), // @has - '//*[@id="variant.HiddenStruct"]//code' 'HiddenStruct' // @count - '//*[@id="variant.HiddenStruct.field.h"]' 0 // @has - '//*[@id="variant.HiddenStruct.field.s"]' 's: S' HiddenStruct { #[doc(hidden)] h: H, s: S, }, } </ins>

Discussion:
<!-- 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. --panics when running . This seems to come from cc <!-- 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
what is that attribute intended to do? Enum fields are always public.
I wanted to hide the field from docs because it was not important. But I agree it's probably a bit strange.
Assigning priority as in the prioritization working group.
Change:
use syntax::ast::{self, FloatTy}; use syntax::ast::{CRATE_NODE_ID, Name, NodeId, CrateNum, IntTy, UintTy}; <del> use syntax::codemap::{self, Span, Pos}; </del> <ins> use syntax::codemap::{self, Span}; </ins> use syntax::errors::DiagnosticBuilder; use syntax::parse::token::{self, keywords}; use syntax::util::lev_distance::find_best_match_for_name;

Discussion:
an arbitrary import of the shape will give the following errors and spans: The span is always as long as the crate, but starts at the imported element This can also be used to create an unprintable span: