jiebi/CodeConvo huggingface dataset:
Change:
} } <ins> pub fn unreachable1() { panic!(); unreachable1(); // WARN unreachable statement } pub fn unreachable2() { loop {} unreachable2(); // WARN unreachable statement } pub fn drop_and_replace(mut a: Option<String>) { //~ ERROR function cannot return without recursing a = None; drop_and_replace(a); } // Calls are assumed to return normally. pub fn call() -> String { //~ ERROR function cannot return without recursing let s = String::new(); call(); s } // Arithmetic operations are assumed not to overflow. pub fn overflow_check(a: i32, b: i32) { //~ ERROR function cannot return without recursing let _ = a + b; overflow_check(a, b); } pub struct Point { pub x: f32, pub y: f32, } impl Default for Point { fn default() -> Self { //~ ERROR function cannot return without recursing Point { x: Default::default(), ..Default::default() } } } </ins> fn main() {}

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code which causes a stack overflow due to a recursive call of I mistakenly . I expected to see the warning. However, the compiler didn't complain it. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.43.0 showed the warning. (ref. ) The warning isn't shown on 1.44.0 or later, including the current stable 1.47.0. <!-- Provide the version you are using that has the regression. --<!-- Did the compiler crash? If so, please provide a backtrace. --<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --
I think this was caused by , but it looks like expected behavior: If diverges, the self-recursion never happens.
Though maybe the lint should assume that functions returning an inhabited type won't diverge (since otherwise they should be marked ). I can definitely see why people would write code like this, so linting on it makes sense.
I personally feel that we should lint for functions if they don't return an uninhabited type. Even if someone wants to exit recursion by unwinding I do feel that a lint is still appropriate here as it is really bad style imo.
Thanks for the quick response. Yeah, it'd be natural to expect a function whose return type is not to return eventually. Probably, we might want to have the following rules?: for self-recursion unless a function returning an uninhabited type is called in advance. a non-diverge function is called before a self-recursion, show a message like "if this diverges, please annotate it." in addition to the warning. 1 would help my case and 2 would help the case of . (2 is not necessary, though.)
Assigning as and removing .
Change:
}; use rustc_middle::ty; use rustc_middle::ty::subst::SubstsRef; <del> use rustc_middle::ty::{Ty, TyCtxt}; </del> <ins> use rustc_middle::ty::{Ty, TyCtxt, TypeFoldable}; </ins> use rustc_span::symbol::{sym, Symbol}; use rustc_target::abi::{Abi, LayoutOf as _, Primitive, Size};

Discussion:
I tried this code: I expected the code to run without errors Instead, the assertion failed. Compiler version: 1.46.0-nightly (2020-07-01 )
Seems something wrong with the intrinsics evaluation.
I think the issue is that is in place when we try to hash . I am not very familiar with the code here but I think this might be evaluated before monomorphization which causes this issue.
Another example showing this is pre-monomorphization: rustc happily compiles this, but I would expect something like .
I was trying to do something somewhat similar with const type_id when I filed . There seem to be some inconsistencies in what combinations of generics and patterns are allowed, which might be contributing to the problem.
I have no idea what is going on, but it certainly looks odd... Cc
needs to monomorphize the type before evaluating it I'd guess (an assert checking for would make sense there, too I'd think).
I wonder if instead of we should more explicitly check for "type or const params", but I think it's mostly about aesthetics thanks to miri working with lifetime-erased types. You said "assert" but I think the type is already monomorphized and what we need to do is return if it's not monomorphic. Same for , actually - any reflection that doesn't rely on will have this problem.
oh right, this may be an evaluation happening too early, so is totally reasonable to emit here. I'm always wary of emitting .
Doesn't that mean that the code samples above will be forbidden?
No, just evaluating the consts early will fail. Once everything is monomorphized it will work.
I have an attempt here: It prevents OP's snippet from compiling:
hmm... maybe const prop is interfering here. Can you try running the same build with and ?
Ah, so this is a different issue. It's the same issue (even if a different symptom) of running
Patterns need to be monomorphic, you can never have a pattern that depends on generic parameters. We may lift this restriction in the future, but it's a separate issue and needs a language RFC afaik
in stable and gives in nightly. We will need a better diagnostics for the TooGeneric error.
works on stable, so the old diagnostic was wrong. It's specifically associated constants that depend on generic parameters.

so is the approach of returning all we need to do here? If so would you be happy to open your branch as a PR so we could look at adding some ui tests and whatnot?
The thing I worried is that the error isn't very helpful. Maybe fixing that diagnostics should be a separate PR?
Yea, cleaning up the diagnostics can be done after fixing the bug
Change:
for (obligation_arg, impl_arg) in std::iter::zip(obligation_trait_ref.args, impl_trait_ref.args) { <ins> if (obligation_arg, impl_arg).references_error() { return false; } </ins> if let Err(terr) = ocx.eq(&ObligationCause::dummy(), param_env, impl_arg, obligation_arg) {

Discussion:
<!-- [31mICE[0m: Rustc '--edition=2021 -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: relating different kinds: {const error}: &'static str KeyNil', 'error: internal compiler error: relating different kinds: {const error}: &'static str KeyNil' 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 [analysis] running analysis passes on this crate --
This bisects to
Minimized further:
Is related? Current ICE-loc: Issue-'s ICE-loc:
cc PR author
Change:
); let normalized_ty = normalizer.fold(projected_term); <del> let mut deduped = SsoHashSet::with_capacity(projected_obligations.len()); projected_obligations.retain(|obligation| deduped.insert(obligation.clone())); </del> Normalized { value: normalized_ty, obligations: projected_obligations } } else { Normalized { value: projected_term, obligations: projected_obligations } }; <ins> let mut deduped = SsoHashSet::with_capacity(result.obligations.len()); result.obligations.retain(|obligation| deduped.insert(obligation.clone())); </ins> if use_cache { infcx.inner.borrow_mut().projection_cache().insert_term(cache_key, result.clone()); }

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> #![allow(warnings)] use std::io::{BufRead, BufReader, Read, Write}; fn issue_81421<T: Read + Write>(mut stream: T) { let initial_message = format!("Hello world"); let mut buffer: Vec<u8> = Vec::new(); let bytes_written = stream.write_all(initial_message.as_bytes()); let flush = stream.flush(); loop { let mut stream_reader = BufReader::new(&stream); //~^ ERROR the trait bound `&T: std::io::Read` is not satisfied [E0277] //~| HELP consider removing the leading `&`-reference //~| HELP consider changing this borrow's mutability stream_reader.read_until(b'n', &mut buffer).expect("Reading into buffer failed"); //~^ ERROR the method `read_until` exists for struct `BufReader<&T>`, } } fn main() {} </ins>

Discussion:
: We currently emit: What is likely desired instead is to use . Seen in the wild at <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
param_env: ty::ParamEnv<'tcx>, } <ins> impl<'tcx> TransferFunction<'_, '_, 'tcx> { /// Returns `true` if this borrow would allow mutation of the `borrowed_place`. fn borrow_allows_mutation( &self, kind: mir::BorrowKind, borrowed_place: &mir::Place<'tcx>, ) -> bool { let borrowed_ty = borrowed_place.ty(self.body, self.tcx).ty; // Zero-sized types cannot be mutated, since there is nothing inside to mutate. // // FIXME: For now, we only exempt arrays of length zero. We need to carefully // consider the effects before extending this to all ZSTs. if let ty::Array(_, len) = borrowed_ty.kind { if len.try_eval_usize(self.tcx, self.param_env) == Some(0) { return false; } } match kind { mir::BorrowKind::Mut { .. } => true, | mir::BorrowKind::Shared | mir::BorrowKind::Shallow | mir::BorrowKind::Unique => !borrowed_ty.is_freeze(self.tcx, self.param_env, DUMMY_SP), } } } </ins> impl<'tcx> Visitor<'tcx> for TransferFunction<'_, '_, 'tcx> { fn visit_rvalue( &mut self,

Discussion:
This code: Errors on with this message:
cc
regression in
I'm still building a compiler with graphviz debugging enabled so I can have a closer look, but I have a theory. I believe the problem is that we are too conservative when marking locals as . Because we pessimistically assume that type is , we also assume that type can be mutated through a shared reference. Once a shared reference to it is taken, we assume that all qualifs that could apply to are applied to that local. We should special case zero-sized arrays here, so when the borrow of occurs, it is not marked as indirectly mutable. Perhaps we could assume that zero-sized arrays never actually as well? While this change would solve this particular issue, I believe that this won't solve the problem entirely. What if we take two references to the zero-sized type ()? While the local containing the ZST itself will not be marked as indirectly mutable, the local containing the first borrow will be, which diverges from the old analysis. We may need to base whether a is indirectly mutable on the analysis.
Change:
panic::set_hook(Box::new(move |info| { let show = BridgeState::with(|state| match state { BridgeState::NotConnected => true, <del> // Something weird is going on, so don't suppress any backtraces BridgeState::InUse => true, BridgeState::Connected(bridge) => bridge.force_show_panics, </del> <ins> BridgeState::Connected(_) | BridgeState::InUse => force_show_panics, </ins> }); if show { prev(info)

Discussion:
Between nightly-2020-08-29 and nightly-2020-09-02, the following began printing an ICE message (despite compiling successfully). The relevant compiler commit range is appears extremely relevant so mentioning From the PR description it sounds like the PR was intended to have no effect unless the new -Z flag is passed. Is it possible it could be causing this? Before: After:
It looks like I misunderstood how works. I'll PR a fix tomorrow.
Assigning as and removing .
PR is up at
Change:
fn main() { m!(a); <del> //~^ ERROR expected a lifetime, found `a` </del> <ins> //~^ ERROR no rules expected the token `a` </ins> }

Discussion:
This is similar to the same buggy behavior we saw for matchers fixed in 1.20.0. For example in Rust 1.19 the following code fails to compile with the message , but correctly prints followed by as of 1.20. The matcher is currently broken in the same way. rustc 1.28.0-nightly ( 2018-06-09)
The ident issue was , so mentioning who fixed that one in . Would you be interested in taking a look at this similar case?
Duplicate of . should still be working on it I think?
Thanks! Let's continue to track this as part of .

is not valid lifetime, so using specifier should not cause local ambiguity. Example: cc tracking issue for $:lifetime matcher:
The problem is that currently a lifetime "may start with anything" because we haven't spelled out the rules. Edit , and insert the case into the function. You may also want to review this function to see if any case did not consider and recent syntax additions.
I'd like to take this issue
I'm on a train right now with limited connectivity, so I cant push my PR, but I have a change that I've compiled and tested, and I'm not sure if it's working correctly, I could use some more background. I this to maybeginwith, compiled and set as a custom toolchain all good so far I created a new cargo bin project (I didn't see any tests for macro_parser or any test dirs in the libsyntax directory, not sure if there's a better way to do this) and made the main function define that macro and use it, as in the original example. With nightly it showed the expected ambiguity error. Then I used rustup overrides with my custom toolchain and rebuilt, and it compiled with no errors. Is this the expected behavior when parsing the macro? I'm unclear on how the macro parser works in rust. Is it that, before adding this branch, when parsing they both matched the specifier. But after adding the bit that says "no that ain't a lifetime," it no longer gets caught by that arm of the macro, and when parsing the , it just skips it and doesn't complain? I guess I was expecting it to say something like "lifetimes cant start with #" instead of the local ambiguity, not for it to just stop being an error. Also, you mentioned reviewing the rest of the function to see if other things didn't consider lifetime or other new syntax additions, but I'm not sure what other syntax additions there are to consider.
Yes this is the expected behavior. When returns false, the parser knows that is definitely not a and thus stop matching against . The original template expects a next, which it matched, and thus everything goes fine. This is similar to the behavior of Basically to check the interaction with all other fragment specifiers, e.g. Interpolated lifetimes are encoded as which I don't see listed in the function.

But maybe adding a case is sufficient to disambiguate the above examples. (For new syntax I'd like to reserve alongside in , though that would be off-topic and could also be a breaking change.)
apparently not
Change:
<ins> trait DynEq {} impl<'a> PartialEq for &'a (dyn DynEq + 'static) { fn eq(&self, _other: &Self) -> bool { true } } impl Eq for &dyn DynEq {} //~ ERROR E0308 fn main() { } </ins>

Discussion:
Causes the following error: This is somewhat confusing, especially since is not a type. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This looks similar to what I reported in
Here we don't account for anything other than type mismatches which means that later we use the generic prefix We need to account for in the first snippet and ferry the prefix strings from there to the later (instead of what we do now).
I'd like to work on this claim
do not hesitate to reach out if you need help!
Do we need to get the correct prefix strings from the contents of or are they just ?
I believe they can be just "trait".
Change:
) -> DllImport { let span = self.tcx.def_span(item); <ins> // this logic is similar to `Target::adjust_abi` (in rustc_target/src/spec/mod.rs) but errors on unsupported inputs </ins> let calling_convention = if self.tcx.sess.target.arch == "x86" { match abi { Abi::C { .. } | Abi::Cdecl { .. } => DllCallingConvention::C, <del> Abi::Stdcall { .. } | Abi::System { .. } => { DllCallingConvention::Stdcall(self.i686_arg_list_size(item)) </del> <ins> Abi::Stdcall { .. } => DllCallingConvention::Stdcall(self.i686_arg_list_size(item)), // On Windows, `extern "system"` behaves like msvc's `__stdcall`. // `__stdcall` only applies on x86 and on non-variadic functions: // https://learn.microsoft.com/en-us/cpp/cpp/stdcall?view=msvc-170 Abi::System { .. } => { let c_variadic = self.tcx.type_of(item).instantiate_identity().fn_sig(self.tcx).c_variadic(); if c_variadic { DllCallingConvention::C } else { DllCallingConvention::Stdcall(self.i686_arg_list_size(item)) } </ins> } Abi::Fastcall { .. } => { DllCallingConvention::Fastcall(self.i686_arg_list_size(item))

Discussion:
While testing variadic function support with I discovered that Rust requires such functions to use either "C" or "cdecl" ABIs but requires the "system" ABI on non-x86 Windows. My undertstanding from discussing with is that this is not an issue with itself but with Rust's insistence that such functions aren't allowed to use the "system" ABI. It's just that is very strict about calling convention so that's where the issue surfaced. On x64 I should be able to compile this but Rust says no: This example works if I change the ABI to "cdecl" but that's not meant to be a valid ABI on x64 and so when I try to compile this with it fails: The practical result is that it is impossible to link this function with on non-x86.
cc which originally variadics support to some other calling conventions (though not it seems) behind the feature gate .
A workaround is to use "C" on non-x86 as I implemented here:
Thoughts on permitting variadic parameters with the calling convention for non-x86 Windows? If gets merged then we'll be pushing folks to use so that they get the correct calling convention for Windows APIs on all architectures, but that breaks compatibility with variadic parameters.
This work-around is . Would be great if there was a way that it could be avoided. :)
There's a comment saying this can't work: I don't understand anything about these ABIs so I can't say how accurate this is. Also I see nothing here special-casing x86, so why does the issue specifically mention non-x86?
Happy to update as soon as there's a way to avoid it.
Can we make equal to when applied to a variadic function? It's supposed to be whatever ABI is correct for the system api and is the correct ABI for a variadic win32 function. According to the acts as when applied to a variadic function.
Went ahead and opened for this.
Change:
// output directory will be deleted by us (as cargo will purge the stamp // file during the first slot's run), and core is relatively fast to // build so works OK to fill this 'dummy' slot. <del> let krates = ["core", "core", "alloc", "std", "proc_macro", "test"]; </del> <ins> let krates = ["core", "alloc", "std", "proc_macro", "test"]; </ins> for krate in &krates { run_cargo_rustdoc_for(krate); }

Discussion:
I think it was working yesterday, but is giving a "Not Found" response for me. works fine, however.
Hm, I wonder if this is a similar bug to the one fixed due to link check failure during the bootstrap bump.
FYI, works fine—it seems to just be .
Yeah, almost certainly the bootstrap bump. cc (just a heads up, I plan to submit a patch soon, though haven't written it yet)
My guess without too much investigation is that the symlinkdirforce which intends to share the compiler-doc directory between rustdoc and rustc docs is ending up clobbered. I likely won't get around to a fix tonight but may be able to do so tomorrow, we'll see how much time I have.
I'm also happy to revert the change on beta, if you want, so there isn't a rush to fix things.
Yeah, I think we should do that - there's enough stuff broken in rustbuild that's not really of the too unusual kind (well, really just two cases, but they seem fairly typical). I'd rather we drop it from beta and either pursue resource-suffix as suggested by or at least tackle the bugs in rustbuild on a less urgent timescale before relanding. (Ideally we should figure out what people should do; rustbuild's approach to just building twice seems pretty... suboptimal; I imagine that the fix for this newly found bug will end up similar if I do it quickly).
OK, I have posted I'll push through the changes, though it may take at least a few days to get beta updated and then bump the version.
Yeah. I think I'm not sure there's as easy a fix in this case (unlike the simple add of a double core build), as the clobbering occurs over two different steps I believe. So I think we'll wait for that patch to land and bump beta. (We could also temporarily remove, say, rustdoc or rustc docs - but that doesn't seem like a real benefit).
Thanks for the speedy fix! The docs are back online now (because it's a bit after midnight UTC). I'm glad they're back :)
Change:
use crate::infer::combine::ConstEquateRelation; use crate::infer::{TypeVariableOrigin, TypeVariableOriginKind}; use crate::traits::Obligation; <ins> use rustc_middle::ty::error::{ExpectedFound, TypeError}; </ins> use rustc_middle::ty::relate::{Cause, Relate, RelateResult, TypeRelation}; use rustc_middle::ty::visit::TypeVisitable; use rustc_middle::ty::TyVar;

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. --This was in a closed source codebase I don't have time to minimize right now. It happened when I called (or something like that, don't exactly remember) on a value with type . Don't remember what T or E were :( <!-- 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
might be related to one of these ^^
Ugh, this is due to adding this  call -- something is calling this with a type that has region variables that no longer exist, probably from an or ... I can possibly try to reproduce, but this will be difficult to do without an MVCE.
can you try or is this a different issue?
This is a different issue. is a trait solver issue having to do with higher ranked type equality and the . This has to do with a region variable escaping out of a . Specifically it's this one:
Actually wait this is a type variable that's escaping. Ugh, probably due to opaque types :?
oh I forgot I saved this code I will try to trim it down to something I can post publicly
if you can, it would be incredibly useful here.
WG-prioritization assigning priority (). label -I-prioritize +P-medium