jiebi/CodeConvo huggingface dataset:
Change:
place_ty = self.sanitize_projection(place_ty, elem, place, location) } <ins> if let PlaceContext::NonMutatingUse(NonMutatingUseContext::Copy) = context { let tcx = self.tcx(); let trait_ref = ty::TraitRef { def_id: tcx.lang_items().copy_trait().unwrap(), substs: tcx.mk_substs_trait(place_ty.ty, &[]), }; // To have a `Copy` operand, the type `T` of the // value must be `Copy`. Note that we prove that `T: Copy`, // rather than using the `is_copy_modulo_regions` // test. This is important because // `is_copy_modulo_regions` ignores the resulting region // obligations and assumes they pass. This can result in // bounds from `Copy` impls being unsoundly ignored (e.g., // #29149). Note that we decide to use `Copy` before knowing // whether the bounds fully apply: in effect, the rule is // that if a value of some type could implement `Copy`, then // it must. self.cx.prove_trait_ref( trait_ref, location.to_locations(), ConstraintCategory::CopyBound, ); } </ins> place_ty }

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 : I expected to see this: Instead, happens undefined behavior. Program successfully compiles in the Rust but fails to compile in (thats what I want).
Regressed in , likely cc
Visited in the compiler team triage meeting. It would be good to look into closing this ASAP. do you think you'll have time to investigate? If not, I'd want to find someone else.
We've assigned this speculatively to -- if you think you won't be able to investigate promptly, though, feel free to unassign and ping t-compiler for reassignment,
I expected the behavior to match that of this example (which still errors): I wonder if the gets erased somehow. Maybe an "user type annotation" is required on the from a , to give it a lifetime'd type?
Change:
<ins> // compile-flags: -Z unstable-options --document-hidden-items #![crate_name = "foo"] #[doc(hidden)] pub use crate::bar::Bar as Alias; mod bar { pub struct Bar; } // @has 'foo/fn.bar.html' // @has - '//*[@class="rust item-decl"]/code' 'pub fn bar() -> Alias' pub fn bar() -> Alias { Alias } </ins>

Discussion:
rustdoc renders renamed imports () using the new, private name (e.g., in ). This is confusing behavior since the new name is an implementation detail. I think it should be using the original item's name instead. As an example, returns a , but the module it's defined in renames to . I would expect rustdoc to still show the item's definition name, but instead it shows the private name.
I don't think this should be changed until is fixed. Otherwise you could have two items shown with the same name and namespace in the same scope.
Code to reproduce: I don't think we need to wait for to be fixed as the fix for this doesn't impact it: if the re-export is not publicly reexported, we simply show the item underneath. When we will it will handle it the same.
Change:
<ins> // Copyright 2017 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. // regression test for issue #41498. struct S; impl S { fn mutate(&mut self) {} } fn call_and_ref<T, F: FnOnce() -> T>(x: &mut Option<T>, f: F) -> &mut T { *x = Some(f()); x.as_mut().unwrap() } fn main() { let mut n = None; call_and_ref(&mut n, || [S])[0].mutate(); } </ins>

Discussion:
hi, my code used to compile last week. I updated the compiler today and now it crashes note that you can get my code here ()
note: going back to nightly-2017-04-01; everything work again. 'nightly-2017-04-17 is not ok. so troubles started somewhere in between.
cc
not too sure what to do with this message. can I help you with something ? I can do a small dichotomy to figure out the last working nightly if this can help.
Minified:
there is a pending fix (), no action needed on your part
triage: P-high
Change:
// Defining use functions may have more bounds than the opaque type, which is ok, as long as the // hidden type is well formed even without those bounds. let predicate = <del> ty::Binder::dummy(ty::PredicateKind::WellFormed(hidden_type.into())).to_predicate(tcx); </del> <ins> ty::Binder::dummy(ty::PredicateKind::WellFormed(hidden_ty.into())).to_predicate(tcx); </ins> ocx.register_obligation(Obligation::new(misc_cause, param_env, predicate)); // Check that all obligations are satisfied by the implementation's

Discussion:
Since the nightly 2022-09-11, the following code doesn't compile anymore. <!-- 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
Minimized it a little
searched nightlies: from nightly-2022-01-01 to nightly-2022-09-30 regressed nightly: nightly-2022-09-11 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
cc
cc
I get the same ICE when using the current nightly in a complex Codebase. The works fine.
I think I minimized this to:

<!-- 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: <!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I found this error occurred by this commit through
Probably cc
Minimized: claim label F-typealiasimpl_trait T-compiler
This has caused crate and docs fail to build.
This just upgraded from bad diagnostics to ICE on latest nightly.
Change:
<ins> // Copyright 2018 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. #![feature(termination_trait_lib)] fn main() -> impl std::process::Termination { } </ins>

Discussion:
we’re stabilizing the combination of features that allows you to put in the return type of main as in . Amusing but unintended so it’s better to forbid this for now.
It's a bit late to change this. Does it cause any problem? AFAICT it just gives you a weird way to declare , but no new capability.
It doesn't give any new capability, I guess would even make sense in the return type of main. This bug could be considered a feature.
cc
Why this is an issue? returns and implements .
does not implement , which is required for the return type of .
Yea, it seems you can use any trait: Works on beta and nightly. So it'll probably work on this weeks stable You can't do anything stupid with this feature. The checks see right through the impl Trait to the real type (). I'd say adding a regression test that ensures that this corner case essentially ignores the anonymization of impl Trait is fine. We can add a deny by default lint that tells you that while this works, it's not pretty.
This seems fine to me and unless we care enough to stop the stable release we're not going to change this. cc though.
Hmm, I feel like we should just fix this. I doubt there are a lot of people taking advantage of it. I can put up some mentoring instructions. We can do a warning period if needed.
Fwiw I tried fixing by doing and got ICEs and stack oveflows which I couldn't debug so I gave up.
Hmm, I don't understand the stack overflows, but I think I would expect that patch to have no effect. The cause of the bug is that we are "instantiating" the impl Trait, here: In the process, we shadow the "original" with a new variable . This new will contain an inference variable used to find the "hidden" type underneath the . Later on, when we add the obligation that (where is the return type), we use this new variable: If we used the original (currently shadowed) , I think it would permit you to use but not other impl traits. (That said, it wouldn't be the end of the world if we just let this go, I suppose.)
As far as I understand we don't want to block 1.26 stable on this, right?

In that case I think we should go with a lint instead of an hard error, since both of the features will be stabilized now.
I probably borked the state of my clone or something. Thanks for the explanation, makes perfect sense, will make a patch.
Change:
<ins> error[E0425]: cannot find value `demo` in this scope --> $DIR/suggest-let-for-assignment.rs:4:5 | LL |     demo = 1; |     ^^^^ | help: you might have meant to introduce a new binding | LL |     let demo = 1; |     +++ error[E0425]: cannot find value `demo` in this scope --> $DIR/suggest-let-for-assignment.rs:5:10 | LL |     dbg!(demo); |          ^^^^ not found in this scope error[E0425]: cannot find value `x` in this scope --> $DIR/suggest-let-for-assignment.rs:7:5 | LL |     x = "x"; |     ^ | help: you might have meant to introduce a new binding | LL |     let x = "x"; |     +++ error[E0425]: cannot find value `x` in this scope --> $DIR/suggest-let-for-assignment.rs:8:23 | LL |     println!("x: {}", x); |                       ^ not found in this scope error[E0425]: cannot find value `x` in this scope --> $DIR/suggest-let-for-assignment.rs:10:8 | LL |     if x == "x" { |        ^ not found in this scope error[E0425]: cannot find value `y` in this scope --> $DIR/suggest-let-for-assignment.rs:15:5 | LL |     y = 1 + 2; |     ^ | help: you might have meant to introduce a new binding | LL |     let y = 1 + 2; |     +++ error[E0425]: cannot find value `y` in this scope --> $DIR/suggest-let-for-assignment.rs:16:23 | LL |     println!("y: {}", y); |                       ^ not found in this scope error: aborting due to 7 previous errors For more information about this error, try `rustc --explain E0425`. </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:
<ins> // ICE: ImmTy { imm: Scalar(alloc1), ty: *const dyn Sync } input to a fat-to-thin cast (*const dyn Sync -> *const usize // or with -Zextra-const-ub-checks: expected wide pointer extra data (e.g. slice length or trait object vtable) // issue: rust-lang/rust#121413 //@ compile-flags: -Zextra-const-ub-checks // ignore-tidy-linelength #![feature(const_refs_to_static)] const REF_INTERIOR_MUT: &usize = { static FOO: Sync = AtomicUsize::new(0); //~^ ERROR failed to resolve: use of undeclared type `AtomicUsize` //~| WARN trait objects without an explicit `dyn` are deprecated //~| ERROR the size for values of type `(dyn Sync + 'static)` cannot be known at compilation time //~| ERROR the size for values of type `(dyn Sync + 'static)` cannot be known at compilation time //~| WARN this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2021! unsafe { &*(&FOO as *const _ as *const usize) } }; pub fn main() {} </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

<!-- [31mICE[0m: Rustc '-Zcrate-attr=feature(constrefstostatic) -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: expected wide pointer extra data (e.g. slice length or trait object vtable)', 'error: internal compiler error: expected wide pointer extra data (e.g. slice length or trait object vtable)' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion information Command: &lt;!-- Include a backtrace in the code block by setting in your environment. E.g. . --&lt;details&lt;summary&lt;strongProgram output&lt;/strong&lt;/summary&lt;p&lt;/p&lt;/details&lt;!-- query stack: [evaltoallocationraw] const-evaluating + checking [evaltoconstvalueraw] simplifying constant for the type system [analysis] running analysis passes on this crate --
cc
You can add to get this kind of stacktrace:
Change:
let projected_term = selcx.infcx.resolve_vars_if_possible(projected_term); <del> let result = if projected_term.has_projections() { </del> <ins> let mut result = if projected_term.has_projections() { </ins> let mut normalizer = AssocTypeNormalizer::new( selcx, param_env,

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 expected to see this happen: The compiler compiles successfully or outputs an error message. Instead, this happened: The code, as provided below, appears to encounter a hang <!-- 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 same problem is reproduced on the nightly version(2023-10-15;) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
This seems to be a type of quadratic blowup that changed in 1.73. I did some tests by altering the number of calls:
searched nightlies: from nightly-2023-08-01 to nightly-2023-10-16 regressed nightly: nightly-2023-08-19 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details cc
Change:
)) ); <ins> let should_convert_option_to_result = format!("{}", trait_ref.print_only_trait_path()) .starts_with("std::convert::From<std::option::NoneError"); let should_convert_result_to_option = format!("{}", trait_ref) .starts_with("<std::option::NoneError as std::convert::From<"); if is_try && is_from && should_convert_option_to_result { err.span_suggestion_verbose( span.shrink_to_lo(), "consider converting the `Option<T>` into a `Result<T, _>` using `Option::ok_or` or `Option::ok_or_else`", ".ok_or_else(|| /* error value */)".to_string(), Applicability::HasPlaceholders, ); } else if is_try && is_from && should_convert_result_to_option { err.span_suggestion_verbose( span.shrink_to_lo(), "consider converting the `Result<T, _>` into an `Option<T>` using `Result::ok`", ".ok()".to_string(), Applicability::MachineApplicable, ); } </ins> let explanation = if obligation.cause.code == ObligationCauseCode::MainFunctionType { "consider using `()`, or a `Result`".to_owned()

Discussion:
It seems that should provide a better error message or hint when one tries to use the operator on an in a function returning a or vice-versa. Currently this is the error you get: However, it would be better to suggest the use of or , or , instead of referencing something dependent on the feature (). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This error is emitted here: We could look at whether the is , and if so, provide a more targeted error, including a structured suggestion for .
Can I claim this issue?
claim
Change:
#[inline] #[stable(feature = "rust1", since = "1.0.0")] pub unsafe fn write<T>(dst: *mut T, src: T) { <del> // FIXME: the debug assertion here causes codegen test failures on some architectures. // See <https://github.com/rust-lang/rust/pull/69208#issuecomment-591326757>. // debug_assert!(is_aligned_and_not_null(dst), "attempt to write to unaligned or null pointer"); </del> <ins> debug_assert!(is_aligned_and_not_null(dst), "attempt to write to unaligned or null pointer"); </ins> intrinsics::move_val_init(&mut *dst, src) }

Discussion:
In , we document more precisely the rules for the various methods that can be used to access memory through raw pointers. In particular, we clarify that the pointer must be non-NULL and aligned even when the access has size 0. This issue is about helping people find bugs in libstd by adding a to all these methods testing that condition, similar to what I did . I suggest to add a helper method to raw pointers to test this, and also use that for and . This may uncover issues in libstd, uncovering misuses of these methods. Those should then be fixed.
I might be interested in working on that. Could you help me with a starting point for that?
You might want to start with It could get a check similar to To avoid code duplication, consider adding a (private) helper method in for this purpose, and using it in both the old places () and . Other candidates besides are and . We could also go further, but maybe we should involve the libs team there... so let's get started with these 3.
Sorry for the delay, it took me a while to free up some time. Quick questions: I found in However, one is just a delegation to the intrinsic, and the other one is for , which is just a call to the previous one. Should I hunt the intrinsic in the C code, or provide a rust wrapper that will check the assumptions and call the intrinsic? I couldn't find a in The only ones I could find were for , , and in . Am I missing something?
Ah, intrinsics are still written in Rust, but as code generation functions. Well, I guess adding debug assertions everywhere in the intrinsics would be counter-productive, so we're going for the wrapper? Although, I'm not sure how to cleanly hijack the interface: I have to keep using the same function name for the callers, so that I don't have to change their code, but unless I don't understand how it works, I also need to have the same signature including the function name for the code generation. How should I proceed?
Ah good point, I forgot about these reexports. I think the right way forward is to replace by a wrapper function that just calls the intrinsic. The docs should be moved from to . That move should be a total NOP.

The, in the 2nd step, you can add the in the delegating wrapper you just . Sorry, I meant the one in . It already has a , but that does not test as much as it could (i.e., it accepts NULL).
Congrats, your patch landed. :) So with the preparation out of the way, let me know if you need any help with adding the debug assertions.
Thanks! I should be okay, I just need to find the time :) I'll ping you when it's ready for review.
Cc
Change:
<ins> fn main() { let baz = ().foo(); //~ ERROR no method named `foo` found for type `()` in the current scope <i32 as std::str::FromStr>::from_str(&baz); // No complaints about `str` being unsized } </ins>

Discussion:
Because of the method error, doesn't get a type (not even , AFAICT), and then it gets inferred to from another call in the function, which results in the unsized variable error.
cc
I'd expect a simple fix for this would be to actually set as 's type, so it can't be inferred to anything else, although that could make other errors less informative.
I just spent a lot of time looking at a error. The errors were hidden by a couple of screens of "doc comment not used by rustdoc" warnings. Because was unknown, the compiler assumed it implemented no traits at all, leading to misleading errors below and user confusion: "why isn't it when this other similar type similar is?", "how can I find out if a type is " and so on. I don't know if works like that, but in this case it might be better to assume that the type implements any trait it's required to.
That doesn't really work out, since the issue here is that inference gets a free pass instead of inferring which would at least signal anything. The fix seems simple, I really don't know why I haven't tried it yet
I'm not saying that the type should be inferred to something else from the code below (like you said it was happening in the issue description) -- that seems bad. But on the other hand the compiler should probably not report an error every place the type or variable is used.
I just reread, and: That's not relevant here - the problem is inference flows up into the variable, which is correct in other cases but in this case it infers the slice type which is unsized. The error is a mere side-effect.
The underlying cause is that we have two maps for →, a general one and one for locals. When type checking we write to the general one but the one for locals is only written to once, during initialization, and the we read from it. If we kept it up to date or read from the general map, the knock-down error wouldn't appear.
Change:
} else { err.span_label(arm_span, msg); } <del> } </del> <ins> }, hir::MatchSource::TryDesugar => { // Issue #51632 if let Ok(try_snippet) = self.tcx.sess.codemap().span_to_snippet(arm_span) { err.span_suggestion_with_applicability( arm_span, "try wrapping with a success variant", format!("Ok({})", try_snippet), Applicability::MachineApplicable ); } }, </ins> _ => { let msg = "match arm with an incompatible type"; if self.tcx.sess.codemap().is_multiline(arm_span) {

Discussion:
Given this example: I get this error (): It seems like it should not be talking about =)
Ideally, I would think it should say something like "missing ", but that may be a separate bug -- i.e., maybe we should strive to just produce the same error you would get if you did
Change:
<ins> error: `recursion_limit` must be a non-negative integer --> $DIR/invalid_digit.rs:3:1 | LL | #![recursion_limit = "-100"] | ^^^^^^^^^^^^^^^^^^^^^------^ |                      | |                      not a valid integer error: aborting due to previous error </ins>

Discussion:
The following code since it exceeds the default recursion limit. Using as the recursion limit works as expected. This is because we don't check for integer overflow errors when parsing limits: There's a few options here. My preference would be to silently default to when overflow occurs. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Hi! I'd like to try and handle this. If I understand this correctly, we should check if there is an , and if that error is an overflow. If it's an overflow, we default to ? claim
correct