jiebi/CodeConvo huggingface dataset:
Change:
<!-- 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've lost so much of my life to this. It looks like the critical missing line is . I would expect this to happen whenever I pass .
The part of emitting is , which is called by . The bit emitting 'Copy ...' is . Notably, does not_ call .
This does not fix the issue and I'm not sure why:
It looks like bootstrap mistakenly thinks that the compiler has been linked and is cached.
So this is still a bug, but it turns out it wouldn't do what I want anyway because it doesn't build . So it would only be able to build crates with (basically nothing).
Yeah you want something like build --stage 1 src/libcore (though we don't support separate crate builds currently, but we could). I think it's not possible today to get bootstrap to copy the compiler but not build anything with it - the compiler itself isn't considered an artifact in some sense.
Right, this issue is asking that to change. I think this would still be useful for what I'm doing now which is only printing the AST and not even doing name resolution ().
Once this is fixed, the docs for in rustc-dev-guide () should be moved to .

Discussion:
match kind { Kind::Build => describe!( compile::Std, <del> compile::Rustc, </del> <ins> compile::Assemble, </ins> compile::CodegenBackend, compile::StartupObjects, tool::BuildManifest,

const DEFAULT: bool = false; fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { <del> run.path("compiler/rustc") </del> <ins> run.never() </ins> } fn make_run(run: RunConfig<'_>) {

impl Step for Assemble { type Output = Compiler; <ins> const ONLY_HOSTS: bool = true; </ins> fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { <del> run.never() </del> <ins> run.path("compiler/rustc") } fn make_run(run: RunConfig<'_>) { run.builder.ensure(Assemble { target_compiler: run.builder.compiler(run.builder.top_stage + 1, run.target), }); </ins> } /// Prepare a new compiler from the artifacts in `stage`
Change:
Hi there! With this code (here's a ) The compiler reports this error message with a hint but the hint is incorrect due to missing parantheses in this case. The correct answer would be It works correctly when the second line in main is executed, where the range is provided directly. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

Discussion:
// Check whether a span corresponding to a range expression is a // range literal, rather than an explicit struct or `new()` call. fn is_lit(sm: &SourceMap, span: &Span) -> bool { <del> let end_point = sm.end_point(*span); if let Ok(end_string) = sm.span_to_snippet(end_point) { !(end_string.ends_with('}') || end_string.ends_with(')')) } else { false } </del> <ins> sm.span_to_snippet(*span).map(|range_src| range_src.contains("..")).unwrap_or(false) </ins> }; match expr.kind {

<ins> type Range = std::ops::Range<usize>; fn demo(r: &Range) { println!("{:?}", r); } fn tell(x: usize) -> usize { x } fn main() { demo(tell(1)..tell(10)); //~^ ERROR mismatched types demo(1..10); //~^ ERROR mismatched types } </ins>

<ins> error[E0308]: mismatched types --> $DIR/issue-73553-misinterp-range-literal.rs:12:10 | LL |     demo(tell(1)..tell(10)); |          ^^^^^^^^^^^^^^^^^ |          | |          expected reference, found struct `std::ops::Range` |          help: consider borrowing here: `&(tell(1)..tell(10))` | = note: expected reference `&std::ops::Range<usize>` found struct `std::ops::Range<usize>` error[E0308]: mismatched types --> $DIR/issue-73553-misinterp-range-literal.rs:14:10 | LL |     demo(1..10); |          ^^^^^ |          | |          expected reference, found struct `std::ops::Range` |          help: consider borrowing here: `&(1..10)` | = note: expected reference `&std::ops::Range<usize>` found struct `std::ops::Range<{integer}>` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0308`. </ins>
Change:
I loaded the std doc at Firefox 77.0.1, then I typed fast for the word "true" (or click this link: ). I expected to see this happen: The search result appears and includes the "true" keyword link. Instead, this happened: No search result was shown. Also in the Firefox console, this was printed after typing the word "true": Version of std docs: 1.46.0-nightly ( 2020-06-21) cc in case you interest.
The type error happened along this line:
It looks like it fails when you have a crate filter selected. Almost certainly caused by (cc
yeah, that's right. I forgot about that detail.
should fix this.

Discussion:
var aliases = []; var crateAliases = []; var i; <del> if (filterCrates !== undefined && ALIASES[filterCrates] && ALIASES[filterCrates][query.search]) { for (i = 0; i < ALIASES[crate][query.search].length; ++i) { aliases.push( createAliasFromItem(searchIndex[ALIASES[filterCrates][query.search]])); </del> <ins> if (filterCrates !== undefined) { if (ALIASES[filterCrates] && ALIASES[filterCrates][query.search]) { for (i = 0; i < ALIASES[filterCrates][query.search].length; ++i) { aliases.push( createAliasFromItem( searchIndex[ALIASES[filterCrates][query.search][i]])); } </ins> } } else { Object.keys(ALIASES).forEach(function(crate) {

<ins> // exact-check const QUERY = 'true'; const FILTER_CRATE = 'some_other_crate'; const EXPECTED = { 'others': [], }; </ins>

<ins> #![feature(doc_alias)] #[doc(alias = "true")] pub struct Foo; </ins>

<ins> // exact-check const QUERY = 'true'; const FILTER_CRATE = 'doc_alias_filter'; const EXPECTED = { 'others': [ { 'path': 'doc_alias_filter', 'name': 'Foo', 'alias': 'true', 'href': '../doc_alias_filter/struct.Foo.html', 'is_alias': true }, ], }; </ins>

<ins> #![feature(doc_alias)] #[doc(alias = "true")] pub struct Foo; #[doc(alias = "false")] pub struct Bar; </ins>

break; } var entry = expected[key]; <ins> if (exact_check == true && entry.length !== results[key].length) { error_text.push(queryName + "==> Expected exactly " + entry.length + " results but found " + results[key].length + " in '" + key + "'"); } </ins> var prev_pos = -1; for (var i = 0; i < entry.length; ++i) { var entry_pos = lookForEntry(entry[i], results[key]);

} function runChecks(testFile, loaded, index) { <del> var loadedFile = loadContent( readFile(testFile) + 'exports.QUERY = QUERY;exports.EXPECTED = EXPECTED;'); </del> <ins> var testFileContent = readFile(testFile) + 'exports.QUERY = QUERY;exports.EXPECTED = EXPECTED;'; if (testFileContent.indexOf("FILTER_CRATE") !== -1) { testFileContent += "exports.FILTER_CRATE = FILTER_CRATE;"; } var loadedFile = loadContent(testFileContent); </ins> const expected = loadedFile.EXPECTED; const query = loadedFile.QUERY;
Change:
Documentation generated for and any code after is all strikethrough because of the . Generated doc: Associated src code: cc: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
modify labels: T-rustdoc C-bug
This is normal and expected markdown behavior. trait X<S{ fn f<T(); } impl<UX<Ufor U { fn f<V() {} } </SIt needs to be placed in a code block to avoid that (or use escapes).
It affecting that specific piece of item doc - expected behavior It affecting the rest of page - duplicate of
Duplicate of
I don't think this should be closed until the docs for are changed not to have strikethroughs everywhere.
Sure, adjusted the title to better reflect the scope of the issue.
claim
modify labels: -T-rustdoc +T-doc

Discussion:
/// /// For example given: /// <ins> /// ```no_run </ins> /// trait X<S> { fn f<T>(); } /// impl<U> X<U> for U { fn f<V>() {} } <ins> /// ``` </ins> /// /// * If `self` is `[Self, S, T]`: the identity substs of `f` in the trait. /// * If `source_ancestor` is the def_id of the trait.
Change:
Now that has been merged, only a few checks remain to be in order to stabilize this feature. First, we need to actually perform those checks in the compiler directly instead of rustdoc. You mentioned other checks too ? This issue is part of .
We should reject on items that don't actually appear in the search index such as blocks and s.
Ok, makes sense! Last question: I remember you telling that you'd prefer this check in rustc directly instead of rustdoc. I can move things there, just wanted to check one last time before doing it.
Yeah, rustc validates some attributes in and it might make sense to validate the attribute there as well.
Since has been merged, we can close this issue.
We're still not rejecting on associated s in trait impls like:
Ok! Putting on hold then!

Discussion:
None } } <ins> Target::AssocConst => { let parent_hir_id = self.tcx.hir().get_parent_item(hir_id); let containing_item = self.tcx.hir().expect_item(parent_hir_id); // We can't link to trait impl's consts. let err = "associated constant in trait implementation block"; match containing_item.kind { ItemKind::Impl { of_trait: Some(_), .. } => Some(err), _ => None, } } </ins> _ => None, } { self.tcx .sess .struct_span_err( meta.span(), <del> &format!("`#[doc(alias = "...")]` isn't allowed on {}", err,), </del> <ins> &format!("`#[doc(alias = "...")]` isn't allowed on {}", err), </ins> ) .emit(); }

<ins> #![feature(doc_alias)] #![feature(trait_alias)] pub struct Foo; pub trait Bar { const BAZ: u8; } impl Bar for Foo { #[doc(alias = "CONST_BAZ")] //~ ERROR const BAZ: u8 = 0; } impl Foo { #[doc(alias = "CONST_FOO")] // ok! pub const FOO: u8 = 0; pub fn bar() -> u8 { Self::FOO } } </ins>

<ins> error: `#[doc(alias = "...")]` isn't allowed on associated constant in trait implementation block --> $DIR/doc-alias-assoc-const.rs:11:11 | LL |     #[doc(alias = "CONST_BAZ")] |           ^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>
Change:
Code: Output in release mode: There is a similar issue about , but incorrect comparison of may be more dangerous. For example, if unsafe code checks the equality between to uphold its invariant, passing values obtained this way may break the invariant, even though the unsafe code itself didn't work with function pointers.
In some sense there's no bug here, this is expected: comparing function pointers should behave the same with or without the cast. What is more surprising is that they print the same. This indicates that comparison is non-deterministic... which is rather problematic indeed, and could break plenty of LLVM optimizations.
Indeed this can be turned into a demonstration of non-deterministic comparison: The second assertion fails, the first passes (in release mode on 1.45.2). That's no good. In principle this could lead to a soundness bug, though I am not sure if that can be actually done in practice. Cc
This is an LLVM bug:
But MIR optimizations also have to be aware that folding equality tests on functions is subtle (Cc And recently had to prevent me from making a similar mistake for pointer equality tests in CTFE (Cc
The LLVM bug has been fixed. (pinging you in lieu of there being a way to ping the LLVM WG), do you usually backport such fixes or wait for the next release?
cc (pinging LLVM WG) I suspect we'll want to backport the patch ourselves, and try to nominate it for LLVM 11 (since that's not yet released, and we're currently on a release candidate). is the thing to backport I think.
Assigning as discussed as part of the and removing .
Discussion on the LLVM bug is that it's too late for 11.0.0, but could be to 11.0.1. If someone wants to see the fix sooner in rust's fork, I'm happy to review PRs: https://rustc-dev-

Discussion:
[submodule "src/llvm-project"] path = src/llvm-project url = https://github.com/rust-lang/llvm-project.git <del> branch = rustc/11.0-2020-10-12 </del> <ins> branch = rustc/11.0-2021-01-05 </ins> [submodule "src/doc/embedded-book"] path = src/doc/embedded-book url = https://github.com/rust-embedded/book.git

<del> Subproject commit fb115ee43b77601b237717c21ab0a8f5b5b9d50a </del> <ins> Subproject commit f9a8d70b6e0365ac2172ca6b7f1de0341297458d </ins>

// Tests that we can compare various kinds of extern fn signatures. #![allow(non_camel_case_types)] <del> extern fn voidret1() {} extern fn voidret2() {} </del> <ins> // `dbg!()` differentiates these functions to ensure they won't be merged. extern fn voidret1() { dbg!() } extern fn voidret2() { dbg!() } </ins> extern fn uintret() -> usize { 22 }
Change:
<!-- 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 works with because the type is forbidden. However, it continues to ICE with .
No longer ICEs since

Discussion:
<ins> error: `&'static [u32]` is forbidden as the type of a const generic parameter --> $DIR/issue-73727-static-reference-array-const-param.rs:9:15 | LL | fn a<const X: &'static [u32]>() {} |               ^^^^^^^^^^^^^^ | = note: the only supported types are integers, `bool` and `char` = help: more complex types are supported with `#![feature(adt_const_params)]` error: aborting due to previous error </ins>

<ins> // Regression test for #73727 // revisions: full min //[full]check-pass #![cfg_attr(full, feature(adt_const_params))] #![cfg_attr(full, allow(incomplete_features))] fn a<const X: &'static [u32]>() {} //[min]~^ ERROR `&'static [u32]` is forbidden as the type of a const generic parameter fn main() { a::<{&[]}>(); } </ins>

<del> fn a<const X: &'static [u32]>() {} //~^ ERROR `&'static [u32]` is forbidden as the type of a const generic parameter fn main() { a::<{&[]}>(); } </del>

<del> error: `&'static [u32]` is forbidden as the type of a const generic parameter --> $DIR/static-reference-array-const-param.rs:1:15 | LL | fn a<const X: &'static [u32]>() {} |               ^^^^^^^^^^^^^^ | = note: the only supported types are integers, `bool` and `char` = help: more complex types are supported with `#![feature(adt_const_params)]` error: aborting due to previous error </del>
Change:
Context: this bug was reduced from indexing into a nested array, but this shows the same problem. () Rust doesn't elide the bounds check on , even though it's impossible for to be out of range due to the if condition. Rust does elide the bounds check when the if condition is just , however. Here is the generated ASM for the above code: and here is the generated ASM when we change the if to just be This occurs in both the latest versions of stable (1.44.1) and nightly (1.46.0-nightly (2020-06-26 ))
It seems that the bounds check does get elided if I split up the if expression. This generates
And it seems it needs two unlikely to produce the right happy path:
The assume intrinsic also seems to not work if a logical expression is used, maybe it's related? I.e. does not make subsequent bounds checks go away but 2 assumes do.
Godbolt: The problem is that the condition is converted to , at which point implication no longer works. It should be straightforward to teach LVI about this special case.
Fix has landed upstream, we'll pull it in with the LLVM 11 upgrade.
This if fixed in 1.47 with the LLVM 11 upgrade. It's probably worthwhile to add a codegen test, as bounds check optimization tends to be a bit fragile.
Great, thanks! I can handle the test

Discussion:
<ins> // This test checks that bounds checks are elided when // index is part of a (x | y) < C style condition // min-llvm-version: 11.0.0 // compile-flags: -O #![crate_type = "lib"] // CHECK-LABEL: @get #[no_mangle] pub fn get(array: &[u8; 8], x: usize, y: usize) -> u8 { if x > 7 || y > 7 { 0 } else { // CHECK-NOT: panic_bounds_check array[y] } } </ins>
Change:
I wanted to move out a number of front element from a vector, like but I wonder if this is the right way to do this cause doc is unclear, note 1 and note 2 say the opposite each other: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
"partially consumed" means taking a few elements out and then dropping the value. Note 2 talks specifically about leaking the value. Is there any way to make this more clear in the docs?
What leaked mean for you ? How would I leak drain struct ? Drop it ?
No, leaking means specifically destroying a value without running its destructor, for example via 
So I think write: Because in the current form the two note look like they apply both whereas it's two difference case, leaked or not. (I'm not sure leak is the good word here for me leak mean leak memory not forget it, so maybe say "without run it's destructor" is more clear)
I myself am familiar with this usage of "to leak", but I don't know how I picked up that, why this is called leaking, or where it's explained in the docs. I suspect that this usage originates from smart pointers, for which destroying them without running destructors would leak the referenced objects. If we generalize this to something that is not a smart pointer, it's called jargon. Although it's convenient to use (in fact, there are more than ten instances of this usage in the standard library), it's not something we can expect to be understood for sure. For this reason, I agree with Replacing the word with something like “destroyed without running its destructor” or at least adding a reference to in parentheses would make sense.
claim

Discussion:
/// Creates a draining iterator that removes the specified range in the vector /// and yields the removed items. /// <del> /// Note 1: The element range is removed even if the iterator is only /// partially consumed or not consumed at all. /// /// Note 2: It is unspecified how many elements are removed from the vector /// if the `Drain` value is leaked. </del> <ins> /// When the iterator **is** dropped, all elements in the range are removed /// from the vector, even if the iterator was not fully consumed. If the /// iterator **is not** dropped (with [`mem::forget`] for example), it is /// unspecified how many elements are removed. </ins> /// /// # Panics ///
Change:
<!-- 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 code fails to pass <!-- 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. --Repo is at <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Oh that is interesting: is that expected? The other way around would make sense (assigning a into anything, really), but with a on the left, that seems odd? Or maybe the message just gets the sides wrong.
Yeah, that MIR looks really broken: Cc
This is probably due to this line: , and shouldn't have this, since they have type , not .
This is a super old issue going back all the way to the initial MIR implementation and I’m somewhat confident is documented somewhere, though I cannot find an issue for this. IIRC these invalid assignments only happen in unreachable basic blocks, so however wrong it looks in isolation, it is dead code and I think it never was a priority to fix either generation or the MIR validation we had back then for exactly that reason. Looks like is a new take on validation? Perhaps the easy fix would be to not validate unreachable blocks.

Discussion:
let ptr_ty = ptr.ty; // Create an *internal* temp for the pointer, so that unsafety // checking won't complain about the raw pointer assignment. <del> let ptr_temp = this.local_decls.push(LocalDecl::with_source_info( ptr_ty, source_info, ).internal()); </del> <ins> let ptr_temp = this .local_decls .push(LocalDecl::with_source_info(ptr_ty, source_info).internal()); </ins> let ptr_temp = Place::from(ptr_temp); let block = unpack!(this.into(ptr_temp, block, ptr)); this.into(this.hir.tcx().mk_place_deref(ptr_temp), block, val)

Some((destination, success)) }, from_hir_call, <del> fn_span </del> <ins> fn_span, </ins> }, ); success.unit()

// These cases don't actually need a destination ExprKind::Assign { .. } | ExprKind::AssignOp { .. } <del> | ExprKind::Continue { .. } | ExprKind::Break { .. } | ExprKind::LlvmInlineAsm { .. } | ExprKind::Return { .. } => { </del> <ins> | ExprKind::LlvmInlineAsm { .. } => { </ins> unpack!(block = this.stmt_expr(block, expr, None)); this.cfg.push_assign_unit(block, source_info, destination, this.hir.tcx()); block.unit() } <ins> ExprKind::Continue { .. } | ExprKind::Break { .. } | ExprKind::Return { .. } => { unpack!(block = this.stmt_expr(block, expr, None)); // No assign, as these have type `!`. block.unit() } </ins> // Avoid creating a temporary ExprKind::VarRef { .. } | ExprKind::SelfRef

} bb10: { <del> _4 = const ();                   // scope 0 at $DIR/issue-49232.rs:10:25: 10:30 // ty::Const // + ty: () // + val: Value(Scalar(<ZST>)) // mir::Constant // + span: $DIR/issue-49232.rs:10:25: 10:30 // + literal: Const { ty: (), val: Value(Scalar(<ZST>)) } </del> unreachable;                     // scope 0 at $DIR/issue-49232.rs:10:25: 10:30 }
Change:
<!-- 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. --When trying to cast a slice, I encountered an ICE in nightly rust. It works in at least two different nightly versions: rustc 1.46.0-nightly ( 2020-06-26) and rustc 1.46.0-nightly ( 2020-06-29). I haven't tested any other versions. In stable rust (1.44.1), no ICE occurs. A minimal example to reproduce this is here: I expected the following result: Instead, I encountered an ICE. From the little testing I have done, it seems to require slices for the ICE to occur. Replacing the slices with structs causes the ICE to disappear. I got the ICE to work with the following two versions: : and It might work with earlier versions of nightly as well, but I haven't checked this. It does not occur with the latest stable version (1.44.1). <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Let’s try to find the culprit for this. ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
searched nightlies: from nightly-2020-06-19 to nightly-2020-06-27 regressed nightly: nightly-2020-06-20 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details modify labels: -E-needs-bisection
Probably cc
Prioritized as as per .

Discussion:
// Check for infer types because cases like `Option<{integer}>` would // panic otherwise. if !expr_ty.has_infer_types() <ins> && !ty.has_infer_types() </ins> && fcx.tcx.type_implements_trait(( from_trait, ty,

<ins> fn main() { let _ = &&[0] as &[_]; //~^ ERROR non-primitive cast: `&&[i32; 1]` as `&[_]` let _ = 7u32 as Option<_>; //~^ ERROR non-primitive cast: `u32` as `std::option::Option<_>` } </ins>

<ins> error[E0605]: non-primitive cast: `&&[i32; 1]` as `&[_]` --> $DIR/issue-73886.rs:2:13 | LL |     let _ = &&[0] as &[_]; |             ^^^^^^^^^^^^^ an `as` expression can only be used to convert between primitive types or to coerce to a specific trait object error[E0605]: non-primitive cast: `u32` as `std::option::Option<_>` --> $DIR/issue-73886.rs:4:13 | LL |     let _ = 7u32 as Option<_>; |             ^^^^^^^^^^^^^^^^^ an `as` expression can only be used to convert between primitive types or to coerce to a specific trait object error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0605`. </ins>