jiebi/CodeConvo huggingface dataset:
Change:
if let Some(candidate) = candidates.get(0) { let path = { // remove the possible common prefix of the path <del> let start_index = (0..failed_segment_idx) .find(|&i| path[i].ident != candidate.path.segments[i].ident) </del> <ins> let len = candidate.path.segments.len(); let start_index = (0..=failed_segment_idx.min(len - 1)) .find(|&i| path[i].ident.name != candidate.path.segments[i].ident.name) </ins> .unwrap_or_default(); <del> let segments = (start_index..=failed_segment_idx) .map(|s| candidate.path.segments[s].clone()) .collect(); </del> <ins> let segments = (start_index..len).map(|s| candidate.path.segments[s].clone()).collect(); </ins> Path { segments, span: Span::default(), tokens: None } }; (

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'index out of bounds: the len is 1 but the index is 1'', 'thread 'rustc' panicked at 'index out of bounds: the len is 1 but the index is 1'' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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: [resolverforlowering_raw] getting the resolver for lowering --
I suspect this could be cc
what's the command line to reproduce it? I build nightly version and cannot reproduce it by only compiling the code. also I checked playground:
Ok, got it, we can not use 2021 edition in the command line.
Change:
|err: &mut DiagnosticBuilder<'_>, found_to_exp_is_fallible: bool, exp_to_found_is_fallible: bool| { <ins> let exp_is_lhs = expected_ty_expr.map(|e| self.tcx.hir().is_lhs(e.hir_id)).unwrap_or(false); if exp_is_lhs { return; } </ins> let always_fallible = found_to_exp_is_fallible && (exp_to_found_is_fallible || expected_ty_expr.is_none()); let msg = if literal_is_ty_suffixed(expr) {

Discussion:
I try this code: () I expect to see this happen: No invalid suggestion for . Instead, I got this errors: label D-invalid-suggestion T-compiler
Change:
if let Some(ref s) = build.config.rustc_default_ar { cargo.env("CFG_DEFAULT_AR", s); } <del> build.run(&mut cargo); update_mtime(build, &librustc_stamp(build, compiler, target)); </del> <ins> run_cargo(build, &mut cargo, &librustc_stamp(build, compiler, target)); </ins> } /// Same as `std_link`, only for librustc

Discussion:
Rustbuild compiles the compiler in a particular location and is then responsible for copying artifacts over to the actual structure the compiler is expecting (e.g. rustbuild assembles a sysroot). In order to handle stale folders rustbuild , deduplicated by hash. This pretty obviously, though, doesn't work with multiple versions of the same library! We should probably call Cargo with and learn about compiled artifacts, that way we can copy precisely what we need to into the sysroot.
Change:
}; // FIXME(#67563): Provide more context for these errors by displaying the spans inline. <del> for message in buffered_messages.borrow().iter() { </del> <ins> for message in buffer.messages.iter() { </ins> diag.note(&message); }

Discussion:
In , we would like to tweak the structure of the tokens rustc uses. One of the components which heavily depends on the current structure is ( and module use ). I think, for this issue and in general, it makes sense to switch over to , which produces lower-level guaranteed lossless tokens, which look like a better fit for the task of syntax highlighting. I plan to do this refactor myself, but I want to check with if this is a good idea. EDIT: cc
sgtm
I'm fine with it as well. :)
BTW, is there some chat room for rustdoc team on zulip on discord? I'd like to ask some questions :)
There is one on discord (simply called "rustdoc").
It's linked at (which is I agree pretty hard to find). Also the text there is wrong and mentions , we should probably fix that.
Change:
<ins> // Copyright 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. fn blah() -> int { //~ ERROR not all control paths return a value 1i ; //~ NOTE consider removing this semicolon: } fn main() { } </ins>

Discussion:
Here is a very simple program which employs trait objects: : : : When this program is compiled and run, it fails with segmentation fault: This program is not correct. You can see that function produces a for arbitrary lifetime , but the local variable is valid only for body. A pointer to , however, is saved to the , and when it is accessed inside , a segmentation fault occurs. However, Rust still compiles it. I thought that borrowing checker should prevent this kind of errors. BTW, I can write or and it will compile either way, but I thought that when going from plain pointers to trait objects I should always specify exact kind of trait object. Not sure that I'm right here thought.
cc
Sounds similar to ; potential duplicate?
This appears to be fixed: Original example code updated to current rust: : : :
Awesome! flagging as needstest (not sure if one already exists)

(Doesn't happen with .)
Paging
Here's a truly minimal test case:
cc me
Variation: This gives a different error message:
Fixed in Can be closed.
Change:
mod dep_tracking { use lint; use middle::cstore; <del> use session::search_paths::{PathKind, SearchPaths}; </del> use std::collections::BTreeMap; use std::hash::Hash; use std::path::PathBuf; use std::collections::hash_map::DefaultHasher; use super::{Passes, CrateType, OptLevel, DebugInfoLevel, Lto, <del> OutputTypes, Externs, ErrorOutputType, Sanitizer, Epoch}; </del> <ins> OutputTypes, ErrorOutputType, Sanitizer, Epoch}; </ins> use syntax::feature_gate::UnstableFeatures; use rustc_back::{PanicStrategy, RelroLevel};

Discussion:
I was trying to determine if sccache could cache crates built as dependencies of different root crates. When I looked into it I found that the rlibs were not bit-identical despite being built from the same source. Most of the differences were in the debug info because the current directory winds up encoded there. I tried using which removed most of the differences but not all. A small difference in the metadata remains, which from looking at the diff of the serialized metadata said was the . do you know why this would be? I built this twice in different directories using the script. The diff of the rlib from each build (I generated that using .) Presumably this would block and also
Lots of stuff goes into the SVH. It might well be that something directory related accidentally goes into it. The SVH is computed here:
cc This is similar to the GCC build-path issue where other programs (and in the past, GCC's DWATproducer) likes to embed CFLAGS into the output. Suggested options: out -Zremap-path-prefix away from that SVH calculation - but other programs that also embed RUSTFLAGS or similar, would also need similar logic the envvar or something similar cargo support a constant flag (whose value does not depend on build-path) that figures out the right -Zremap-path-prefix for rustc so they don't need to appear in RUSTFLAGS. you'd also need to implement (1) but at least the caveat (about other programs) doesn't apply.
addresses (1), which is kind of orthogonal to (2) and (3) because the SVH will always be part of the output binary and it must change if the result of the mapping changes.
With the latest Rust nightly: which includes the fix from , the outputs from are still not the same:
I think we may still be hashing arguments?
Yes, it seems we do: Good catch! Not sure if we have to hash those at this point. The tracking system should catch resulting changes later on, if we don't have any holes in the tracking. This needs some review.
Edit: never mind - seems fixed now that I've rebased to master. I found that (after implementing it) still affects the SVH, even if the mapping does nothing: will generate different metadata hashes if I change the mapping, even though it doesn't affect anything and nothing else changes.
Change:
//! //! This module implements generation for all bits and pieces of documentation //! for the Rust project. This notably includes suites like the rust book, the <del> //! nomicon, standalone documentation, etc. </del> <ins> //! nomicon, rust by example, standalone documentation, etc. </ins> //! //! Everything here is basically just a shim around calling either `rustbook` or //! `rustdoc`.

Discussion:
This is an issue for moving Rust By Example, which is currently at , to . I will be working on the first step shortly. [x] Convert RBE to a submodule under [x] Add RBE to the bookshelf (thanks [x] Update book release process on forge After it is converted and RBE reaches stable: [ ] Update the main English website link a 301
Step one done! Now waiting for this to reach stable.
The forge documentation can be updated now.
This has all been done!
Change:
/// Parses an `impl B0 + ... + Bn` type. fn parse_impl_ty(&mut self, impl_dyn_multi: &mut bool) -> PResult<'a, TyKind> { // Always parse bounds greedily for better error recovery. <ins> if self.token.is_lifetime() { self.look_ahead(1, |t| { if let token::Ident(symname, _) = t.kind { // parse pattern with "'a Sized" we're supposed to give suggestion like // "'a + Sized" self.struct_span_err( self.token.span, &format!("expected `+` between lifetime and {}", symname), ) .span_suggestion_verbose( self.token.span.shrink_to_hi(), "add `+`", " +", Applicability::MaybeIncorrect, ) .emit(); } }) } </ins> let bounds = self.parse_generic_bounds(None)?; *impl_dyn_multi = bounds.len() > 1 || self.prev_token.kind == TokenKind::BinOp(token::Plus); Ok(TyKind::ImplTrait(ast::DUMMY_NODE_ID, bounds))

Discussion:
<!-- 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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --I tried this almost-correct code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
expected: Ty<'tcx>, found: Ty<'tcx>, ) -> bool { <del> let ty::Adt(adt, args) = found.kind() else { return false }; </del> <ins> let ty::Adt(adt, args) = found.kind() else { return false; }; </ins> let ret_ty_matches = |diagnostic_item| { <del> if let Some(ret_ty) = self .ret_coercion .as_ref() .map(|c| self.resolve_vars_if_possible(c.borrow().expected_ty())) && let ty::Adt(kind, _) = ret_ty.kind() && self.tcx.get_diagnostic_item(diagnostic_item) == Some(kind.did()) { true } else { false } </del> <ins> let Some(sig) = self.body_fn_sig() else { return false; }; let ty::Adt(kind, _) = sig.output().kind() else { return false; }; self.tcx.is_diagnostic_item(diagnostic_item, kind.did()) </ins> }; // don't suggest anything like `Ok(ok_val).unwrap()` , `Some(some_val).unwrap()`,

Discussion:
snippet: 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
Regression in probably ? cc
This is due to . The function name in the stack trace matches the title of that PR. cc
oops race condition, clicked the button before I saw you self-assigned -- I already found a fix
yeah, go ahead please.
Change:
<ins> // error-pattern: this file contains an unclosed delimiter // error-pattern: mismatched closing delimiter: `]` // error-pattern: expected one of `)` or `,`, found `{` #![crate_name="0"] fn main() {} fn r()->i{0|{#[cfg(r(0{]0 </ins>

Discussion:
<!-- 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 think this issue is more than an internal compiler error, so I report here. I tried this code: The md5 of is: I expected to see this happen: normal compilation Instead, this happened: rustc crashes <!-- 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. --I test it on nightly, beta, and stable versions. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
I am not sure whether it is a security-oriented bug. If so, please close this. But I guess it is ok to be public. Thanks.
This is an explicit : So just an ICE, just somebody used an instead of a .
is the that's being executed.
The problem is that the parsing code is attempting to emit a fatal error, but error emission cannot happen through the function. The stack looks something like this: Two potential fixes here: adjust so that it does not abort on panics or make anything running within the incapable of panicking. The latter is way harder and more prone to eventually break again. I think this is probably P-medium or thereabouts.
It seems like the implementation of is copied from [][1]'s : [1]:
Would this be safe? My understanding is if the callback panics then the pointer will potentially be in an inconsistent state and continuing execution will not be safe.
Well, not in the exact form it is now, but there are a couple avenues that could be explored to make it more resilient to closure panics – e.g. one could replace the old value with some sort of placeholder default while the original value is being processed.
Another test-case. Hope it can help. .
Assigning as discussed as part of the and removing .
No longer crashes due to
Change:
<ins> error: removing an expression is not supported in this position --> $DIR/attr-empty-expr.rs:8:13 | LL |     let _ = #[test] 0; |             ^^^^^^^ error: removing an expression is not supported in this position --> $DIR/attr-empty-expr.rs:9:13 | LL |     let _ = #[bench] 1; |             ^^^^^^^^ error: removing an expression is not supported in this position --> $DIR/attr-empty-expr.rs:10:13 | LL |     let _ = #[test_case] 2; |             ^^^^^^^^^^^^ error: aborting due to 3 previous errors </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
modify labels: +regression-from-stable-to-stable Had to uninstall ~20 gigs of rustc releases again but since this code does not ICE on 1.20 but ices on 1.48.0, this is a stable-to-stable ice.
This started ICE'ing in 1.30.0. Error message in 1.29.0:
This is not supposed to work yet and it gives a good error message saying so -P-low Assigning and removing as in the prioritization working group.
The error message is helpful but it still panics in nightly. Do we want to fix the ICE at least or keep it?
A possible duplicate.
Fixed in
Change:
let msg = "`...` range patterns are deprecated"; let suggestion = "use `..=` for an inclusive range"; if parenthesise { <del> *visit_subpats = false; </del> <ins> self.node_id = Some(pat.id); </ins> let mut err = cx.struct_span_lint(ELLIPSIS_INCLUSIVE_RANGE_PATTERNS, pat.span, msg); err.span_suggestion( pat.span,

Discussion:
The parameter is a hack (to fix ) that should be refactored. The idea is that the state should be contained in instead. This should be straightforward to fix. the parameter from (You'll also need to update the signature of in . a method with an identical signature below it. the condition from an early lint pass for at the end. a field to in (Look at for an example of a lint with fields.) You'll also need to initialise it with here: should be replaced with an assignment of the new field in to : should be early-exited if the field is . a implementation to and reset the field to if the pattern ID matches the field ID. sure the UI tests still pass with no changes.
hi I'm happy to take care of this one if it's not taken already.
go ahead! Let me know if you have any questions or problems with the implementation! :)
Change:
impl<'tcx> Visitor<'tcx> for NamePrivacyVisitor<'tcx> { fn visit_nested_body(&mut self, body_id: hir::BodyId) { <del> let old_maybe_typeck_results = self.maybe_typeck_results.replace(self.tcx.typeck_body(body_id)); </del> <ins> let new_typeck_results = self.tcx.typeck_body(body_id); // Do not try reporting privacy violations if we failed to infer types. if new_typeck_results.tainted_by_errors.is_some() { return; } let old_maybe_typeck_results = self.maybe_typeck_results.replace(new_typeck_results); </ins> self.visit_body(self.tcx.hir().body(body_id)); self.maybe_typeck_results = old_maybe_typeck_results; }

Discussion:
<!-- [31mICE[0m: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' 'thread 'rustc' panicked at 'called on a value'', 'thread 'rustc' panicked at 'called on a value'' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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: note: compiler flags: -Z incremental-verify-ich=yes -C incremental=[REDACTED] -C debuginfo=2 [checkmodprivacy] checking privacy in top-level module [analysis] running analysis passes on this crate --
this bisects to
Change:
#[stable(feature = "nonnull", since = "1.25.0")] #[repr(transparent)] #[rustc_layout_scalar_valid_range_start(1)] <del> #[cfg_attr(not(stage0), rustc_nonnull_optimization_guaranteed)] </del> <ins> #[cfg_attr(not(bootstrap), rustc_nonnull_optimization_guaranteed)] </ins> pub struct NonNull<T: ?Sized> { pointer: *const T, }

Discussion:
We should only pass stage0 in general, should be sufficient for all use cases. cc for awareness and in case there's any concerns
Change:
for ur in self.scc_values.universal_regions_outlived_by(r_scc) { let new_lub = self.universal_region_relations.postdom_upper_bound(lub, ur); debug!("approx_universal_upper_bound: ur={:?} lub={:?} new_lub={:?}", ur, lub, new_lub); <ins> // The upper bound of two non-static regions is static: this // means we know nothing about the relationship between these // two regions. Pick a 'better' one to use when constructing // a diagnostic </ins> if ur != static_r && lub != static_r && new_lub == static_r { <del> lub = std::cmp::min(ur, lub); </del> <ins> // Prefer the region with an `external_name` - this // indicates that the region is early-bound, so working with // it can produce a nicer error. if self.region_definition(ur).external_name.is_some() { lub = ur; } else if self.region_definition(lub).external_name.is_some() { // Leave lub unchanged } else { // If we get here, we don't have any reason to prefer // one region over the other. Just pick the // one with the lower index for now. lub = std::cmp::min(ur, lub); } </ins> } else { lub = new_lub; }

Discussion:
Output (): The lifetime name should be given to the second reference in the tuple. modify labels: C-bug A-async-await A-diagnostics A-lifetimes T-compiler
On stable the output is different: Per bisect-rustc, the commit that changed the output is - almost definitely . is there something that can be done to improve this case? <details<summaryBisect output</summarysearched nightlies: from nightly-2020-06-01 to nightly-2020-07-15 regressed nightly: nightly-2020-07-02 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
Here's the output with removed: It looks like we're missing the "let's call the lifetime of this reference" note in the case.
The current equivalent of that annotation is the note at the bottom: (see ) I actually ran into this while testing a potential fix for that issue - it would make the output Which still points at the wrong reference.
Are you still planning to work on this?
Change:
<ins> // Regression test for #62504 #![feature(const_generics)] #![allow(incomplete_features)] trait HasSize { const SIZE: usize; } impl<const X: usize> HasSize for ArrayHolder<{ X }> { const SIZE: usize = X; } struct ArrayHolder<const X: usize>([u32; X]); impl<const X: usize> ArrayHolder<{ X }> { pub const fn new() -> Self { ArrayHolder([0; Self::SIZE]) //~^ ERROR: array lengths can't depend on generic parameters } } fn main() { let mut array = ArrayHolder::new(); } </ins>

Discussion:
: <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'd like to work on this. claim
Now ICE no longer occurs, I think it's fixed by . Marked as E-needstest.

When executed in the : <details<summaryCompiler output</summary</detailsEDIT: Here's the updated and the new stack trace as of Jan 7, 2020: <details<summaryCompiler output</summary</details
cc
I think this is another instance of However, we can leave this issue open to remember to add a test case when it's fixed.
The original issue no longer ICEs and instead errors with: which is essentially correct. However, providing the type annotations produces a new ICE:
In Source: <details<summaryStack trace</summary<p</p</details
Now ICE no longer occurs. I think it's fixed by .

This occurs on 1.34.1 and 1.34.0, is a regression from 1.33.0, and does.. not occur on nightly? Reproduction: compiled with Yields: I found this in building crates like and but pared it down to this
I think this is fixed in which might explain why it doesn't occur on nightly
triage: Probably fixed by . Normally an ICE would lead me to tag this as P-high, but the fact that this is only exposed by leads me to prioritize this as P-medium.
assigning to self to confirm that is the reason this is fixed, and (if need be) add a regression test.
Here's a slightly smaller case of what appears to potentially be the same thing which shows up if you select the "show MIR" option in In particular the following error is observed:
I think this issue is fixed in all channels. I tried stable and nightly both locally and on , and couldn't get any ICEs. Should we add a test? Otherwise we can just close I think.
Adding a test with seems like a good idea.

Compiler crash when using cfgif and defining a macro with macrorules twice. I tried this code: In a repo: I expected to see this happen: error: a macro named has already been exported Instead, this happened: error: internal compiler error: unexpected panic : Backtrace:
Regression from stable to stable (works in 1.30). Reduced test case:
mode is implemented on best effort basis, generally unsupported and will be removed in some time.
Ah, I see, the original issue doesn't have it. I'll investigate.
Reproducer in no longer ICEs.