jiebi/CodeConvo huggingface dataset:
Change:
<ins> static _MAYBE_STRINGS: [Option<String>; 5] = [None; 5]; //~^ ERROR the trait bound `String: Copy` is not satisfied </ins> fn main() { // should hint to create an inline `const` block // or to create a new `const` item <del> let strings: [String; 5] = [String::new(); 5]; </del> <ins> let _strings: [String; 5] = [String::new(); 5]; //~^ ERROR the trait bound `String: Copy` is not satisfied let _maybe_strings: [Option<String>; 5] = [None; 5]; </ins> //~^ ERROR the trait bound `String: Copy` is not satisfied <del> println!("{:?}", strings); </del> }

Discussion:
I'm basing this suggestion on two things. One, that if you follow it, the code compiles: and two, that the diagnostic help you get when you try to use a in the repeat position suggests something very similar, see "other cases." It would require the compiler to know that a value that is attempted to be repeated is able though, which I don't know whether it can, but I figured I'd suggest this, and you can reject it if it isn't possible to do. Alternatively, the help text could say something like "if the value can be made , consider creating [...]" I was inspired to make this issue based on the output you get when you try to use a as an array initializer. For instance, the code produces the output No response
hey why im getting this error message all over my github repository ! whenever i commit some changes, The first changes i able to create pull request but after some other changes im not able to do that why im getting these error ! Please help
I don't think your comment is related to this issue? If this is a problem you've encountered while trying to fix this issue, please reach out on instead.
Change:
} pub fn type_is_sized<'a, 'tcx>(tcx: TyCtxt<'a, 'tcx, 'tcx>, ty: Ty<'tcx>) -> bool { <del> ty.is_sized(tcx, ty::ParamEnv::empty(traits::Reveal::All), DUMMY_SP) </del> <ins> ty.is_sized(tcx.at(DUMMY_SP), ty::ParamEnv::empty(traits::Reveal::All)) </ins> } pub fn type_is_freeze<'a, 'tcx>(tcx: TyCtxt<'a, 'tcx, 'tcx>, ty: Ty<'tcx>) -> bool {

Discussion:
One example is the method on . Internally it creates a , when it could simply be taking exactly that as an argument. In miri I had to write which just feels a little riddiculous (taking apart the , just to have the method construct it back). There's probably many other similar methods and functions that should be taking a
Can I take this one if no one is working on that ?
it's all yours!
Change:
} fn all_constructors(cx: &MatchCheckCtxt, m: &Matrix, left_ty: ty::t) -> Vec<ctor> { <ins> // This produces a list of all vector constructors that we would expect to appear // in an exhaustive set of patterns. Because such a list would normally be infinite, // we narrow it down to only those constructors that actually appear in the inspected // column, plus, any that are missing and not covered by a pattern with a destructured slice. </ins> fn vec_constructors(m: &Matrix) -> Vec<ctor> { let max_vec_len = m.iter().map(|r| match r.get(0).node { PatVec(ref before, _, ref after) => before.len() + after.len(), _ => 0u }).max().unwrap_or(0u); <del> let contains_slice = m.iter().any(|r| match r.get(0).node { PatVec(_, ref slice, _) => slice.is_some(), _ => false }); let lengths = iter::range_inclusive(0u, if contains_slice { max_vec_len } else { max_vec_len + 1 }); lengths.map(|len| vec(len)).collect() </del> <ins> let min_vec_len_with_slice = m.iter().map(|r| match r.get(0).node { PatVec(ref before, Some(_), ref after) => before.len() + after.len(), _ => max_vec_len + 1 }).min().unwrap_or(max_vec_len + 1); let other_lengths = m.iter().map(|r| match r.get(0).node { PatVec(ref before, _, ref after) => before.len() + after.len(), _ => 0u }).filter(|&len| len > min_vec_len_with_slice); iter::range_inclusive(0u, min_vec_len_with_slice) .chain(other_lengths) .map(|len| vec(len)) .collect() </ins> } match ty::get(left_ty).sty {

Discussion:
It looks like introduced a regression. The following used to work: but now generates the following error:
Yeah, sorry about that! There's already a fix for this in
I am also now seeing spurious 'non-exhaustive patterns' errors when attempting to match struct variants of an imported enum type. For example, here is a simplification of some code in : The error is:
Oh dear. Looks like it only fails when the enum is defined in a different crate as this works: I'll take a look!
Please add an appropriate test for this case... Niko
I a test for the cross-crate case in . There are already quite a few existing tests for local variants.
On Sun, Jun 22, 2014 at 07:43:54AM -0700, Jakub Wieczorek wrote: great
Change:
// ignore-msvc everything is the system allocator on msvc // ignore-musl no dylibs on musl yet <ins> // ignore-bitrig no jemalloc on bitrig </ins> // aux-build:allocator-dylib.rs // no-prefer-dynamic // error-pattern: cannot link together two allocators

Discussion:
After the new snapshots landed, test failures showed up.
failures: [run-pass] run-pass/allocator- [run-pass] run-pass/allocator-
it looks like the outstanding jemalloc issues are finally biting us.
Change:
<ins> fn main() { foo::( //~ HELP: consider removing the `::` here to call the expression //~^ NOTE: while parsing this parenthesized list of type arguments starting bar(x, y, z), bar(x, y, z), bar(x, y, z), bar(x, y, z), bar(x, y, z), bar(x, y, z), bar(x, y, z), baz("test"), //~ ERROR: expected type, found `"test"` //~^ NOTE: expected type ) } </ins>

Discussion:
Given an invalid call such as: The following diagnostic is issued: This gets much worse on multiline calls: Which just prints out a diagnostic nowhere near the error: Ideally this should mention something about either missing a missing turbofish (e.g. ), or a missing identifier (e.g. ). This would at least get the error pointing to the correct spot. Latest playground nightly (2024-02-09) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Oh, wow, it didn't even occur to me until now that the expression is syntactically valid .< Edit: Wow, even is syntactically well-formed.
This should pretty easy to fix, basically if we fail to parse a type here we should first of all attach a label to the saying something akin to while parsing this list of parenthesized type arguments starting here and we should suggest removing the trailing path separator if the is , the parenthesized generics aren't followed by or and if the list of non-types we encountered can be successfully parsed as a list of expressions (using a snapshot parser). Furthermore, if the is we can try to reparse the list as a list of patterns and provide the same structured suggestion. I will gladly mentor & review any PR for this.
claim
Hello , is this issue still open for mentoring? I can see that already claimed the issue, but there seems to be no progress.
I read the code but no time to finish it at the moment. You can do it.
Change:
/// /// [`once_with`]: fn.once_with.html #[derive(Copy, Clone, Debug)] <del> #[unstable(feature = "iter_once_with", issue = "57581")] </del> <ins> #[stable(feature = "iter_once_with", since = "1.43.0")] </ins> pub struct OnceWith<F> { gen: Option<F>, } <del> #[unstable(feature = "iter_once_with", issue = "57581")] </del> <ins> #[stable(feature = "iter_once_with", since = "1.43.0")] </ins> impl<A, F: FnOnce() -> A> Iterator for OnceWith<F> { type Item = A;

Discussion:
This is the tracking issue for . Currently in nightly, PR = .
Is this function now ready for stabilization?
I don’t see why not. Tracked here: fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
I noticed that this iterator has been stabilized a impl which I assume wasn't intentional so I've submitted to remove it.
Change:
///     None => println!("{} is not defined in the environment.", key) /// } /// ``` <ins> /// /// [`PathBuf`]: ../../std/path/struct.PathBuf.html </ins> #[stable(feature = "env", since = "1.0.0")] pub fn split_paths<T: AsRef<OsStr> + ?Sized>(unparsed: &T) -> SplitPaths<'_> { SplitPaths { inner: os_imp::split_paths(unparsed.as_ref()) }

Discussion:
Reading both and there's no specification that the type for the iterator is . To me it seemed ambiguous what an "iterator that splits an environment variable into paths" or "an iterator over the paths" returns since it could be the string representing the paths -- which is -- or an actual object. I'm happy to submit a PR if this is makes sense enough to fix (since according it used to specify this detail and now it doesn't with a quick perusal of not turning up anything obvious as to why the change).
If you unfold at the Trait Implementation section in you can see that . Did you mean that this should be more clearly mentioned in the description of (or maybe as well)? I do think it would be nice if some extra text on would be that clarifies the item type of the iterator!
since I didn't even think of expanding for the info (which in hindsight makes sense), my answer is "yes" , mentioning it explicitly as part of the main summary would be handy". As I said, if this is deemed reasonable I'm happy to do the PR to add the change.
That would be great! Let us know what you come up with!
Looks like someone snagged fixing this before I had a chance to get to it, so I'll let and its author handle fixing this.
Nice :) Let's wait for that then :)
Change:
cmd.arg("--src-base").arg(builder.src.join("src/test").join(suite)); cmd.arg("--build-base").arg(testdir(builder, compiler.host).join(suite)); cmd.arg("--stage-id").arg(format!("stage{}-{}", compiler.stage, target)); <ins> cmd.arg("--suite").arg(suite); </ins> cmd.arg("--mode").arg(mode); cmd.arg("--target").arg(target.rustc_target_arg()); cmd.arg("--host").arg(&*compiler.host.triple);

Discussion:
When compiletest fails, it prints an error summary like this at the end: However, there is one very important bit of information that I cannot gleam from this information: what are the host and target architectures that were tested! Figuring this out requires scrolling up quite a bit to where this test beings (and carefully not scrolling up too far because then one might look at the wrong test). See for an example where this confused people. I have also been confused by this multiple times in the past, e.g. using the name of the CI runner to incorrectly deduce what the architecture(s) are (and not realizing that some of our runners run tests for quite a few different targets). So I think in case of a failure, that summary at the end should repeat the important information that is printed at the top of the test run:
Cc
And also it would be nice if when it ignored a test because it was the wrong platform, it showed some indication of that, because otherwise it looks like it ran the test and it passed. Perhaps show a question mark ()? (We already use for tests that were ignored because they were already run and passed.)
AFAIK should already be used for all kinds of "ignored", including directives.
Turns out these messages are printed by bootstrap, not compiletest: However, detecting failures and exiting is done a few layers deeper: In case of failure, never returns or unwinds (except if fail-fast is off). I am not sure how to best adjust this to print an error before exiting (or to always print an error after the process finished, whether it succeeded or failed). any advice? If we just want this to happen when fail-fast is off, that would be easy, but I am not sure if that ever applies.
Change:
.trait_item_def_id .expect("Part of a trait implementation, but not linked to the def_id?"); let trait_method = tcx.associated_item(method_id); <del> if traits::is_vtable_safe_method(tcx, trait_ref.skip_binder().def_id, trait_method) { </del> <ins> let trait_id = trait_ref.skip_binder().def_id; if traits::is_vtable_safe_method(tcx, trait_id, trait_method) && tcx.object_safety_violations(trait_id).is_empty() { </ins> // Trait methods will have a Self polymorphic parameter, where the concreteized // implementatation will not. We need to walk back to the more general trait method let trait_ref = tcx.instantiate_and_normalize_erasing_regions(

Discussion:
<!-- [31mICE[0m: Rustc '-Zsanitizer=cfi -Ccodegen-units=1 -Clto -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: typeidforinstance: couldn't get fnabi of instance Layout(ReferencesError(ErrorGuaranteed(())))', 'error: internal compiler error: typeidforinstance: couldn't get fnabi of instance Layout(ReferencesError(ErrorGuaranteed(())))' 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: --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim
Change:
<ins> error[E0403]: the name `M` is already used for a generic parameter in this item's generic parameters --> $DIR/self-referential.rs:1:30 | LL | trait Foo<const M: u8, const M: u8 = M> {} |                 -            ^ already used |                 | |                 first use of `M` error: aborting due to previous error For more information about this error, try `rustc --explain E0403`. </ins>

Discussion:
Found with a <details<summaryFull output including backtrace</summary</detailsRegression in nightly-2021-04-26, possibly from ( label +A-const-generics
Here's a simpler case that ICEs in a similar way. It ICEd at least as far back as nightly-2018-01-01 (with the keyword removed for older versions). Output: <details<summaryFull output</summary</details
A similar thing was fixed a week ago in but maybe a more general fix is needed.
This fix probably needs to go into the resolver -- Using to distinguish the identifers in the example: I think the issue is that is resolving to , instead of , so when we do the partial substitution of default const params, we end up trying to look for while is being created.
Similar ICE with struct instead of impl trait:
This would be inconsistent with how lifetimes work. You can have . I suggest a check in astconv, replacing the self-referential type/const by error type/const.
Change:
sigaltstack(&stack, ptr::null_mut()); Handler { _data: stack.ss_sp as *mut libc::c_void } } else { <del> Handler { _data: ptr::null_mut() } </del> <ins> Handler::null() </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 tried this code: and compiled it with: I expected to see asan report a bad pointer use and give a backtrace. Instead I just got a raw sigsegv: Running with verbose output shows that AddressSanitizer is intercepting the signal. It looks like is also installing a signal handler, which is overriding the AddressSanitizer one. <!-- 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. --: </p</details
(set handler and prevent override) is a workaround, but I think the Rust runtime shouldn't stomp SIGSEGV in the sanitizer case.
cc
Change:
let input = "use asdf::qwop; assert_eq!(2+2, 4);"; let expected = "#![feature(sick_rad)] <del> extern crate asdf; </del> <ins> extern crate r#asdf; </ins> fn main() { use asdf::qwop; assert_eq!(2+2, 4);

Discussion:
In I tried to create a new testcase that runs doctests. However having the substring in a doctest comment injected an invalid into the code generated for the doctest. Turns out this here is a bit too aggressive: It looks like compiletest actually gave the crate the name , perhaps because it was defined in a file, and having a doctest such as this triggers the this auto-injection, resulting in a failed doctest run: /// // ^ line 10 /// assert_eq!(1, 1); /// `
I think rustdoc needs to check if the crate name is a keyword and add if so. Actually it's probably enough to unconditionally add since it works for things that aren't keywords.
there is actually two bugs here. not being properly escaped is one thing, the other is probably the way that rustdoc is invoked, or not quite sure. Basically it infers the crate name from the file name if not explicitly given, and then just assumes that a crate with that name exists, which it doesn’t.
that's an issue with compiletest, not rustdoc - it needs to compile the crate itself before running rustdoc on it: I don't know how to fix that, I think compiletest needs to add support for this maybe?
Change:
<ins> // check-pass mod m { pub enum Same { Same, } } use m::*; // The variant `Same` introduced by this import is not considered when resolving the prefix // `Same::` during import validation (issue #62767). use Same::Same; fn main() {} </ins>

Discussion:
Reproduction code: If I re-export in the module, it works as expected, having enum in the type-namespace and variant in the value-namespace ().
Compiler team check-in: I'm marking this as P-medium for now as it is not classified as a regression, although it seems like a fairly major problem. appears to be on it, though.
Feel free to add the I-nominated label if you think it should be P-high
late last year. could you take a look at this to see if it is valid for the invariant being checked not to hold in this case? If I comment out the the output is reasonable:
I'll see what happens (that's why I self-assigned). The assert is there to catch the cases that resolve logic assumes to be impossible. It may work ok if the assert is removed, but it may also mean some deeper issues, this needs a more detailed look.
The above error message without the looks a lot like and .
but it may also mean some deeper issues was exactly the case here! Thank you for reporting. Fixed in
Change:
)); } <ins> // FIXME: remove the suggestions that are from derive, as the span is not correct suggestions = suggestions .into_iter() .filter(|(span, _, _)| !span.in_derive_expansion()) .collect::<Vec<_>>(); </ins> if suggestions.len() == 1 { let (span, suggestion, msg) = suggestions.pop().unwrap();

Discussion:
Given the following code: current output is: The last part of the suggestion is not valid Rust code and therefore should not be suggested like this. This problem occurs on the Playground on both stable and nightly with basically identical error messages. serde v1.0.147 requires such that will be . Otherwise the problem does not seem serde specific. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
do you know how to create a minimal case without ? so we may add it to unit testing. I give a fix and verified it's OK with my local testing, but I'm struggle to construct a minimal case without to reproduce it.
I assume this reproduces when using the same setup of derive macro implementing a trait while the implementation is missing bounds. I don't know if it is relevant that the derive macro produces a trait. Something along these lines, with the proc macro crate omitted.
yes, it's caused by derive macro.
emmmet this error
Change:
DeprecatedOwnedVector, Warnings, <ins> RawPointerDeriving, </ins> } pub fn level_to_str(lv: level) -> &'static str {

Discussion:
In the following, the does the wrong thing: it shallow copies the pointer when the semantics mean it should be making a new allocation and copying the data; there's no indication of this until runtime double-frees/segfaults. Some possible resolutions: do nothing: unsafe code is unsafe have lints for + unsafe pointers have completely disabled on unsafe pointers remove the trait impls for raw pointers
I favor a lint.
(I'm happy to mentor this.)
I'm interested in doing this. I'll find on IRC.
Change:
A link was used without a name parameter. Erroneous code example: <del> ```ignore (cannot-test-this-because-rustdoc-stops-compile-fail-before-codegen) </del> <ins> ```compile_fail,E0459 </ins> #[link(kind = "dylib")] extern {} // error: `#[link(...)]` specified without `name = "foo"` ```

Discussion:
The below code (in ) has three doc tests: first succeeds as expected. second test fails as expected: the constant would be and there is an attempt to subtract with overflow. third test should succeed as it has the exact same code as the second test but is marked as . However the test fails with the message “Test compiled successfully, but it's marked .” rust /// let works = cf::S::<u32::default(); /// (); /// rust /// let shouldfail = cf::S::<u64::default(); /// (); /// compilefail /// let shouldfail = cf::S::<u64::default(); /// (); ///
This is a consequence of how works. (and ) does the equivalent of (or the same as ), which does not perform all steps of compilation (like codegen and linking). One of the issues tracking this problem is . I'm not sure why rustdoc does not perform the full compilation steps for and .
Change:
// current number of evaluated terminators is a power of 2. The latter gives us a cheap // way to implement exponential backoff. let span = ecx.cur_span(); <del> ecx.tcx.dcx().emit_warn(LongRunningWarn { span, item_span: ecx.tcx.span }); </del> <ins> // We store a unique number in `force_duplicate` to evade `-Z deduplicate-diagnostics`. // `new_steps` is guaranteed to be unique because `ecx.machine.num_evaluated_steps` is // always increasing. ecx.tcx.dcx().emit_warn(LongRunningWarn { span, item_span: ecx.tcx.span, force_duplicate: new_steps, }); </ins> } }

Discussion:
I tried the following code: output after running for a very long time: modify rustc as follows results in the following output: changing the invocation to actually prints the warning at each power of two of steps. This warning should not be affected by . It's whole point is to be repeated multiple times. cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I honestly don't remember if we want it to be repeated or not. Is there even a way for a single diagnostic to opt-out of deduplication? I guess we could put some number into the error message so that it's not the exact same diagnostic each time.
yes, we have full ownership of rustc, we can the deduplication code to stop duplicating this single warning while keeping everything else the same :grin:
claim
Change:
#![feature(bool_to_option)] #![feature(box_patterns)] #![feature(box_syntax)] <del> #![feature(cmp_min_max_by)] </del> #![feature(const_fn)] #![feature(const_panic)] #![feature(core_intrinsics)]

Discussion:
Tracking issue for the feature, which adds the / / / functions to . PR:
Is there anything blocking this from stabilizing?
Doesn't look like it! If somebody would like to open a stabilization PR then we can start a FCP
Stabilization PR up at