jiebi/CodeConvo huggingface dataset:
Change:
if cfg!(debug_assertions) { let check_layout = compute()?; assert!( <del> mir_assign_valid_types(check_layout, known_layout), </del> <ins> mir_assign_valid_types(tcx, check_layout, known_layout), </ins> "expected type differs from actual type.nexpected: {:?}nactual: {:?}", known_layout.ty, check_layout.ty,

Discussion:
The following ICEs (example by shows This means that is wrong. It might be possible to also trigger this without nightly features through const_prop.
Baring a way to do the proper structural subtyping check, the only solution I see is to go back to comparing layouts in all cases (as a fallback after types mismatch) -- but does not like this, as far as I recall. Any other proposals?
Change:
<ins> // Copyright 2013 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 main() { let mut s = ~"test"; s[0] = 3; //~ ERROR: not allowed s[0] += 3; //~ ERROR: not allowed { let _a = &mut s[0]; //~ ERROR: not allowed } } </ins>

Discussion:
As far as I understand, the str types have a pretty strong assumption that they contain valid UTF-8. Any method/function that could break this (such as ) is marked as unsafe. However, it is possible to assign random bytes in the middle of a ~str, breaking the UTF-8 invariant: I think that such assignments should only be allowed in unsafe code. Update: should also be unsafe, IMO.
I had no idea str even allowed index-assign.
forbidding it entirely could also fix the issue, but might be overkill.
Hmm... This could be tricker than just forbidding assignment because this code compiles as well
I suppose we could also forbid (in safe code) to borrow mutable references to individual bytes in a string. Similarly, I believe that should be unsafe (but does not need to be.)
I think we should just forbid index-assign and borrowing mutable references. It can still be done through unsafe methods, but doesn't need to be in the language as a feature. The only language feature we have is raw pointer dereferencing so it's nice to keep it simple.
Nominating for the backwards compatible milestone.
doesn't need to be unsafe because it passes you a raw pointer, which is unusable without
Accepted for well-defined. (Also: document what "unsafe" means, which is a separate issue.)
Change:
} if sess.opts.debugging_opts.no_link { <del> let mut encoder = rustc_serialize::opaque::Encoder::new(Vec::new()); rustc_serialize::Encodable::encode(&codegen_results, &mut encoder).unwrap(); </del> <ins> let encoded = CodegenResults::serialize_rlink(&codegen_results); </ins> let rlink_file = self.prepare_outputs.with_extension(config::RLINK_EXT); <del> std::fs::write(&rlink_file, encoder.into_inner()).map_err(|err| { </del> <ins> std::fs::write(&rlink_file, encoded).map_err(|err| { </ins> sess.fatal(&format!("failed to write file {}: {}", rlink_file.display(), err)); })?; return Ok(());

Discussion:
This allows giving a better error when attempting to use the original source file with -Zlink-only rather than crashing and allows rejecting rlink files produced by a different rustc version.
To clarify: here's what I thought you had to do: But that gives an inscrutable error like this: The correct way to invoke is actually this If the file has a header, the code that reads it can check for that header. If it's not present (e.g. because somebody passed a file by mistake) then it can give a nice error message like "this doesn't look like a .rlink file".
I tried to look at this. is a struct that is serialized to files using the machinery. I tried to create a wrapper struct that would serialize and deserialize a header to provide nicer messages, but it's not really easy to provide a custom message if decoding of the header fails currently, since you removed the s from methods :sweat_smile: I see several solutions to this: 1) Catch panic that could be caused by invalid decoding of the header and provide a nicer message in that case (seems dubious). 2) Implement serialization and deserialization of the header using manual byte writes/reads, going around the traits. 3) Return sto methods (probably not worth it because of this). What do you suggest, solution 2)?
The crate metadata encodes and decodes the header separately from the contents. For crate metadata the header is of the form "rust" + 32bit be version number (currently 5 I believe) + 32bit offset of the crate root + rustc version string. During decoding the header is checked for "rust", the right version number and then the right rustc version. Only after that is a created to decode the contents. The rlink header could work the same way except omitting the offset of the crate root and using say "rsld" (rust ld) or "rustlink" as start instead of "rust" like the crate metadata.
Thanks for the hint. I checked rmeta decoding and it basically decodes the magic header byte slice with , which should be easy, but then it uses for decoding the rustc version, which will panic if the version is missing. So with this approach we could have a nice error if header magic is missing, nice error if rust version is wrong, but weird error if rust version if missing.

That is basically the same that we get for parsing, so I suppose that's ok?
Yeah, the header magic is supposed to be changed every time the rustc version needs to be decoded in a different way. IMO it is ok.
Change:
stage = compiler.stage; } <del> let mut extra_args = env::var(&format!("RUSTFLAGS_STAGE_{}", stage)).unwrap_or_default(); </del> <ins> let mut extra_args = String::new(); </ins> if stage != 0 { <del> let s = env::var("RUSTFLAGS_STAGE_NOT_0").unwrap_or_default(); if !extra_args.is_empty() { extra_args.push_str(" "); } </del> <ins> let s = env::var("RUSTFLAGS_NOT_BOOTSTRAP").unwrap_or_default(); extra_args.push_str(&s); } else { let s = env::var("RUSTFLAGS_BOOTSTRAP").unwrap_or_default(); </ins> extra_args.push_str(&s); }

Discussion:
Right now rustbuild invokes cargo which wants to rebuild the world if it sees a different value, while my workflow involves changing just to test stage1+ with . It would be nice to have passing to the python script (or the environment variable `RUSTFLAGS1="-Z orbit") just work. Currently the Makefiles have something similar but it doesn't actually work for , just .
Did rustbuild ever get support for this? This appears to also be breaking builds that need to pass per-stage values.
I'm going to unassign from this; I think others should be able to implement this and as far as I know they don't have any particular concern with this specific bug.
We support this via and set in the environment today.
I wonder if we should switch to and .
That would make sense, I'll reopen to track that.
Change:
<ins> error[E0599]: `i32` is not an iterator --> $DIR/issue-84495.rs:3:24 | LL |     println!("{:?}", x.count()); |                        ^^^^^ `i32` is not an iterator | = note: the following trait bounds were not satisfied: `i32: Iterator` which is required by `&mut i32: Iterator` error: aborting due to previous error For more information about this error, try `rustc --explain E0599`. </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. 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. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: For some reason, this doesn't happen for all traits in . Eg Just gives Version: 1.53.0-nightly (2021-04-22 ) <!-- 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. --
Some discussion on Discord suggests that might be a culprit. Trying with the variant produces as expected. So it looks like the trait bound is being honored for the search for the method, which is defined in the block, but not for the search for the method, which is defined in definition.
I suggest retitling this to "Compiler incorrectly (and inconsistently) finds methods on ".
I'd also like to suggest adding D-newcomer-roadblock because I've seen several other newcomers on Discord run into this confusing diagnostic.
I tried to replicate the incorrect diagnostic with a more minimal case than . It looks like it depends on the borrow mode of the receiver. This code : produces these errors: is a required trait method that takes a ref to , similar to (the doesn't seem necessary to exhibit these diagnostics). is a default trait method that moves , similar to most of the methods. It seems like a default trait method that moves is necessary to trigger this incorrect diagnostic. is a default trait method that takes a ref to , similar to . I've built a debugging version of the compiler and I'm trying to understand the debug logs for the trait and typechecking systems.
To elaborate on my prior comment: newcomers seem likely to encounter and be confused by this diagnostic. I ran into it myself by trying to call methods directly on , and I've seen several others be confused by that.

I think I've also seen newcomers be confused by trying to call methods directly on arrays. label +D-newcomer-roadblock
Change:
<del> Subproject commit ea6fa9c2d43aaf0f11559719eda9b54d356d5416 </del> <ins> Subproject commit 533d3f338b804d54e5d0ac4fba6276af23002d9c </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. --See . At line 177 of the generated assembly, it loads the address and passes it to the function. The offset 176 is incorrect since the data pushed to the stack in lines 166-175, the 40-byte stack frame pushed during the interrupt, and the 8-byte error code are only 128 bytes total, so the address will point to something random below the interrupt stack frame on the stack. This does not occur if the error code argument is removed: see . Here, an additional instruction appears at line 175 after saving registers, and the offset used at line 177 is correct (skipping the 80 bytes plus the 72 from the 9 saved registers, for 152 bytes total). Experimenting with custom target JSON specifications instead of x8664-unknown-none, it appears that the bug disappears when the part of the specification is removed.
cc
This regression seems to have been introduced by the LLVM 16 upgrade. searched nightlies: from nightly-2023-03-24 to nightly-2023-05-03 regressed nightly: nightly-2023-03-26 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
This bug seems to have been present in LLVM versions earlier than 16, I'm not sure why this only surfaced now. I'm working on a patch for LLVM.
Change:
use crate::collect::PlaceholderHirTyCollector; use crate::middle::resolve_lifetime as rl; use crate::require_c_abi_if_c_variadic; <ins> use rustc_ast::ast::ParamKindOrd; </ins> use rustc_ast::util::lev_distance::find_best_match_for_name; use rustc_data_structures::fx::{FxHashMap, FxHashSet}; use rustc_errors::ErrorReported;

Discussion:
suggests type parameters should come before lifetime parameters, which is incorrect. The message is emitted here: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I want to try working on this. claim
I've been trying to fix this, but even reversing the arguments to the format didn't seem to do anything. Am I missing something? I also to the error note for testing: And here's the error diff: EDIT: I modified the expected stderr for the test so that it matches how it should look after this is fixed by the way.
I've looked into it a bit more, and it looks like this isn't as simple as I thought at first. I thought it might work if I just reversed the arguments to , but that messes up other things. I think I'll need to rethink this.
Note that I cherry-picked the examples that were incorrect. The diagnostic is correct in other cases. You'll need to investigate a little to work out how best to fix this; one simple solution would be to sort the two with , though I'm not sure if that's the cleanest approach.
Okay, thanks for the info! I'll look into sorting and see if that works :)
I think I've figured out a basic solution. Let me know if there are things I can improve!
Change:
} fn error_derive_forbidden_on_non_adt(&self, derives: &[Path], item: &Annotatable) { <del> let attr = attr::find_by_name(item.attrs(), sym::derive).expect("`derive` attribute should exist"); let span = attr.span; </del> <ins> let attr = attr::find_by_name(item.attrs(), sym::derive); let span = attr.map_or(item.span(), |attr| attr.span); </ins> let mut err = self .cx .struct_span_err(span, "`derive` may only be applied to structs, enums and unions"); <del> if let ast::AttrStyle::Inner = attr.style { </del> <ins> if let Some(ast::Attribute { style: ast::AttrStyle::Inner, .. }) = attr { </ins> let trait_list = derives.iter().map(|t| pprust::path_to_string(t)).collect::<Vec<_>>(); let suggestion = format!("#[derive({})]", trait_list.join(", ")); err.span_suggestion(

Discussion:
` :
This crashes on stable, beta and nightly.
cc
says this regressed between releases 1.40 and 1.41.
triage: P-high to bisect and determine severity. Removing nomination. Added stable-to-stable regression label.
searched nightlies: from nightly-2019-11-01 to nightly-2020-02-25 regressed nightly: nightly-2019-12-08 searched commits: from to regressed commit: source code: Confirmed automated tests with manual run using <details<summaryCOLLAPSIBLE ERROR STACKTRACE</summary<p</p</details<details<summaryCOLLAPSIBLE ERROR STACKTRACE</summary<p</p</details
modify labels: -E-needs-bisection
Maybe
Reduced:
Fixed by
Change:
import os import sys import threading <ins> import thread </ins> import re import atexit <ins> import time </ins> # Set this to True for additional output DEBUG_OUTPUT = False

Discussion:
From time to time the LLDB test suite hangs on the build bots, which leads to the whole pipeline being blocked for an hour. One way to make this problem a bit less severe is to add a time-out to the LLDB test runner which just kills tests that take longer than a few seconds. This should at least reduce the time until the tests can be restarted. cc
cc
Change:
| LL |     foo(); |     ^^^ cannot infer the value of const parameter `X` declared on the function `foo` <ins> | help: consider specifying the const argument | LL |     foo::<X>(); |     ^^^^^^^^ </ins> error: aborting due to previous error

Discussion:
At the moment, we simply emit errors like: It would be good to suggest to the user how to fix this, like with uninferred type arguments.
cc
Stu over has picked this issue up.
Change:
let loc = Location::START; let span = self.patch.source_info_for_location(self.body, loc).span; let false_ = self.constant_bool(span, false); <del> for flag in self.drop_flags.values() { </del> <ins> for flag in self.drop_flags.iter().flatten() { </ins> self.patch.add_assign(loc, Place::from(*flag), false_.clone()); } }

Discussion:
This code creates MIR statements based on an iteration order: is defined as: Since FxHashMap's fixed seed is different between 32 and 64 bit platforms, we may end up creating statements in a different order on 32-bit vs 64-bit hosts (the target platform passed to the compiler has no effect). We should probably sort by before creating the statements.
Perhaps it should just use instead?
Revisiting this issue to evaluate the priority. unsure about the status and global direction of this issue. Do we have some work in progress somewhere? I've tried following the breadcrumbs and landed on . Unsure if it helps and - if yes - how much does that pull request covers to fix this issue. opinions? thanks :)
Change:
} fn enter<R>(self, f: impl FnOnce() -> R) -> R { <ins> let force_show_panics = self.force_show_panics; </ins> // Hide the default panic output within `proc_macro` expansions. // NB. the server can't do this because it may use a different libstd. static HIDE_PANICS_DURING_EXPANSION: Once = Once::new();

Discussion:
Between nightly-2020-08-29 and nightly-2020-09-02, the following began printing an ICE message (despite compiling successfully). The relevant compiler commit range is appears extremely relevant so mentioning From the PR description it sounds like the PR was intended to have no effect unless the new -Z flag is passed. Is it possible it could be causing this? Before: After:
It looks like I misunderstood how works. I'll PR a fix tomorrow.
Assigning as and removing .
PR is up at
Change:
write!(w, "<code>")?; render_assoc_item(w, item, link.anchor(&id), ItemType::Impl)?; write!(w, "</code>")?; <del> render_stability_since_raw(w, item.stable_since(), outer_version)?; </del> <ins> if let Some(l) = (Item { cx, item }).src_href() { write!(w, "</span><span class='out-of-band'>")?; write!(w, "<div class='ghost'></div>")?; render_stability_since_raw(w, item.stable_since(), outer_version)?; write!(w, "<a class='srclink' href='{}' title='{}'>[src]</a>", l, "goto source code")?; } else { render_stability_since_raw(w, item.stable_since(), outer_version)?; } </ins> write!(w, "</span></h4>n")?; } }

Discussion:
Test case:
Stability is fixed now, just needs links.
Triage: no src link on methods as of today.
We have [src] for impls now. Is that enough?
Did this just land? I can’t find these links in Is it only trait impls on inherent as well? In any case it’s an improvement, but some blocks are very large and source links on individual methods would still be useful in my opinion.
yep, it was merged recently: and works for both kinds of impls. It should be visible in the nightly docs already. There appear to be some problems with linking to impls pulled from to , I planned to investigate if that's fixable later.
I've opened to fix this.
Change:
<ins> error[E0391]: cycle detected when computing layout of `Foo<()>` | = note: ...which requires computing layout of `<() as A>::Assoc`... = note: ...which again requires computing layout of `Foo<()>`, completing the cycle note: cycle used when elaborating drops for `main` --> $DIR/recursive-type-binding.rs:11:1 | LL | fn main() { | ^^^^^^^^^ = note: see https://rustc-dev-guide.rust-lang.org/overview.html#queries and https://rustc-dev-guide.rust-lang.org/query.html for more information error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0391`. </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</detailsThis regressed in , previously it output a cycle error: label -I-ICE +I-crash +regression-from-stable-to-nightly
Bisection points to , but I don't have the context to determine which PR it was, maybe Assigning P-medium as this was already non-working code, and just the error message is a bit terse. label -I-prioritize +P-medium
Change:
// Calling `sess.incr_comp_session_dir()` will panic if `sess.opts.incremental.is_none()`. // Fortunately, we just checked that this isn't the case. <del> let path = dep_graph_path_from(&sess.incr_comp_session_dir()); </del> <ins> let path = dep_graph_path(&sess); </ins> let report_incremental_info = sess.opts.debugging_opts.incremental_info; let expected_hash = sess.opts.dep_tracking_hash(false);

Discussion:
This function is only used once, with the current session's directory. Is there a reason to keep it, or should it be replaced by ? Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
label +A-incr-comp +C-cleanup
feel free to make a PR and r? me on it.
claim
Change:
}) } <ins> ast::ItemKind::Fn(..) => { if let Some(attr) = cx.sess().find_by_name(&it.attrs, sym::no_mangle) { self.report_overriden_symbol_name( cx, attr.span, "declaration of a `no_mangle` function", ); } if let Some(attr) = cx.sess().find_by_name(&it.attrs, sym::export_name) { self.report_overriden_symbol_name( cx, attr.span, "declaration of a function with `export_name`", ); } } ast::ItemKind::Static(..) => { if let Some(attr) = cx.sess().find_by_name(&it.attrs, sym::no_mangle) { self.report_overriden_symbol_name( cx, attr.span, "declaration of a `no_mangle` static", ); } if let Some(attr) = cx.sess().find_by_name(&it.attrs, sym::export_name) { self.report_overriden_symbol_name( cx, attr.span, "declaration of a static with `export_name`", ); } } </ins> _ => {} } }

Discussion:
Given that there should be a lint that is capable of detecting it (there was a suggestion that should also detect it, but it might make sense to be able to lint it individually too).
So maybe should be a lint group, and include this new lint? I am suggesting that because I think should suffice to trigger the new lint.
I've got the basic lint working now. do you think it's worth adding it as a separate lint, renaming to something else (which I can't think of a name for), and adding them both as lints in an group; or better to just integrate it into the current lint?
I'll defer to for that :D
I am partial towards having a hard error when encountering multiple functions with the same name in a given workspace, . Adding this to might be problematic in the wild. Let's make a PR that rolls it into and see the behavior in the wild with a crater run, but if it causes too much fallout, lets make it an independent lint.
There's other ways of using which create UB than just overriding within a workspace, e.g. the example in While adding a hard error for cases that can be detected would be nice, I don't think it's possible in general.
Removing I-prioritize since this is already tracked at
Is there a tracking issue for additional lints like this to similar "unsafe attributes"? I think that'd be great!
not that I know of but you could open one :)
Done
Change:
// xfail-pretty // xfail-test <del> #[feature(quote_expr, quote_ty, quote_item, quote_stmt, quote_pat)]; </del> <ins> #[feature(quote)]; </ins> extern mod extra; extern mod syntax;

Discussion:
These all are only useful in the compiler, aren't hygienic, etc. Nominating.
What hygiene issues do they still have? The hygiene issue I'm aware of was fixed by . They'll be very useful for externally defined syntax extensions. I'm okay with feature gating it though.
The only thing I recall is that they require an to be in scope. Perhaps that's not technically a hygiene problem.
Accepted for 1.0, P-backcompat-lang.
I would like to look at this, but I am not familiar to quasi-quoting. Can you list some quasi-quoting macros, or point out the directory of the source tree to look up? What I have found related to quasi-quoting lies on .
All of the quasi-quoting macros live there.
Their .