jiebi/CodeConvo huggingface dataset:
Change:
deprecation: stability::lookup_deprecation(tcx, did).clean(cx), def_id: did, }); <ins> } </ins> <del> fn is_doc_hidden(a: &clean::Attribute) -> bool { match *a { clean::List(ref name, ref inner) if *name == "doc" => { inner.iter().any(|a| { match *a { clean::Word(ref s) => *s == "hidden", _ => false, } }) } _ => false </del> <ins> fn is_doc_hidden(a: &clean::Attribute) -> bool { match *a { clean::List(ref name, ref inner) if *name == "doc" => { inner.iter().any(|a| { match *a { clean::Word(ref s) => *s == "hidden", _ => false, } }) </ins> } <ins> _ => false </ins> } }

Discussion:
The link to "FullOps" on this page is broken:
Background for anyone who wants to tackle this: is an unstable trait defined in a module of (specifically in ). It is an implementation detail that should not leak out. Because of the above, the fix is to not list the trait on the implementing type's page, not to generate a doc page for . Other examples of such traits are and on and , which are also listed on the respective pages with dead links.
I want to give it a try, however i don't know what is the right way to test changes. How can i build only the related docs? Make docs rebuilds everything, so it takes a while (even with the flag). How can i quickly test the html output for the docs without rebuilding everything? I tried rustdoc 'path/to/file' too, but it is not able to compile the doc for that given file
Unfortunately, this kind of change is just going to take forever to test. :/ You have to point it at a crate root, not just any rust file.
:( I will give a try to rustdoc once more. Compilations on my machine take around 1 hour, so i don't know if i can fix something that way.
I believe I have an explanation. The annotation on the modules ensures no documentation is created for the module or any traits or similar contained within it. However, when assessing whether s should be hidden on other pages the documentation compiler considers only the hiddenness of the itself, not its containing module. I suspect the existing behaviour is working as intended—consider the case of someone putting their (given public types Foo and Bar) in a doc-hidden module and then wondering where the went. I recommend the simple fix of putting on the s of the public-not-public traits.
Thanka for tracking this down! You are right that impls in private modules should generally be displayed since they are public in a sense. But I think the current state of affairs is very unsatisfying, since Rustdoc generates broken docs for perfectly valid code. Shouldn't it at the very least somit links that will wind up dead? And if both trait and implementing type are dic(hidden), as is the case here, it seems like a reasonable heuristic to treat the impl as hidden too.

I'm less sure about hidden traits in public types (e.g., RawFloat and f64) but if it's overridable it also seems sensible.
Putting my real-world-concerns hat on, I think this is really just a corner case where and “public” don't coincide. The Right Thing is to propagate from traits to s of those traits; I don't know how difficult that is to do, so I opted for recommending a simple fix which I'd confirmed to work.
Change:
<ins> - // MIR for `main` before GVN + // MIR for `main` after GVN fn main() -> () { let mut _0: (); let _1: bool; let mut _2: *mut u8; scope 1 (inlined dangling_mut::<u8>) { let mut _3: usize; scope 2 (inlined align_of::<u8>) { } scope 3 (inlined without_provenance_mut::<u8>) { } } scope 4 (inlined Foo::<u8>::cmp_ptr) { let mut _4: *const u8; let mut _5: *mut u8; let mut _6: *const u8; scope 5 (inlined std::ptr::eq::<u8>) { } } bb0: { StorageLive(_1); StorageLive(_2); StorageLive(_3); -         _3 = AlignOf(u8); -         _2 = _3 as *mut u8 (Transmute); +         _3 = const 1_usize; +         _2 = const {0x1 as *mut u8}; StorageDead(_3); StorageLive(_4); StorageLive(_5); -         _5 = _2; -         _4 = _2 as *const u8 (PtrToPtr); +         _5 = const {0x1 as *mut u8}; +         _4 = const {0x1 as *const u8}; StorageDead(_5); StorageLive(_6); -         _6 = const Foo::<u8>::SENTINEL as *const u8 (PtrToPtr); -         _1 = Eq(_4, _6); +         _6 = const {0x1 as *const u8}; +         _1 = const true; StorageDead(_6); StorageDead(_4); StorageDead(_2); StorageDead(_1); _0 = const (); return; } } </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. --Compiling the following code with results in ICE. Strangely, this code compiles fine without . Replace with plain comparison also works. : <!-- 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
This seems to bisect to cc
Thanks for the ping! I'll take a look. I thought I'd checked for this with , but clearly I missed something.
Change:
<ins> // Copyright 2013-2014 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. trait I {} type K = I; //~ ERROR: reference to trait fn main() {} </ins>

Discussion:
This code is wrong because ToStr does not define . But what's odd is that the compiler error does not happen in the block but in the : Error message: The expected error message would point to the block that needs to be split into two (one with ToStr and one without a trait).
Reproduced as of
Repro'd with -- but not critical for 0.6, de-milestoning
Appears to be fixed, as per this updated test case: fails with . Closing.
We've regressed: there's a test case (), but it's been xfailed since it was . With I see:
Aaaand, we've un-regressed! Removing all tags except for neesdtest.
Whoops, had the wrong code example, regression still here.
Change:
self.fail(location, "adt has the wrong number of initialized fields"); } for (src, dest) in std::iter::zip(fields, &variant.fields) { <del> if !self.mir_assign_valid_types( src.ty(self.body, self.tcx), dest.ty(self.tcx, args), ) { </del> <ins> let dest_ty = self .tcx .normalize_erasing_regions(self.param_env, dest.ty(self.tcx, args)); if !self.mir_assign_valid_types(src.ty(self.body, self.tcx), dest_ty) { </ins> self.fail(location, "adt field has the wrong type"); } }

Discussion:
<!-- [31mICE[0m: Rustc '-Zvalidate-mir -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at ', 'thread 'rustc' panicked at ' File: --auto-reduced (treereduce-rust): original: Version information Command: &lt;!-- Include a backtrace in the code block by setting in your environment. E.g. . --&lt;details&lt;summary&lt;strongProgram output&lt;/strong&lt;/summary&lt;p&lt;/p&lt;/details&lt;!-- query stack: [mirconst] preparing for borrow checking [mirpromoted] promoting constants in MIR for [mirborrowck] borrow-checking [typeofopaque] computing type of opaque [typeof] computing type of [checkwellformed] checking that is well-formed [checkmodtype_wf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
&lt;!-- [31mICE[0m: Rustc '-Zvalidate-mir -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at ', 'thread 'rustc' panicked at ' File: --auto-reduced (treereduce-rust): original: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [mirconst] preparing for borrow checking [mirpromoted] promoting constants in MIR for [mirborrowck] borrow-checking [typeofopaque] computing type of opaque [typeof] computing type of [checkwellformed] checking that is well-formed [checkmodtype_wf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
This ices since by but I dont see any of the error messages which is weird
ICE happens before any of those error messages would be fired. I'll fix it later.
Change:
} fn is_copy_raw<'tcx>(tcx: TyCtxt<'tcx>, query: ty::ParamEnvAnd<'tcx, Ty<'tcx>>) -> bool { <del> let (param_env, ty) = query.into_parts(); let trait_def_id = tcx.require_lang_item(lang_items::CopyTraitLangItem, None); tcx.infer_ctxt() .enter(|infcx| traits::type_known_to_meet_bound_modulo_regions( &infcx, param_env, ty, trait_def_id, DUMMY_SP, )) </del> <ins> is_item_raw(tcx, query, lang_items::CopyTraitLangItem) </ins> } fn is_sized_raw<'tcx>(tcx: TyCtxt<'tcx>, query: ty::ParamEnvAnd<'tcx, Ty<'tcx>>) -> bool { <del> let (param_env, ty) = query.into_parts(); let trait_def_id = tcx.require_lang_item(lang_items::SizedTraitLangItem, None); tcx.infer_ctxt() .enter(|infcx| traits::type_known_to_meet_bound_modulo_regions( &infcx, param_env, ty, trait_def_id, DUMMY_SP, )) </del> <ins> is_item_raw(tcx, query, lang_items::SizedTraitLangItem) </ins> } fn is_freeze_raw<'tcx>(tcx: TyCtxt<'tcx>, query: ty::ParamEnvAnd<'tcx, Ty<'tcx>>) -> bool { <ins> is_item_raw(tcx, query, lang_items::FreezeTraitLangItem) } fn is_item_raw<'tcx>( tcx: TyCtxt<'tcx>, query: ty::ParamEnvAnd<'tcx, Ty<'tcx>>, item: lang_items::LangItem, ) -> bool { </ins> let (param_env, ty) = query.into_parts(); <del> let trait_def_id = tcx.require_lang_item(lang_items::FreezeTraitLangItem, None); </del> <ins> let trait_def_id = tcx.require_lang_item(item, None); </ins> tcx.infer_ctxt() .enter(|infcx| traits::type_known_to_meet_bound_modulo_regions( &infcx,

Discussion:
See: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'm interested in taking this!
assign
Change:
<ins> // Copyright 2015 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. struct Test; struct Test2(Option<Test>); impl Drop for Test { fn drop(&mut self) { println!("dropping!"); } } impl Drop for Test2 { fn drop(&mut self) {} } fn stuff() { let mut x : (Test2, Test2); (x.0).0 = Some(Test); //~^ ERROR partial reinitialization of uninitialized structure `x.0` } fn main() { stuff() } </ins>

Discussion:
So I was curious how Drop handles cycles, because this could lead to dangling pointers, which is why . And indeed the below example does not call Drop. But is moved into , so why does this compile at all?
Nominating, seems like a soundness hole.
This is an issue with zeroing dynamic drops (which are going to be removed: rust-lang/rfcs) – when is moved, its drop flag is cleared, which prevents the destructor of from running. A clearer example is:
Structs that implement drop are not supposed to be in a partially initialized state. We already prevents moves out from individual fields, but we also need to prevent individual fields from being re-initialized. cc since (iirc?) he was working on the patches that made us more accepting around re-initializing fields and so forth, and maybe this bug is of interest to him.
So we are not supposed to allow structs that implement drop to be partially initialized. We already disallow going from fully-initialized to partially initialized. But it seems (from the first example) that we missed disallowing going from fully-uninitialized to partially initializd. That needs to be fixed. Assigning P-backcompat-lang, 1.0.
While this will hopefully be fixed soon, as there is a PR up, it seems to have fallen through the cracks as a P-backcompat-lang issue that is only on the 1.0 milestone and not 1.0 beta. Nominating for 1.0 beta. (Also, I guess I will try to run through and find any other such overlooked issues.)
Assigning 1.0 beta.
Change:
if let Some(env) = maybe_env { let mut blk = Vec::new(); <ins> // If there are no environment variables to set then signal this by // pushing a null. if env.is_empty() { blk.push(0); } </ins> for (k, v) in env { blk.extend(ensure_no_nuls(k.0)?.encode_wide()); blk.push('=' as u16);

Discussion:
Running with will reproducibly result in Error with OS code 87. if is omitted, it works:
This is expected behavior because it appears that there are basically some required environment variables on Windows to get subprocesses to work. For example and which seems to match as well
Should we ensure that on windows we pass these variables through regardless of being specified? Otherwise, we should at least document this behaviour.
Perhaps yeah. In the past our spawning tended to mirror libuv closely (where it all originated from), but we've since backpedaled a bit from that original design. From a systems-y perspective I would prefer that actually clear the environment, but from a "let's make this ergonomic to use" perspective it'd make more sense to only clear non-required environment variables. I'd probably personally be fine either way
is used to create a new environment block. If is passed for then the returned block will "start from a clean state". If we're going to preserve a few required environment variables, might as well get them straight from the system rather than inheriting them.
Sounds reasonable to me!
I feel like this isn't a change we can make backwards compatibly. What are the considerations that are involved in making this change? Can we make it? We at least need documentation for this inconsistency, but I'm not sure what tag to use for those issues: ?
I think we've got leeway to change the implementation on Windows to preserve some environment variables. If a process can just literally not be spawned without an environment variable then we're basically guaranteed to not break anyone if we start preserving it by default on . Existing working code would override it anyway (as it'd specify a value for the variable)
See the discussion in PowerShell/PowerShell.
The issue is closed, but with the fix related to running process on windows with empty environment that seems not quite exactly as described Using on windows is still unusable in most cases and leads to the cryptic errors like
Can you open a new issue?
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. // only-x86_64 #![allow(dead_code, non_upper_case_globals)] #![feature(asm)] #[repr(C)] pub struct D32x4(f32,f32,f32,f32); impl D32x4 { fn add(&self, vec: Self) -> Self { unsafe { let ret: Self; asm!(" movaps $1, %xmm1 movaps $2, %xmm2 addps %xmm1, %xmm2 movaps $xmm1, $0 " : "=r"(ret) : "1"(self), "2"(vec) : "xmm1", "xmm2" ); ret } } } fn main() { } </ins>

Discussion:
Even more minimal test case: The parser for some reason is expecting a pattern by end of the second .
The ICE is fixed in nightly.
Change:
<del> Subproject commit 7973f3560287d750500718314a0fd4025bd8ac0e </del> <ins> Subproject commit 84f190a4abf58bbd5301c0fc831f7a96acea246f </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. --Note that I can’t reproduce this SIGILL with , only sandybridge or higher (including native). The crate I wanted to build is , here is a minimal version: <!-- 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
LLVM assertion:
Upstream issue:
label llvm-fixed-upstream

Fuzzer generated custom MIR This code has UB under Stacked Borrows, but UB-free under Tree Borrows. Right: Wrong: While it looks like an LLVM issue, I couldn't get an IR-only reproduction. It's possible that rustc is producing IR with UBs On latest nightly cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I am only refraining from adding I-unsound so far because there's no surface Rust repro yet.
We should get , but we get .
claim
Upstream issue:
I do not have such qualms, especially because a fix is already on the way.
WG-prioritization assigning priority (). Keeping an eye on this issue to evaluate what to do when the LLVM fix lands label -I-prioritize +P-high

I tried this code: I expected to see this happen: Both and can be inlined. Instead, this happened: <details<summarycargo asm</summary</detailsWhen using , it works well. Also, when I replace with , it works well. <details<summarycargo asm</summary</details:
I think this is an llvm issue related to inlining when the target features do not match exactly and when using inline assembly: is implemented using asm and has . This seems to prevent it getting inlined into functions with additional target features. When compiling for a specific target with all these features enabled it should get inlined, but this restriction makes it very difficult to implement runtime dispatch and get performant code. I'm currently facing the same issue, and plan to replace the asm implementation with one that uses the new rust intrinsic, but this only solves the problem for masked loads/stores. The problem also exists for the implementations of , for which there is not yet a rust intrinsic.
Change:
<ins> error[E0107]: wrong number of type arguments: expected 1, found 0 --> $DIR/issue-76595.rs:15:5 | LL |     test::<2>(); |     ^^^^^^^^^ expected 1 type argument error: constant expression depends on a generic parameter --> $DIR/issue-76595.rs:15:5 | LL | fn test<T, const P: usize>() where Bool<{core::mem::size_of::<T>() > 4}>: True { |                                                                           ---- required by this bound in `test` ... LL |     test::<2>(); |     ^^^^^^^^^ | = note: this may fail depending on what value the parameter takes error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0107`. </ins>

Discussion:
I got a little excited with merged, soooo I gave it a try, and I found this rather funny ICE. Notice how I call , without a type parameter, while the function expects a type parameter. <!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
yeah, that ICE is interesting :thinking: and why is it only triggered with ? claim

() Errors: Probably related: Removing (at least) one of the s for makes the panic go away, and the compiler correctly reports the error: modify labels: I-ICE, T-compiler, A-const-eval, A-const-generics, C-bug, F-const_generics, requires-nightly
That's happening here: I don#t think there is a meaningful way to evaluate a polymorphic constant, so either some code earlier screwed up to even get so far, or we need to throw here. Cc
cc This ICE is totally expected. Using features that emit the lint are expected to ICE, otherwise they would not emit said lint. The const evaluator is not at fault here, there's just no way to evaluate this.
hmm, we shouldn't try to evaluate this constant here or at least have it be a instead of a . Not quite sure what's going on here, will have to look at it in more detail soon
So we probably fail here because we call with a which get's canonicalized to a . All of that seems correct to me :thinking: Is it possible that we should treat similar to and "just" return here?

<!-- 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. --Code from glacier: <!-- 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
NB: Only panics for me with the flag.
Change:
error: expected one of `!`, `+`, `->`, `::`, `;`, or `=`, found `.` <del> --> $DIR/recover-colon-instead-of-eq-in-local.rs:2:32 </del> <ins> --> $DIR/recover-colon-instead-of-eq-in-local.rs:5:32 | LL |     let _: std::env::temp_dir().join(&self, push: Box<usize>); |          -                     ^ expected one of `!`, `+`, `->`, `::`, `;`, or `=` |          | |          while parsing the type for `_` error: expected one of `!`, `+`, `->`, `::`, `;`, or `=`, found `.` --> $DIR/recover-colon-instead-of-eq-in-local.rs:9:32 </ins> | LL |     let _: std::env::temp_dir().join("foo"); |          -                     ^ expected one of `!`, `+`, `->`, `::`, `;`, or `=`

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at ', 'thread 'rustc' panicked at ' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: --
cc
Change:
error[E0027]: pattern does not mention field `name` <del> --> $DIR/E0027.rs:10:9 </del> <ins> --> $DIR/E0027.rs:11:9 </ins> | LL |         Dog { age: x } => {} |         ^^^^^^^^^^^^^^ missing field `name`

Discussion:
I tried this code: I expected to see this happen: A suggestion to change to Instead, this happened: A suggestion to change to (note the extra comma!) With the comma at the end, I get a parser error and a suggestion to remove the comma. Nightly on playground: 1.49.0-nightly (2020-10-27 )
modify labels: +A-diagnostics