jiebi/CodeConvo huggingface dataset:
Change:
} pub fn get_crate_data(&self, cnum: CrateNum) -> Rc<CrateMetadata> { <del> self.metas.borrow().get(&cnum).unwrap().clone() </del> <ins> self.metas.borrow()[cnum].clone().unwrap() </ins> } pub fn set_crate_data(&self, cnum: CrateNum, data: Rc<CrateMetadata>) { <del> self.metas.borrow_mut().insert(cnum, data); </del> <ins> use rustc_data_structures::indexed_vec::Idx; let mut met = self.metas.borrow_mut(); while met.len() <= cnum.index() { met.push(None); } met[cnum] = Some(data); </ins> } pub fn iter_crate_data<I>(&self, mut i: I) where I: FnMut(CrateNum, &Rc<CrateMetadata>) { <del> for (&k, v) in self.metas.borrow().iter() { i(k, v); </del> <ins> for (k, v) in self.metas.borrow().iter_enumerated() { if let &Some(ref v) = v { i(k, v); } </ins> } }

Discussion:
While investigating the root cause(s) of and discussing (in the IRC chat room) the use of a hashmap mapping crate-numbers to crate-metadata, "why is that not an ?" One word: Legacy. Big time: the field has been a hashmap ever since was introduced, 6.5 years ago in () It should be a useful (and hopefully simple?) exercise to replace the hashmap that is with an .
So is it just replacing the type with? If sow what is the equivalent for insert?
Should be as simple as that
The only way I am seeing to add to an IndexVec is to push to the end at index == len But the hashmap uses the ability to insert at an arbitrary index: So I don't quite see how to make the conversion.
from my quick skimming, is only called from one place: , here: The in that context is always the steadily incremented . So I would suggest removing entirely, and replacing it with a some method that indeed pushes to the end at index == len, as you state, since it seems that will have the same end effect.
BTW if one really did need to support overwriting for arbitrary s, that is easy too, as long as they already exist in the , since supports the method that underlying : ; but I don't think we will need that in this case.
Maybe you want an ?
That's not 100% correct. Crate numbers are assigned in preorder - if a crate (say ) has a dependency (say ), then will get the earlier crate number, then will be loaded, and only then will the metadata for be assigned. But it's ok to use an to handle this.
You are right. I overlooked the fact that we 1. first increment the crate num (reserving the number, like for in your example), then 2. call (which may recursively re-enter ), before finally 3. calling at the end.
Ok, what is the best incantation to test this locally? In the meantime I will open a pr.
Change:
if rendered { return } PLAYGROUND_KRATE.with(|krate| { let mut s = String::new(); <del> let id = krate.borrow().as_ref().map(|krate| { let idx = TEST_IDX.with(|slot| { let i = slot.get(); slot.set(i + 1); i }); </del> <ins> krate.borrow().as_ref().map(|krate| { </ins> let test = origtext.lines().map(|l| { stripped_filtered_line(l).unwrap_or(l) }).collect::<Vec<&str>>().connect("n"); let krate = krate.as_ref().map(|s| s.as_slice()); let test = test::maketest(test.as_slice(), krate, false, false); <del> s.push_str(format!("<span id='rust-example-raw-{}'  class='rusttest'>{}</span>", idx, Escape(test.as_slice())).as_slice()); format!("rust-example-rendered-{}", idx) </del> <ins> s.push_str(format!("<span class='rusttest'>{}</span>", Escape(test.as_slice())).as_slice()); </ins> }); <del> let id = id.as_ref().map(|a| a.as_slice()); s.push_str(highlight::highlight(text.as_slice(), None, id) .as_slice()); </del> <ins> s.push_str(highlight::highlight(text.as_slice(), None, Some("rust-example-rendered")) .as_slice()); </ins> let output = CString::from_vec(s.into_bytes()); hoedown_buffer_puts(ob, output.as_ptr()); })

Discussion:
For example, the code snippet for with suspicious muffin-related content. This seems to be the snippet for the  function (which is also the first function on the page with example code). All other code snippets on the page lead to the same muffin code. This is on Chrome 39.0.2171.95 (64-bit) on Mac OS X 10.10.1. !
It looks like this is caused by rustdoc rendering all of the examples with the same id. If you look at the playpen js code in rustdoc: you see that it depends on all the same ids being different. However, if you look at the source of the StrExt example you linked, you see they all have "rust-example-rendered-0" as the id. I think the error comes from somewhere in here, but it's not obvious to me how to fix it. I'll look into the issue, but this is my first little bit of work on rust so it may take a second/I'd appreciate insight as to what the problem might be.
nominating for I-muffins
Change:
// See rsbegin.rs for details. <ins> #![feature(no_core, lang_items)] </ins> #![crate_type="rlib"] <del> #![no_std] </del> <ins> #![no_core] #[lang = "sized"] trait Sized {} #[lang = "sync"] trait Sync {} impl<T> Sync for T {} </ins> #[cfg(all(target_os="windows", target_arch = "x86", target_env="gnu"))] pub mod eh_frames {

Discussion:
This looks weird. Isn't a .dll the right thing for this target? cc
Could you try passing ? Seems like may not be making its way to Cargo, or the shim is really messing up here (probably the latter)

Because that's what the old build system does: but rustbuild and rsbegin.o ends up being an ELF on linux: The fix should be simple in theory. You just have to pass to the in the code linked above. But then you run in problems with the order of the operations: " not found for $TARGET". cc
FWIW, trying to cross compile to i686-pc-windows-gnu I get this: Trying to cross compile to x86_64-pc-windows-gnu results in
Yeah not passing would do it, should be easy to add though! (I think that's all that's necessary)
Actually, the solution is the opposite. rustbuild is building these startup files for linux but it should compile them for windows hence the has to be .
Oh right sorry "it" there was "would cause this problem", we should indeed pass !
Change:
// FIXME (#2397): At some point we want to rpath our guesses as to // where extern libraries might live, based on the // addl_lib_search_paths <del> if !sess.opts.cg.no_rpath { </del> <ins> if sess.opts.cg.rpath { </ins> cmd.args(rpath::get_rpath_flags(sess, out_filename).as_slice()); }

Discussion:
Followup to and . Can we completely eliminate our usage of rpath? Doing so would make our linkage more consistent across platforms since it doesn't work on windows. Nominating.
I think that the largest difficulty for this is that we build dynamically, and this means that if you have a fresh install of rust in a new location it won't work by default (you'll have to munge your os library path). If we could print out some helpful instructions of what to do, then I think that would be a much better situation, but I'm also not entirely sure how we'd do that.
If we defaulted to static linking then there would it would be easier to justify making people use LDLIBRARYPATH when they opt in to dylibs.
The only consideration that I have about static linking is that you'll install 5 copies of (as opposed to 3): with static linking rustdoc rustc rustpkg without static linking That being said, our distributions are already pretty big, so maybe this isn't much of a concern? I agree though that if we statically linked everything then we could easily take this route of action
IMO this is a concern. What's wrong with the current approach (link rust's own tools dynamically)? It works fine on windows since the DLLs are in the bin folder and for everything else it will soon link statically ().
Another use case for this came up on IRC. If you've got a rust installed locally in , then when you try to recompile rust again, the rpath for all the stage0-produced libraries will have something pointing into /usr/local. Apparently on some platforms when you run the stage1 , this means that you'll pick up all the /usr/local libs at runtime instead of the stage0-produced libs (causing errors until you uninstall rustc).
Accepted for 1.0, P-backcompat-lang.
Rust now builds and passes tests with . This feature could be disabled by default or completely removed, with as a suggestion for those who want to use a dynamically linked in their home directory on *nix.
Change:
<ins> // aux-build:generics_of_parent_impl_trait.rs #![feature(const_generics, const_evaluatable_checked)] #![allow(incomplete_features)] extern crate generics_of_parent_impl_trait; fn main() { // check for `impl Trait<{ const }>` which has a parent of a `DefKind::TyParam` generics_of_parent_impl_trait::foo([()]); //~^ error: type annotations needed: } </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. --I tried simplifying my code, but the code is quite complex and I wasn't able to recreate the ICE. Here is the repo which you can try building to see it for yourself: The main source of the issue is my Tensor structs which look similar to the below code. I have had issues with this . The ICE started happening after I convolution with fft. I to simplify writing the types. Maybe it's related? Sorry for the code mess; I didn't plan to show this code to other people. <!-- 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
Please add A-const-generics, F-constevaluatablechecked, and F-const_generics labels
Maybe related to , but I had this ICE already all the way back in 04/06/2021. Back then the error was
Smaller repro of ICE:
confirming potentially predates 1.56 nightly
Change:
format!("{}{}{}", consts::DLL_PREFIX, base, consts::DLL_SUFFIX) } <del> /// Optionally returns the filesystem path to the current executable which is </del> <ins> /// Optionally returns the filesystem path of the current executable which is </ins> /// running. If any failure occurs, None is returned. <del> pub fn self_exe_path() -> Option<Path> { </del> <ins> pub fn self_exe_name() -> Option<Path> { </ins> #[cfg(target_os = "freebsd")] fn load_self() -> Option<~[u8]> {

Discussion:
On OS X at least, it will think the link itself is the executable, then calculate sysroot based on that. Thanks to kyle for the report.
nominating to change to production ready
accepted for production-ready milestone
triage bump. still annoying.
or could be used to resolve the symlink. Would this issue warrant the badge "E_easy"?
Seems so! Adding the E-easy label.
Note that the relevant code is and it probably needs a check to see whether is a symlink or not.
seems important to fix for polish reasons. Accepted for P-high.
Change:
}; // strip all impls referencing stripped items <del> let mut stripper = ImplStripper { retained: &retained, cache: &cx.cache }; </del> <ins> let mut stripper = ImplStripper { retained: &retained, cache: &cx.cache, is_json_output, document_private: cx.render_options.document_private, }; </ins> stripper.fold_crate(krate) }

Discussion:
cc label +A-docs +A-rustdoc-ui +C-enhancement +T-rustdoc This is technically a regression, but it doesn't feel appropriate to label it as such.
Here is an example of a block that should be hidden when is not passed:
Change:
} } } <ins> (&ShouldPanic::Yes, Ok(())) => TrFailedMsg("test did not panic as expected".to_string()), </ins> _ if desc.allow_fail => TrAllowedFail, _ => TrFailed, }

Discussion:
When a fails because there was no panic it should produce an error message to that effect. For example, the following test: when run with produces the following output: There is no indication why it failed. Which can be problematic if the test itself is created by a macro. Example:
I'm not familiar with the code, but I'd guess that you just need to change in here: to . (And add a test to make sure it works.)
Thanks.I would like to work on this.
go ahead! If you have any questions, feel free to ask them here.
Hi.I've the in and trying to write a test but is this right approach?
actually, I think you can get away with just changing this line: to update it to your , because such a test already exists for this case.
Thanks
The previous fix was closed, so this issue is open again. The contains detailed instructions.
I'd like to finish this out if is no longer working on it.
Change:
_ if component.is_copy_modulo_regions(tcx.at(DUMMY_SP), self.param_env) => (), ty::Closure(_, substs) => { <del> for upvar_ty in substs.as_closure().upvar_tys() { queue_type(self, upvar_ty); } </del> <ins> queue_type(self, substs.as_closure().tupled_upvars_ty()); </ins> } ty::Generator(def_id, substs, _) => { let substs = substs.as_generator(); <del> for upvar_ty in substs.upvar_tys() { queue_type(self, upvar_ty); } </del> <ins> queue_type(self, substs.tupled_upvars_ty()); </ins> let witness = substs.witness(); let interior_tys = match witness.kind() {

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</detailsNOTE: The bug is found by our work-in-progress compiler testing tool Kira, and the test program is reduced/minimized by <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
does this still panic after ? That only merged a couple days ago so you'll need to update your version of nightly.
Hmm I checked and it does, and it also panics before. So probably unrelated? cc just in case
Note that this works fine on .
Sorry, I accidentally closed the issue. Yes, you are right. It still crashes on the latest nightly version. I have a cron job to update my rust version everyday.
I think we ended up (incorrectly) removing a check in We shouldn't be calling upvarsty if is . This is a separate issue than that was fixed in
claim
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. // aux-build:modify-ast.rs #![feature(proc_macro)] extern crate modify_ast; use modify_ast::*; #[derive(Foo)] pub struct MyStructc { #[cfg_attr(my_cfg, foo)] _a: i32, } macro_rules! a { ($i:item) => ($i) } a! { #[assert1] pub fn foo() {} } fn main() { let _a = MyStructc { _a: 0 }; foo(); } </ins>

Discussion:
I ran across a very curious case today... Given this procedural macro: and this expansion: when compiled I get: which is quite curious! -- er, just wrong thinking here cc cc cc
Seems similar to how also causes an inconsistency.
Ok I think I see what's going on here. This has to do with introduced in Basically I think this boils down to , we fundamentally cannot losslessly tokenize an AST item into a list of tokens to hand to a procedural macro. What's happening here is that all the tokens of the are saved off in the parser. This is the original source token stream which produced the struct. Later on when we tokenize the struct to hand off to a procedural macro we will use this cached token stream, if available, and tokenize it out and return it. When stringifying, however, we use the actual AST node itself (the source of truth). The bug is that cfg processing does indeed happen before the procedural macro runs. The cfg processing is modifying the AST item's internal fields but it's not invalidating the cached token stream or modifying it. Hence when the procedural macro runs the cached token stream is invalid wrt the internal state of the AST node, causing two different results to come out depending on how you look at it. Possible solutions here are: the cached list of tokens if the AST node is modified. This seems tricky to get right, are there other locations where a modification can happen? implemented , but holy cow that's a lot of work. the two results of tokenization (stringify + parse and the tokens themselves) and return the string one if they differ. None of them seem like great solutions :(
Change:
mod slice; mod str; mod string; <ins> mod task; </ins> mod thin_box; mod vec; mod vec_deque;

Discussion:
I would expect this to run to completion: On stable, it does: But not on current nightly: Interestingly, it works ok without cargo: The cargo project isn't special though: OS: macOS 13.6.3
cc I guess?
The internal function uses const promotion for the vtable in two places, once at initial construction and another when cloning. Maybe that results in two differently-addressed vtables.
I gave this a shot in . But without a language feature for statics with type parameters, we are not seeing a reliable way to restore 's functionality. Let's consider reverting . Having be a handful of CPU instructions faster but way more often wrong is not useful.
Change:
{ (s, " +") } else { <del> (span.shrink_to_hi(), ":") </del> <ins> (param.name.ident().span.shrink_to_hi(), ":") </ins> }; err.span_suggestion_verbose( span,

Discussion:
No response No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Another variant of this error I came up with using stable Edit Just tested on stable and . Both produced the same output.
claim
This is only tangentially related but just to give more context to anyone stumbling upon this issue: The diagnostic highlighting the entire path instead of only the type argument is tracked in .
Change:
<ins> // Copyright 2016 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. // compile-flags:--test /// ``` /// let a = r#" /// foo /// bar"#; /// let b = "nfoonbar"; /// assert_eq!(a, b); /// ``` pub fn main() { } </ins>

Discussion:
When using multiline string literal in doctest, rustdoc pads spaces after the newline. The doc renders perfectly fine: ! I tried this code: //! Hello world. //! //! # Examples //! //! //! //! fn main() { println!("hello world!"); } I expected to see this happen: The test should pass. Instead, this happened: The test failed. Did you notice it? : : Backtrace (I don't know if it'd be useful, but):
I hit this issue today as well with a similar case
Triaging: This is still happening on
Change:
use option::Option::{self, Some, None}; use result::Result::{Err, Ok}; use sync::{Mutex, Condvar, Arc}; <ins> use str::Str; </ins> use string::String; use rt::{self, unwind}; use old_io::{Writer, stdio};

Discussion:
I think this is fallout of , and it's somewhat unfortunate :( ! cc
Yup. Didn't think of that. So don't set the name of the main thread I suppose?
Yeah that may be the best option after all (sorry for recommending the opposite!)
Okay, no problem, I'll send PR...
Thanks!
Change:
<ins> trait Foo<T, T = T> {} //~^ ERROR the name `T` is already used for a generic parameter in this item's generic parameters fn eq<A, B>() { eq::<dyn, Foo> //~^ ERROR cannot find type `dyn` in this scope //~| ERROR missing generics for trait `Foo` //~| WARN trait objects without an explicit `dyn` are deprecated //~| WARN this is accepted in the current edition } 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
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
Change:
use rustc_index::bit_set::BitSet; use rustc_middle::mir::visit::{NonMutatingUseContext, PlaceContext, Visitor}; use rustc_middle::mir::{Body, Local, Location, Operand, Terminator, TerminatorKind, RETURN_PLACE}; <del> use rustc_middle::ty::{self, DeducedParamAttrs, ParamEnv, Ty, TyCtxt}; </del> <ins> use rustc_middle::ty::{self, DeducedParamAttrs, Ty, TyCtxt}; </ins> use rustc_session::config::OptLevel; /// A visitor that determines which arguments have been mutated. We can't use the mutability field

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. -- (requires release mode) <!-- 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. --: 1.70.0-nightly (2023-04-02 ) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details labels modify +F-specialization +requires-nightly +requires-incomplete-features
I understand how this ICE can come about, but I frankly cannot reproduce this. can you help out?
Ah, I apparently forgot to list that the ICE requires ; building without optimizations doesn't ICE.
label +F-specialization +requires-nightly +requires-incomplete-features
Change:
"one of supported relocation models (`rustc --print relocation-models`)"; pub const parse_tls_model: &str = "one of supported TLS models (`rustc --print tls-models`)"; <ins> pub const parse_target_feature: &str = parse_string; </ins> } #[allow(dead_code)]

Discussion:
I'm trying to pass multiple conditionally downstream. However, despite +/- for adding/removing a feature it appears only the last value takes effect.
FWIW, you can check for values without any test program like: $ rustc --print cfg -C target-feature=+avx2 -C target-feature=+fma $ rustc --print cfg -C target-feature=+avx2,+fma
I agree that it's a bug and will try to fix it.
Fixed in
Change:
// Which is valid in other languages, but not Rust. match self.parse_stmt_without_recovery(false) { Ok(Some(stmt)) => { <ins> if self.look_ahead(1, |t| t == &token::OpenDelim(token::Brace)) { // if the next token is an open brace (e.g., `if a b {`), the place- // inside-a-block suggestion would be more likely wrong than right return Err(e); } </ins> let mut stmt_span = stmt.span; // expand the span to include the semicolon, if it exists if self.eat(&token::Semi) {

Discussion:
this code currently emmits Could we detect explicitly if there are 2 unchained (via && or ) "variables" after an "if" and if the first one is "not" and explicitly suggest using "!" instead of "not" instead? meta: `