jiebi/CodeConvo huggingface dataset:
Change:
#![feature(pattern)] #![feature(range_is_empty)] #![feature(raw)] <del> #![feature(saturating_neg)] </del> #![feature(sort_internals)] #![feature(slice_partition_at_index)] #![feature(specialization)]

Discussion:
It would be great to have and functions for signed integer types. The current work-around is using a pattern like but having explicit functions would lift the corner-case knowledge "burden" from the user.
What do you expect them to return? Just for the two values that can't be expressed? IMHO you should prefer the instead and explicitly handle that.
The and functions both have a corner case when the negative minimum value is used (e.g. -128 for type i8). The result cannot be represented within the bounds of the output type. The / variants shall return a best-effort value (like 127 in case of -128 i8 input), similar to the existing functions. asserteq!(127i8.saturatingabs(), 127); asserteq!(-127i8.saturatingabs(), 127); asserteq!(-128i8.saturatingabs(), 127); asserteq!(127i8.saturatingneg(), -127); asserteq!(-127i8.saturatingneg(), 127); asserteq!(-128i8.saturating_neg(), 127);
These seems reasonable. I'd suggest just making a PR with them unstable and seeing what libs says. By using they'll automatically get the new saturating implementation, too, which should be better for optimization and codegen than the approach.
Haven't done a PR for Rust yet so will take a look at the contribution guidelines and try to get along.
What's holding up stabilization on this? It seems relatively simple.
In my opinion there is nothing specific holding this up from being stabilized. Initially I wanted to give it some time for others to comment, then forgot about. Added a PR for stabilization now.
Change:
use crate::mir::operand::OperandRef; use crate::traits::*; <del> use rustc_index::vec::Idx; </del> use rustc_middle::mir; use rustc_middle::mir::interpret::{ConstValue, ErrorHandled}; use rustc_middle::ty::layout::HasTyCtxt;

Discussion:
Followup to I think we only have one use site of left: and it iterates over all fields anyway. So we can call instead and iterate over the resulting fields. There should be no more results for searching in the rust source after this, so some comments may need updating to mentioning instead of . These mentoring instructions are a bit vague, I do realize that, so if you encounter any hickup of any magnitude, don't hesitate to write here or contact me via discord/zulip. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
EDIT: Okay, it is a word. Still, to me "destruct" sounds better. But maybe that's just because I am used to theorem provers?
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:18:1 | LL | mod tests {

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:
} } if let Ok(base_snippet) = base_snippet { <del> let mut sp = after_colon_sp; for _ in 0..100 { // Try to find an assignment sp = sm.next_point(sp); let snippet = sm.span_to_snippet(sp); match snippet { Ok(ref x) if x.as_str() == "=" => { err.span_suggestion( base_span, "maybe you meant to write an assignment here", format!("let {}", base_snippet), Applicability::MaybeIncorrect, ); show_label = false; break; } Ok(ref x) if x.as_str() == "n" => break, Err(_) => break, Ok(_) => {} } </del> <ins> // Try to find an assignment let eq_span = sm.span_look_ahead(after_colon_sp, Some("="), Some(50)); if let Ok(ref snippet) = sm.span_to_snippet(eq_span) && snippet == "=" { err.span_suggestion( base_span, "maybe you meant to write an assignment here", format!("let {}", base_snippet), Applicability::MaybeIncorrect, ); show_label = false; </ins> } } }

Discussion:
As a python programmer, forgetting a in an assignment to a variable that didn't exist before is an easy mistake to make. () Rust sees two uses of an undefined variable here (E0425 twice): While the second one is fine, in the first case I would have really appreciated a sentence like this: This would helped me as a newcomer to the language, because it does an educated guess what the problem might be and tells me how to fix it. I think the hint should be if the value is assigned to (first error), but not if it is used as an argument (second error). I hope this is the right place and format to file this suggestion, I would appreciate hints if this is not the case. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is the right place, however you should use the "diagnostic" template when creating issues like this. Thanks for the issue though. label +T-compiler +A-diagnostics
claim
Change:
impl<T: Copy> SpecFill<T> for [T] { fn spec_fill(&mut self, value: T) { <del> if size_of::<T>() == 1 { // SAFETY: The size_of check above ensures that values are 1 byte wide, as required // for the transmute and write_bytes unsafe { let value: u8 = transmute_copy(&value); write_bytes(self.as_mut_ptr(), value, self.len()); } } else { for item in self.iter_mut() { *item = value; } </del> <ins> for item in self.iter_mut() { *item = value; </ins> } } }

Discussion:
This was reported by on Zulip: https://rust- Demo:
I think the fix should be as simple as using instead of as the type of - that will work regardless of whether or not the memory is initialized.
The other option is just removing the case entirely. Llvm is smart enough to turn that loop in the branch into a memset.
It does help the gcc codgen backend at least as it can't manage to produce a memset for u64 so I assume it would fail to do the same for u8 if it weren't for that specialization.
It also fails for the case:
It does call memset if you don't pass an array.
I'd think the intrinsic could easily have its type changed to take a , which would let one solve this problem. The stable function of course cannot be changed, though...
Reopening to track adding a test. (That's the standard procedure for this, isn't it?)
I would like to try working on adding the test, though this will be my first contribution so I'd need some guidance. I'm assuming this would be a miri test as it's related to correctness--may I DM you on Zulip? (or would someone else be more suitable?)
great. :) Miri runs the libcore test suite via So adding it as a test in libcore makes most sense, IMO.
Change:
import front.ast.stmt; import front.ast.block; import front.ast.item; <ins> import front.ast.view_item; import front.ast.meta_item; </ins> import front.ast.arg; import front.ast.pat; import front.ast.decl;

Discussion:
I was trying to build the stdlibs for the target like this: However, the build fails with the following error: Here is the full build log: I'm using Xubuntu 15.10. At the time of building, the Rust master was at .
Unfortunately is a which means that we don't guarantee that it builds in-tree right now. Patches are certainly welcome to fix this, however! We tend to not keep issues tracking build support for all Tier 3 platforms, however, so I'm going to close this. If you're interested in promoting this to at least tier 2 you could also help modify out to be able to support this target!
Change:
static LLVM_THREAD_LOCAL char *LastError; <ins> // Custom error handler for fatal LLVM errors. // // Notably it exits the process with code 101, unlike LLVM's default of 1. static void FatalErrorHandler(void *UserData, const std::string& Reason, bool GenCrashDiag) { // Do the same thing that the default error handler does. std::cerr << "LLVM ERROR: " << Reason << std::endl; // Since this error handler exits the process, we have to run any cleanup that // LLVM would run after handling the error. This might change with an LLVM // upgrade. sys::RunInterruptHandlers(); exit(101); } extern "C" void LLVMRustInstallFatalErrorHandler() { install_fatal_error_handler(FatalErrorHandler); } </ins> extern "C" LLVMMemoryBufferRef LLVMRustCreateMemoryBufferWithContentsOfFile(const char *Path) { ErrorOr<std::unique_ptr<MemoryBuffer>> BufOr =

Discussion:
Related to . If a fatal error occurs in LLVM, the compiler exits with status 1. This is problematic, because if a test is expecting a compilation failure, the test could still pass. It also makes it difficult to test for the presence of ICEs in general. A simple fix would be to patch our copy of LLVM to exit with 101 (like ICEs) in , but any other ideas would be appreciated.
Those error functions all call , which sounds like it could be a great hook for us, but then that only calls . :/
There is  though, and that handler gets called first.
That sounds nice, but if we exit with 101 (or simply panic) in the handler won't we be skipping any other cleanup (, plus any future cleanup that gets there)? Or could we just call it in our handler? I'm interested in putting a patch together, but I'm unfamiliar with how we link Rust to C++. The error handler needs to be able to consume a .
We shouldn't do anything that looks like exception unwinding. See : I think we can call it -- it's publicly declared in . We might want to keep a note to make sure we check for new cleanup needed when we update LLVM though. We bridge C++ code in . You could just write our handler in C++ there, and add some C-FFI function for to call and hook that up.
Change:
vec.contains(&99u); }) } <ins> #[bench] fn zero_1kb_from_elem(bh: &mut BenchHarness) { bh.iter(|| { let _v: ~[u8] = vec::from_elem(1024, 0u8); }); } #[bench] fn zero_1kb_set_memory(bh: &mut BenchHarness) { bh.iter(|| { let mut v: ~[u8] = vec::with_capacity(1024); unsafe { let vp = vec::raw::to_mut_ptr(v); ptr::set_memory(vp, 0, 1024); vec::raw::set_len(&mut v, 1024); } }); } #[bench] fn zero_1kb_fixed_repeat(bh: &mut BenchHarness) { bh.iter(|| { let _v: ~[u8] = ~[0u8, ..1024]; }); } #[bench] fn zero_1kb_loop_set(bh: &mut BenchHarness) { // Slower because the { len, cap, [0 x T] }* repr allows a pointer to the length // field to be aliased (in theory) and prevents LLVM from optimizing loads away. bh.iter(|| { let mut v: ~[u8] = vec::with_capacity(1024); unsafe { vec::raw::set_len(&mut v, 1024); } for i in range(0, 1024) { v[i] = 0; } }); } #[bench] fn zero_1kb_mut_iter(bh: &mut BenchHarness) { bh.iter(|| { let mut v: ~[u8] = vec::with_capacity(1024); unsafe { vec::raw::set_len(&mut v, 1024); } for x in v.mut_iter() { *x = 0; } }); } </ins> }

Discussion:
While landed a nice optimization of in , he said that it's still not performing as fast as doing a malloc and a . We should figure out why it is not performing as well as it should be and fix it in order to remove the temptation of using the faster unsafe functions.
It turns out this is substantially slower than I expected. With this test benchmark: I'm getting these results: This is related to and .
mentioned in irc that with the difference is: Which is much better, but still not great.
memset "cheats" with sse. fromelem spends a lot of time in moveval_init without optimizations so there's a bunch of unnecessary function calls. With optimizations, the thing that's killing it is the copies.
LLVM knows how to optimize loops to the same code as memcpy/memmove/memset though, as long as you generate good IR.
I a bench for the literal vec repeat syntax as well: Without optimizations: With optimizations (-O): Looking at the optimized IR, both setmemory and vecrepeat become a memset but setmemory seems to have a lot more overhead. does not become a memset hence the bad results.
this gets a lot better with the optimization passes from , from ~3x as slow to ~2x as slow Before (opt-level=2): After (opt-level=2)
the problem is with the code bloat from the surrounding code, rather than itself - I think we actually produce some IR there with undefined behaviour
greatly speeds up , fixing half of the issue Before: After:
The performance of all 3 has improved, but got slower relative to the others:
It looks like the remaining issue is our pointer arithmetic being slow. The and functions compile to conversions to and from integers, rather than actual pointer arithmetic with the stricter semantics. I think we need to make the and implementations for pointers a compiler feature.
Fixed by .
This since that fix, is attempting a bisect atm. Update: bisect finished, is to blame. isn't optimized. Maybe the needs to be inlined for further optimizations.
Note that set_memory has regressed by ~16ns, cause is ()
Change:
if let Some(item) = module .res .and_then(|res| res.mod_def_id()) <ins> // If the module is `self`, i.e. the current crate, // there will be no corresponding item. .filter(|def_id| def_id.index != CRATE_DEF_INDEX || def_id.krate != LOCAL_CRATE) </ins> .and_then(|def_id| self.tcx.hir().as_local_hir_id(def_id)) .map(|module_hir_id| self.tcx.hir().expect_item(module_hir_id)) {

Discussion:
Attempting to compile this code: Playground link: Causes this ICE in nightly 2019-12-29 ,and stable with a slightly different stack trace.
reduced to 2 lines: also, when the is removed from the line, OR both 's are removed, it compiles fine.
yeah, I prepared the fix but has already submitted another fix so assignment is unnecessary?
Change:
} ItemEnum(ref enum_definition, ref type_parameters) => { visitor.visit_generics(type_parameters); <del> visitor.visit_enum_def(enum_definition, type_parameters, item.id) </del> <ins> visitor.visit_enum_def(enum_definition, type_parameters, item.id, item.span) </ins> } ItemDefaultImpl(_, ref trait_ref) => { visitor.visit_trait_ref(trait_ref)

Discussion:
Namely: + maybe So, if I want to visit, for example, a and report an error, I can't do it and have to visit all its parents instead.
Change:
<ins> error[E0423]: cannot initialize a tuple struct which contains private fields --> $DIR/suggest-box-new.rs:9:19 | LL |         wtf: Some(Box(U { |                   ^^^ | note: constructor is not visible here due to private fields --> $SRC_DIR/alloc/src/boxed.rs:LL:COL | = note: private field | = note: private field help: you might have meant to use the `new` associated function | LL |         wtf: Some(Box::new(U { |                      +++++ error: aborting due to previous error For more information about this error, try `rustc --explain E0423`. </ins>

Discussion:
Could someone change the bad title? I am not good for english.
Seems like more of a diagnostics issue. is a private constructor, but we're erroring out on type-checking before we realize this. The fix for this specific code is to replace with
Triage: this now has a different, yet still confusing, error:
That error is correct; but either way, the other error you get today is this, which while not ideal, is possibly the best we can do. I guess we could look for a method with a single parameter? But that seems hacky.
It is, but it is a common enough pattern and such a big enhancement in end user experience that I feel it'd be worth it to add it, specially when the ctor is not public. Then, the output should be: Similar output, but not quite the same cause in .
In order to implement this there's a bit of roadblock at the moment. The verification if a struct has a given method is done in , while this error is being emitted in . I believe the error is being bubbled up, but it would have to be delayed on its entirety to the type check step in order to verify wether exists. :-/ You can look for traits that have a given method (), but when I tried it with it returned an empty . We could provide with a generic suggestion about trying out , but I would much rather prefer if we could have some certainty that the method exists instead of potentially misleading the user.
Current output:
The error message seems pretty good... let's close this?
I still think that . Definitely low priority now given the other improvements on the error.
: We still need to look for and suggest it.
Change:
<ins> // compile-flags: --test #![feature(custom_test_frameworks)] #![deny(unnameable_test_items)] fn foo() { #[test_case] //~^ ERROR cannot test inner items [unnameable_test_items] fn test2() {} } </ins>

Discussion:
This happens when a test function is declared inside another function, the one where the tests start running to be precise, using a custom testing framework in a nostd environment. link: at lines: 31 [function declared outside] , 40 [comment of function declared inside] I checked with the latest version of the nightly channel, and could not find any related issues <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Running on your current master branch () doesn't reproduce the issue for me, all tests pass.
That is because the section causing the issue is commented out, if you remove function27 (dont mind the name) from and replace the comment from the function init() in with function27, it should reproduce the issue (just checked again) ! I shouldve pushed and linked a version that reproduces the issue, my bad
I'm able to reproduce this with nightly <details<summary<stronglong file</strong</summary<p</p</details
Got it down to this: using (see ).
claim
Change:
) if **sub_r == RegionKind::ReStatic => { // This is for an implicit `'static` requirement coming from `impl dyn Trait {}`. if let ObligationCauseCode::UnifyReceiver(ctxt) = &cause.code { <ins> // This may have a closure and it would cause ICE // through `find_param_with_region` (#78262). let anon_reg_sup = tcx.is_suitable_region(sup_r)?; let fn_returns = tcx.return_type_impl_or_dyn_traits(anon_reg_sup.def_id); if fn_returns.is_empty() { return None; } </ins> let param = self.find_param_with_region(sup_r, sub_r)?; let lifetime = if sup_r.has_name() { format!("lifetime `{}`", sup_r)

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. --: This bug also exists at . <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Output on 1.46: Changing the closure argument type to compiles successfully on both verions. modify labels: +A-diagnostics +A-lifetimes +regression-from-stable-to-stable
With instead of it compiles successfully too. <details<summaryCode</summary</details
We probably have to check for closures in here.
Assigning as and removing I-prioritize.
Change:
<ins> #![feature(fn_delegation)] #![allow(incomplete_features)] use std::marker::PhantomData; pub struct InvariantRef<'a, T: ?Sized>(&'a T, PhantomData<&'a mut &'a T>); impl<'a> InvariantRef<'a, ()> { pub const NEW: Self = InvariantRef::new(&()); //~^ ERROR: no function or associated item named `new` found } trait Trait { fn foo(&self) -> u8 { 0 } fn bar(&self) -> u8 { 1 } fn meh(&self) -> u8 { 2 } } struct Z(u8); impl Trait for Z { reuse <u8 as Trait>::{foo, bar, meh} { &const { InvariantRef::<'a>::NEW } } //~^ ERROR: use of undeclared lifetime name `'a` //~| ERROR: use of undeclared lifetime name `'a` //~| ERROR: use of undeclared lifetime name `'a` //~| ERROR: the trait bound `u8: Trait` is not satisfied //~| ERROR: the trait bound `u8: Trait` is not satisfied //~| ERROR: the trait bound `u8: Trait` is not satisfied //~| ERROR: mismatched types //~| ERROR: mismatched types //~| ERROR: mismatched types } fn main() { } </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' '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: [typeck] type-checking [checkmatch] match-checking -- label +F-constgenerics +F-constevaluatablechecked
Slightly minimized with fewer errors: The compiler seems to have trouble figuring out whether the type of matches the returned type <details<summaryProgram output</summary</summary

<!-- 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<strongICE location label +F-fn_delegation
Adding more methods in trait creates more ICE :eyes: <details<summary<strongBacktrace</strong</summary<p</p</details