jiebi/CodeConvo huggingface dataset:
Change:
use crate::sys::handle::Handle; use core::str::utf8_char_width; <ins> #[cfg(test)] mod tests; </ins> // Don't cache handles but get them fresh for every read/write. This allows us to track changes to // the value over time (such as if a process calls `SetStdHandle` while it's running). See #40490. pub struct Stdin {

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 tried this code: In windows terminal running Git Bash (also occured in Nushell, though I'm not sure if this is terminal or shell-land), I pressed Ctrl-Z + Enter to send EOF. I expected to see this happen: The application would gracefully exit the loop Instead, this happened: I saw this error message: <!-- 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<summaryBacktrace</summary<p</p</details
The underlying regression here is that the way we call does not accept zero length strings. And we're calling in a way that makes ctrl-z immediately return without reading anything after it. This is important because a zero length read is how we signal to stdlib that an eof has occurred (so ctrl-z handling is pretty indirect). The fix is simple, if anyone wants to claim this issue. needs to check for zero length input and immediately return in that case.
Seems like a good first issue, I can take a stab at it.
That would be great!
Where would be a good place to write a test for this?
Hm, this is a Windows specific issue so it should probably stay close to the affected code. Take a look at how for tests and do something similar for stdio.
Never mind, I see how things are glued together.
It's a sub module so it should be able to access the private functions of its parent (aka ) module. This is noted in the :
For sure, just misread the directory structure.
Change:
<ins> error[E0433]: failed to resolve: use of undeclared type or module `nope` --> $DIR/conflicting-impl-with-err.rs:4:11 | LL | impl From<nope::Thing> for Error { |           ^^^^ use of undeclared type or module `nope` error[E0433]: failed to resolve: use of undeclared type or module `nope` --> $DIR/conflicting-impl-with-err.rs:5:16 | LL |     fn from(_: nope::Thing) -> Self { |                ^^^^ use of undeclared type or module `nope` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0433`. </ins>

Discussion:
(edit: see below) The first error is sensical: But the knock-on errors are not:
Minimized:
Change:
} } <ins> #[derive(Debug, Copy, Clone, TypeFoldable, TypeVisitable, Lift)] pub struct PrintClosureAsImpl<'tcx> { pub closure: ty::ClosureSubsts<'tcx>, } </ins> forward_display_to_print! { ty::Region<'tcx>, Ty<'tcx>,

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 suggest how to specify the return type when a function returns a closure. <!-- 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
Is some thing like this not ok ?
release-assignment
It's ok but I was wondering if it's possible to make the compiler give some form of a suggestion to the user on how to do this. Cause the current diagnostics does not suggest how to fix it.
Change:
#![feature(const_transmute)] #![feature(reverse_bits)] #![feature(non_exhaustive)] <ins> #![feature(structural_match)] </ins> #[prelude_import] #[allow(unused)]

Discussion:
Given: results in: Is this intentional due to some soundness issue with having it otherwise? (I cannot think of any...) We could fix this by attaching to manually. While having be structurally matchable is quite boring and useless on its lonesome it prevents other types that contain it from being structurally matchable. (not likely to occur very often, but when it occur it seems like it would be annoying...) r? cc
Change:
.add_element(live_region_vid, location); }); <ins> // HACK(compiler-errors): Constants that are gathered into Body.required_consts // have their locations erased... let locations = if location != Location::START { location.to_locations() } else { Locations::All(constant.span) }; </ins> if let Some(annotation_index) = constant.user_ty { if let Err(terr) = self.cx.relate_type_and_user_type( constant.literal.ty(), ty::Variance::Invariant, &UserTypeProjection { base: annotation_index, projs: vec![] }, <del> location.to_locations(), </del> <ins> locations, </ins> ConstraintCategory::Boring, ) { let annotation = &self.cx.user_type_annotations[annotation_index];

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 ( , regressed in the past week) 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. --The desired result can be achieved by swapping the order of the two statements and . <!-- 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 --<!-- TRIAGEBOT_END --
searched nightlies: from nightly-2022-06-07 to nightly-2022-06-08 regressed nightly: nightly-2022-06-08 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details are you working on this? I'll probably be investigating this due to it being related to the recent removal of the borrowck migration mode.
I've been working on it a bit, but please feel free to take over this issue!
This actually looks like a particularly difficult issue. I think it's either a bug in , or something weird with the that is convincing us that the correct source for this region error is through the on line 12 of the example. It may also be notable that we end up going thru a when emitting this error. This issue seems to be out of my area of expertise, so I won't claim it. if you can't find a solution then it may be best to hand off to someone with mir-borrowck expertise.
Actually, what I said was totally wrong.

This is definitely because we're passing in the wrong when . I think I have a fix for this, though I probably want to eliminate other dummy locations we're passing around mir borrowck... cc sorry for all the pings, but don't keep wasting time on this unless you've made significant progress :stuckout_tongue: claim
Change:
let empty_string = String::new(); let s = self.symbol.as_str(); <del> let parser = Parser::new(s, None, None, false, ParseMode::Format); </del> <ins> let mut parser = Parser::new(s, None, None, false, ParseMode::Format); </ins> let item_context = (options.get(&sym::ItemContext)).unwrap_or(&empty_string); <del> parser </del> <ins> let constructed_message = (&mut parser) </ins> .map(|p| match p { Piece::String(s) => s.to_owned(), Piece::NextArgument(a) => match a.position {

Discussion:
The following are some unexpected behaviors I see with the formatting strings in the attribute. I'm not sure that the attribute should actually be using std's format parsing, but if it is, the following seem like issues with the current implementation. Anything after the is ignored, and not included in the message output. Expectation: There should be a warning that the string is malformed. or These generate an error. However, my understanding of the attribute is that it tries to only generate warnings for things it doesn't understand. I would expect this to also generate a warning. This does not generate a warning or error. I would expect it to generate a warning that anything after the is ignored. This includes width, precision, debug formatting, etc. The error message generated with this is the type followed by a . I would expect this to generate a warning that the format arguments are not valid (similar to how works). : cc
I filled to hopefully address this.
Good catch! This should probably support a strict subset of formatting (only named arguments and no format options), and warn whenever the string is either not valid for or not in the supported subset. When it shows a warning, not sure what the behavior of the string should be -- maybe just take it as a literal without any interpolation?
Change:
impl<'tcx> TypeVisitor<TyCtxt<'tcx>> for ParameterCollector { fn visit_ty(&mut self, t: Ty<'tcx>) -> ControlFlow<Self::BreakTy> { match *t.kind() { <del> ty::Alias(ty::Projection | ty::Inherent, ..) if !self.include_nonconstraining => { </del> <ins> ty::Alias(..) if !self.include_nonconstraining => { </ins> // projections are not injective return ControlFlow::Continue(()); }

Discussion:
The following UB compiles: The impl is invalid because the lifetime parameter appears unconstrained in the impl header. It should be rejected for the same reason that projection types doesn't constraint impl generics: label C-bug T-types I-unsound requires-nightly F-typealiasimpl_trait
Change:
<ins> // Regression test for #92105. // ICE when mutating immutable reference from last statement of a block. fn main() { let foo = Some(&0).unwrap(); *foo = 1; //~ ERROR cannot assign } </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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This panic appears to be fixed in PR . Duplicate of ?
Perhaps worth adding a regression test for this issue in particular.
Sounds like a good idea- I'll get going on that
claim
Change:
#[cfg(all(target_arch = "x86_64", target_feature = "sse2"))] // only called on x86 #[inline] unsafe fn small_slice_eq(x: &[u8], y: &[u8]) -> bool { <ins> debug_assert_eq!(x.len(), y.len()); </ins> // This function is adapted from // https://github.com/BurntSushi/memchr/blob/8037d11b4357b0f07be2bb66dc2659d9cf28ad32/src/memmem/util.rs#L32

Discussion:
PR a x8664 SIMD-based implementation of to optimize searching into strings when the needle is at most 32 bytes long. Unfortunately, that implementation doesn't seem to be sound. When compiling the standard library with debug assertions on, running UI tests excluding results in compiletest itself panicking before executing any test due to a in libcore: To reproduce the issue, use the following configuration file: run: cc
Tentatively opened a revert PR in
Ugh. I ran it under miri with quite a combinatorial test that I thought should cover all the edge-cases. It's not immediately obvious what's wrong, so it's fine to land the revert for now.
Last I checked (and a lot has happened since then so I could be working on outdated info -- might be able to confirm), miri can't catch failure in many cases I believe, since it's "just" library UB.
the memory will be accessed after the get_unchecked so it should still be an invalid memory access when it's out of bounds. Unless I'm just doing some shortening slicing and then extending it again so that it's valid within the same allocation but not correct slicing.
What says is correct. The error here is in a situation like Miri (without Stacked Borrows) will not complain about that since the index is in-bounds of the allocation. But the debug assertion will complain since you are causing library UB by going out-of-bounds of the slice. I don't quite understand your last comment,
It seems like the test is just insufficient. Even with debug asserts and overflow checks enabled it doesn't catch it. I'll have to reproduce it first to figure out what's missing.
Ooh, I was getting absolutely unexplainable compiler errors when building stage 1 libstd with a stage 0 rustc which was built with however, could this be the cause for this? :sweat_smile:
Possible, but it would also do incorrect things on x86-64 baseline
has a proper fix
Change:
.run(move |s| compile::assemble_rustc(build, s.stage, s.target)); rules.build("llvm", "src/llvm") .host(true) <ins> .dep(move |s| { if s.target == build.config.build { dummy(s, build) } else { s.target(&build.config.build) } }) </ins> .run(move |s| native::llvm(build, s.target)); // ========================================================================

Discussion:
with: (In this example: and ) when configured with or with . I think this is because rustbuild tries to use the that's supposed to be generated by building LLVM for but rusbuild nevers builds LLVM for in this case. cc
Call: before .
Fixed in
Change:
if let Some(span) = in_test_module { db.span_help( sess.source_map().guess_head_span(span), <del> "consider adding a `#[cfg(test)]` to the containing module", </del> <ins> "if this is a test module, consider adding a `#[cfg(test)]` to the containing module", </ins> ); } }

Discussion:
This help message seems weird. I'd expect the help to be more like: Consider adding if you want to silent the lint on the unused import Consider removing the unused import Suggesting to add to the module is the least expected option, and it seems too assertive in its current wording. No response Perhaps the detection for triggering on the module could be smarter and only consider a module as a potential test module if it contains at least one annotated function? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
How can i proceed to solve this any suggestions on how can it be done changes to which file will make it happen since i am new to this repo
Hi thank you for your interest. For now, I think making the help message less assertive would be sufficient. Here are some tips to get you started: will need to find where this help message is emitted. You can identify where this help message is coming from by grepping the repo, i.e. this case, it might be as simple as changing this string to make it sound less assertive. can reformat your changes via . the UI test suite to make sure at least one test fails -- this means at least one test is actually testing this diagnostic. you're happy with the stderr output from your change, re-bless the UI test suite and now make sure the UI test suite passes. to make sure tidy checks passes locally. a PR and wait for review. Your reviewer will discuss with you to see if any further changes are desirable. <https://rustc-dev- the more in-depth reference. If you are stuck, feel free to ask here, or make a new thread in .
claim
(Unless already submitted a change and I didn't find it, I should be able to create a PR soon)
Change:
scx.tcx().hir.krate().visit_all_item_likes(&mut visitor); } <ins> // We can only translate items that are instantiable - items all of // whose predicates hold. Luckily, items that aren't instantiable // can't actually be used, so we can just skip translating them. roots.retain(|root| root.is_instantiable(scx.tcx())); </ins> roots }

Discussion:
Compiler panicks instead of showing an appropriate error message in case boundaries are not satisfied. I tried this code: In the result compiler panicked with the following message:
Minimal repr:
Still panics on stable 1.15.1
Change:
impl<'tcx> MirPass<'tcx> for Validator { fn run_pass(&self, tcx: TyCtxt<'tcx>, body: &mut Body<'tcx>) { let def_id = body.source.def_id(); <del> let param_env = tcx.param_env(def_id); </del> <ins> // We need to param_env_reveal_all_normalized, as some optimizations // change types in ways that require unfolding opaque types. let param_env = tcx.param_env_reveal_all_normalized(def_id); </ins> let mir_phase = self.mir_phase; let always_live_locals = AlwaysLiveLocals::new(body);

Discussion:
Previously: Now: <!-- 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
Inlining exposes a use of unnormalized local in a call terminator (not sure if this is more of an issue with inlining or a validator): Note: revision annotation doesn't work in an auxiliary file (so it isn't tested on CI with mir-opt-level=2). modify labels: +A-mir-opt-inlining
This ICEs again because the fix was reverted Can someone reopen please?
Due to this new requires to trigger. <details<summaryICE:</summary</details
(FWIW can also trigger this: )
fixes this for and , but it still ICEs with on its own or with mir-opt-level 1/2 cc
Change:
<del> Subproject commit 4083a90168d605b682ba166a0c01f86b3384e474 </del> <ins> Subproject commit 8eee2e473e71e659cbd5d32ee78aaf42e8b75752 </ins>

Discussion:
~ OK on 1.46: | fails on 1.47: In all cases, we are using gdb 9.2 and LLVM 10. The tests themselves haven't changed since ~1.38, so it must be an actual behavioural change in rustc. <details<summaryui/backtrace-</summary~ </details<details</summary~ </details<details<summaryui/std-</summary~ </details
could this be related to ?
Seems likely! If this is happening on big-endian platforms then there's likely an issue with endianness in (most likely) . It could also be in itself or , but it seems most likely to be in the integration in the crate itself.
Related:
Assigning and removing as in the prioritization working group.
I'll try to run gimli etc things on a sparc, but no promises of success.
I have an s390x machine at hand, so I tried a few things. Plain passes for , , and , but fails two tests: There are also warnings about FFI safety, but I don't know if they're relevant.
It may be easier to reproduce on a mac:
Mac may have a very different issue, since it's apparently a big-endian thing here. (Plus I don't have a mac at all. :wink: )
Well, this will do it: I think this should this be , unless there's support for backtracing other processes.
Side note: does this need to be updated?
Change:
} } <ins> fn visit_fn(&mut self, fk: FnKind<'a>, sp: Span, _: NodeId) { match fk { FnKind::Fn(FnCtxt::Foreign, _, sig, _, _) => { self.visit_fn_header(&sig.header); visit::walk_fn_decl(self, &sig.decl); // Don't visit the foreign function body even if it has one, since lowering the // body would have no meaning and will have already been caught as a parse error. } _ => visit::walk_fn(self, fk, sp), } } </ins> fn visit_assoc_item(&mut self, item: &'a AssocItem, ctxt: AssocCtxt) { self.lctx.with_hir_id_owner(item.id, |lctx| match ctxt { AssocCtxt::Trait => {

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. --: Also occurs on nightly at <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Semicolon is not the main problem here. Standalone semicolons are allowed as items inside function body. Second function definition would be OK if not for the extern "C" block — AFAIK only function declarations are allowed there, so is not valid syntax.
Prioritized as as per .7B.3B.60)
claim
A possibly clearer repro:
glacier ""
The previous issue has been fixed, let's try again (sorry for the noise!). glacier ""
Change:
LL |     use super::a; |         ^^^^^^^^ | <del> help: consider adding a `#[cfg(test)]` to the containing module </del> <ins> help: if this is a test module, consider adding a `#[cfg(test)]` to the containing module </ins> --> $DIR/unused-imports-in-test-module.rs:48:1 | LL | mod tests_a {

Discussion:
This help message seems weird. I'd expect the help to be more like: Consider adding if you want to silent the lint on the unused import Consider removing the unused import Suggesting to add to the module is the least expected option, and it seems too assertive in its current wording. No response Perhaps the detection for triggering on the module could be smarter and only consider a module as a potential test module if it contains at least one annotated function? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
How can i proceed to solve this any suggestions on how can it be done changes to which file will make it happen since i am new to this repo
Hi thank you for your interest. For now, I think making the help message less assertive would be sufficient. Here are some tips to get you started: will need to find where this help message is emitted. You can identify where this help message is coming from by grepping the repo, i.e. this case, it might be as simple as changing this string to make it sound less assertive. can reformat your changes via . the UI test suite to make sure at least one test fails -- this means at least one test is actually testing this diagnostic. you're happy with the stderr output from your change, re-bless the UI test suite and now make sure the UI test suite passes. to make sure tidy checks passes locally. a PR and wait for review. Your reviewer will discuss with you to see if any further changes are desirable. <https://rustc-dev- the more in-depth reference. If you are stuck, feel free to ask here, or make a new thread in .
claim
(Unless already submitted a change and I didn't find it, I should be able to create a PR soon)