jiebi/CodeConvo huggingface dataset:
Change:
<ins> //@ edition: 2021 #![feature(async_closure)] struct DropMe; trait Impossible {} fn trait_error<T: Impossible>() {} pub fn main() { let b = DropMe; let async_closure = async move || { // Type error here taints the environment. This causes us to fallback all // variables to `Error`. This means that when we compute the upvars for the // *outer* coroutine-closure, we don't actually see any upvars since `MemCategorization` // and `ExprUseVisitor`` will bail early when it sees error. This means // that our underlying assumption that the parent and child captures are // compatible ends up being broken, previously leading to an ICE. trait_error::<()>(); //~^ ERROR the trait bound `(): Impossible` is not satisfied let _b = b; }; } </ins>

Discussion:
<!-- [31mICE[0m: Rustc '--edition=2018 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'we captured CapturedPlace {'', 'thread 'rustc' panicked at 'we captured CapturedPlace {'' File: --snippet: Version 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 --
probably also caused by ?
yep ill put up a fix in a few
Change:
<ins> // Checks whether shadowing a const parameter leads to an ICE (#85348). impl<const N: usize> ArrayWindowsExample { //~^ ERROR: cannot find type `ArrayWindowsExample` in this scope [E0412] fn next() { let mut N; //~^ ERROR: let bindings cannot shadow const parameters [E0530] //~| ERROR: type annotations needed [E0282] } } 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
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Change:
<ins> error[E0271]: type mismatch resolving `<dyn Pointee<Metadata = ()> as Pointee>::Metadata == ()` --> $DIR/ice-with-dyn-pointee-errors.rs:9:33 | LL |     unknown_sized_object_ptr_in(x) |     --------------------------- ^ expected `()`, found `DynMetadata<dyn Pointee<Metadata = ...>>` |     | |     required by a bound introduced by this call | = note: expected unit type `()` found struct `DynMetadata<dyn Pointee<Metadata = ()>>` note: required by a bound in `unknown_sized_object_ptr_in` --> $DIR/ice-with-dyn-pointee-errors.rs:6:50 | LL | fn unknown_sized_object_ptr_in(_: &(impl Pointee<Metadata = ()> + ?Sized)) {} |                                                  ^^^^^^^^^^^^^ required by this bound in `unknown_sized_object_ptr_in` error: aborting due to previous error For more information about this error, try `rustc --explain E0271`. </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. -- Needs to reproduce, is not enough. <!-- 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
related: This shouldn't compile, but it does:
This is definitely fixed by , I'll add some tests and link this one.
whoops, forgot to add tests. marking as E-needs-test
I wouldn't mind giving this one a try if I'm understanding it correctly. Just add tests for the changes made in , should the original code at the top of this issue compile now and the code in the next comment, shouldn't compile?
correct. Please put some care into which subdirectory in these tests are placed, and make sure they're given at least somewhat descriptive names (i.e. not or anything like that).
Change:
} #[cfg(test)] <del> mod tests { </del> <ins> mod test { </ins> use super::*; use test::Bencher;

Discussion:
The code example at should be corrected changing into .
nice catch!
Should this instance be , or should everything else be instead? Judging from , it looks like is more common. Granted, half of it is alexcrichton, but still ;-) Incoming PR to that effect.
Oh, really now?
I actually vote for everything else to be .
Aw, shoot. From some more grepping, the style guide and the language reference both refer to . Going with that.
Ok but... to me it doesn't make sense that we use and then we name the folder , as they both can contain multiple tests...
/me considers giving Steve a choose-your-own-adventure pair of pull requests.
Change:
demand::coerce(fcx, e.span, t_1, &e); } } <del> } else if fcx.type_is_fat_ptr(t_e, span) && !fcx.type_is_fat_ptr(t_1, span) { </del> <ins> } else if fcx.type_is_fat_ptr(t_e, span) != fcx.type_is_fat_ptr(t_1, span) { </ins> fcx.type_error_message(span, |actual| { <del> format!("illegal cast; cast from fat pointer: `{}` as `{}`", </del> <ins> format!("illegal cast; cast to or from fat pointer: `{}` as `{}`  involving incompatible type.", </ins> actual, fcx.infcx().ty_to_string(t_1)) }, t_e, None); } else if !(t_e_is_scalar && t_1_is_trivial) {

Discussion:
This is done when compiling repository. Use on either the entire handmadehero crate, or handmadelibsdl. Warning: Ugly, code ahead! Cleaned up repo: It does need to be across crate lines, and needs to be returned in a result, afaict.
The issue is that I should not be able to write because is a [T]. Same with .
Actually, to that end, why is bigger than a anything? Why is a a fat pointer at all?
Very similar to , , .
Yes it is, pretty much the same. A should not be differently sized from a , at least IMHO, so why is it?
is a with fewer guarantees; one can convert between them freely (if you ensure the guarantees are maintained for -). In particular, this means is a fat pointer to match .
That is weird...
NVM, I now understand why it is a fat pointer. However, this should be an easy fix, right? Why is a mut [T] seen as the same size as a mut T in rustc? Well, now it isn't, so is fixed, but it still panics at .
Change:
<del> Subproject commit fd0428f622feee209e6014b802f5717d48d9e978 </del> <ins> Subproject commit 3e74853d1f9893cf2a47f28b658711d8f9f97b6b </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
Change:
}).collect() } <del> fn dump_constraints(&self) { debug!("----() Start constraint listing ()----"); </del> <ins> fn dump_constraints(&self, subject: ast::NodeId) { debug!("----() Start constraint listing (subject={}) ()----", subject); </ins> for (idx, (constraint, _)) in self.constraints.borrow().iter().enumerate() { debug!("Constraint {} => {}", idx, constraint.repr(self.tcx)); } } <ins> fn expand_givens(&self, graph: &RegionGraph) { // Givens are a kind of horrible hack to account for // constraints like 'c <= '0 that are known to hold due to // closure signatures (see the comment above on the `givens` // field). They should go away. But until they do, the role // of this fn is to account for the transitive nature: // //     Given 'c <= '0 //     and   '0 <= '1 //     then  'c <= '1 let mut givens = self.givens.borrow_mut(); let seeds: Vec<_> = givens.iter().cloned().collect(); for (fr, vid) in seeds { let seed_index = NodeIndex(vid.index as usize); for succ_index in graph.depth_traverse(seed_index) { let succ_index = succ_index.0 as u32; if succ_index < self.num_vars() { let succ_vid = RegionVid { index: succ_index }; givens.insert((fr, succ_vid)); } } } } </ins> fn expansion(&self, free_regions: &FreeRegionMap, var_data: &mut [VarData]) { self.iterate_until_fixed_point("Expansion", |constraint| { debug!("expansion: constraint={} origin={}",

Discussion:
Notably, this does not occur with a trait like: This smells like a bug to me, unless a language change introduced special treatment of with regard to lifetimes.
An interesting quirk is that if you replace with just , it compiles fine with the impl.
cc
are you saying this used to work? Just curious what the original was.
(Also it seems difficult if not impossible to satisfy the combination of and ..... well I guess of static would, but I don't know if we can deduce that.
Yes, this used to work. This bug is affecting
It looks like this may have been introduced in . Prior to this, checking for bounds in was done via , which creates a throw-away inference context before calling into trait selection. It now goes through the ; the impl of for uses its own inference context. This causes region constraints introduced during trait selection for to stick around, resulting in a seemingly inappropriate transitive constraint between the free region within the closure body and at the call site of .
hmm good catch, sorry I let this slip through last week :( I'll try to pay it some attention now. The current code does not seem entirely wrong to me, though. I have to think this through a bit.
Change:
use rustc_driver::abort_on_err; use rustc_resolve as resolve; <ins> use syntax::ast::CRATE_NODE_ID; </ins> use syntax::source_map; use syntax::attr; use syntax::feature_gate::UnstableFeatures; use syntax::json::JsonEmitter; use syntax::symbol::sym; <ins> use syntax_pos::DUMMY_SP; </ins> use errors; use errors::emitter::{Emitter, EmitterWriter};

Discussion:
/cc
So the explosion is that somehow the crate index in the is broken, or at least not entirely right. Interestingly if you add to the then it no longer ICEs (but has the same ) Edit: So this looks like it's somehow a bug when trying to resolve it as a global name (both and prevent the iCE)
Maybe it's linked to ? If so, it's not in rustdoc but below.
I believe I've worked out approximately what's going on: Rustdoc freezes the compiler state (resolver, etc) as part of the setup to ready the instance. Since was made optional, and crate names are automatically part of the global scope, people stopped necessarily telling the compiler about the crates in their code. If a comment references a path in this manner, but the code itself doesn't, then the resolver frozen into the doesn't have that crate's metadata loaded into it. When we then ask the resolver to resolve a new path (e.g. ) it goes ahead and loads the crate into a different instance of the than will be used when we then try and use the later. It feels like the moment a is d it should also be locked so that it can never be modified again. It's also possible that rustdoc could be forced to enter the right context so that we never do this wrongly, but that's beyond me right now. Given that, , I feel this is probably either a bug in how is handling the resolver, or else a change in how the resolver behaves which either needs fixing, or changing in to cope.
My gut feeling is that we probably need to stop capturing/cloning the resolver as we do here: and instead try and find a resolver as part of the closure here: Of course, it looks like a has an immutable copy of the resolver's outputs, and no access to the resolver itself, urgh, and we have no easy way to inject changes into the context at this point.
I wonder why that type can be cloned in the first place...

I found an ICE when trying to document the [spirit-log][1] crate on the latest . Skimming through the backtrace, it looks like accessed an invalid index while traversing links within . Steps to reproduce: [1]:
Taking a look.
Actually, it's failing outside of rustdoc so I prefer to let someone else handle it. cc
I think this might be a bug (or at least mismatch between how uses the resolver infrastructure and how it's meant to work). See my comment here:
Change:
... LL |     } |     - `client` is later dropped here <del> help: consider moving this method call into a `let` binding to create a shorter lived borrow </del> <ins> help: consider moving this into a `let` binding to create a shorter lived borrow </ins> --> $DIR/issue-64130-4-async-move.rs:19:15 | LL |         match client.status() {

Discussion:
The following code was working in nightly-2019-09-05, but no longer works in nightly-2019-10-15. The workaround is not quite intuitive. () Errors: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'm also running into this error using Tide and a DB Pool from Diesel I've managed to get a slightly simpler/different version of the above code - I'd expect this to work because I'd expect the to be finished before the starts (I guess it's similar to how pre-NLL we'd expect function calls in arguments to work but sometimes they wouldn't because existing borrows?) I've managed to track it down to happening somewhere between these - but I'm not sure how to go about figuring this out any further (I've never built the compiler, let alone actually debugged it) This successfully buildsThis fails
This was an intentional change to match the drop order in synchronous code:
This was an intentional change but these errors also look like they are caused by "overapproximation" of the set of captured values. We are working to improve that; separately, we are also working on improving the diagnostics here.
Assigning to myself as this is a case I'd hope to tackle in . It isn't currently handled by that PR, as the current diagnostic improvements only work when the error originates from an , not . claim
I found a similar problem: Is this the same bug?
Unassigning myself since has landed.
adds a compiler message to suggest a workaround for this problem. Is it not possible to make the compiler smarter and not borrow unnecessary variables across ?
rustc is not that smarter yet, we already have an issue tracking this , along with were trying to lint users with "shorten" workaround(might be lifted once the analysis is improved) in these two "common" cases.
It's a matter of having consistent language semantics for async and non-async code. The lang team discussed this and decided the drop order should be consistent (i.e. we shouldn't drop temporaries until the end of the statement, even if the statement contains ).
Change:
} } Err(coercion_error) => { <ins> // Mark that we've failed to coerce the types here to suppress // any superfluous errors we might encounter while trying to // emit or provide suggestions on how to fix the initial error. fcx.set_tainted_by_errors(); </ins> let (expected, found) = if label_expression_as_expected { // In the case where this is a "forced unit", like // `break`, we want to call the `()` "expected"

Discussion:
: and then if I increase the recursion limit enough... adding a backtrace gives nothing new, however, compiling on nightly gives the following: </p</detailsI strongly suspect this is related to , but that issue is now old and should have been solved. Perhaps a regression?
can you provide the you compiled that code snippet with? The provided code doesn't seem complete.
I can reproduce it with in the section of a , but this is not an ICE.
Change:
if sess.opts.debug_assertions { ret.insert((sym::debug_assertions, None)); } <ins> if sess.overflow_checks() { ret.insert((sym::overflow_checks, None)); } </ins> // JUSTIFICATION: before wrapper fn is available #[allow(rustc::bad_opt_access)] if sess.opts.crate_types.contains(&CrateType::ProcMacro) {

Discussion:
An enhancement request discussed here: (That thread also contains a hacky solution by Yandros). I propose to add a config like this: #[cfg(overflow_checks)] I would like to use it to enable/disable lines of code that perform safe unsafe "as" casts replacing them with casts when I compile with debug builds or with release builds compiled with "-C overflow-checks".
modify labels: C-enhancement
label A-attributes T-compiler
I’d also be interested in this.
Tracking issue:
Change:
# Create a directory # $(1) is the directory <ins> # # XXX: These defines are called to generate make steps. # Adding blank lines means two steps from different defines will not end up on # the same line. </ins> define PREPARE_DIR <del> @$(Q)$(call E, prepare: $(1)) </del> <ins> @$(call E, prepare: $(1)) </ins> $(Q)$(PREPARE_DIR_CMD) $(1) endef # Copy an executable # $(1) is the filename/libname-glob # <del> # Gee, what's up with that $(nop)? See comment below. </del> <ins> # See above for an explanation on the surrounding blank lines </ins> define PREPARE_BIN <del> $(nop) </del> @$(call E, prepare: $(PREPARE_DEST_BIN_DIR)/$(1)) $(Q)$(PREPARE_BIN_CMD) $(PREPARE_SOURCE_BIN_DIR)/$(1) $(PREPARE_DEST_BIN_DIR)/$(1) endef # Copy a dylib or rlib # $(1) is the filename/libname-glob # <del> # XXX: Don't remove the $(nop) command below! # Yeah, that's right, it's voodoo. Something in the way this macro is being expanded # causes it to parse incorrectly. Throwing in that empty command seems to fix the # problem. I'm sorry, just don't remove the $(nop), alright? </del> <ins> # See above for an explanation on the surrounding blank lines </ins> define PREPARE_LIB <del> $(nop) </del> @$(call E, prepare: $(PREPARE_WORKING_DEST_LIB_DIR)/$(1)) $(Q)LIB_NAME="$(notdir $(lastword $(wildcard $(PREPARE_WORKING_SOURCE_LIB_DIR)/$(1))))";  MATCHES="$(filter-out %$(notdir $(lastword $(wildcard $(PREPARE_WORKING_SOURCE_LIB_DIR)/$(1)))), 

Discussion:
Also .
Like any good bug, turning on debugging changes behaviour (VERBOSE=1). It creates a directory called ' From make output:
Found the problem, making PR.
Change:
<ins> // Copyright 2013 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. struct Node<'self, T> { val: T, next: Option<&'self Node<'self, T>> } impl<'self, T> Node<'self, T> { fn get(&self) -> &'self T { match self.next { Some(ref next) => next.get(), None => &self.val } } } fn main() {} </ins>

Discussion:
I wonder if this shouldn't work? The failure is: expects a but is a . 's id is the same as ('s id). CC'ing because he's the borrowed pointer specialist.
I think this never should have worked, since the struct is declared to contain a managed box. The error message isn't the clearest, but is saying the compiler doesn't know that the lifetime of the contents of a node's field is the same as the lifetime of the contents of the node itself. I'll check in a modified run-pass test case (where the field contains a pointer with a lifetime annotation).
Pending
Doesn't look critical for 0.6
Yeah, this is working-as-intended. The associated test (which landed) shows how this needs to be written if you want to use borrowed pointers here. Closing.
Change:
core::ptr::read_volatile(&42); } } <ins> // CHECK: define void @i() #[no_mangle] #[inline] fn i() {} // CHECK: define void @j() #[no_mangle] #[inline] pub fn j() {} // CHECK: define void @k() #[no_mangle] #[inline(always)] fn k() {} // CHECK: define void @l() #[no_mangle] #[inline(always)] pub fn l() {} </ins>

Discussion:
Code: If the function is marked as , it doesn't get compiled into the dll file: The reason a function may be marked as both and is so that it gets inlined when compiling the crate as a rust library, but not inlined when compiling the crate as a cdylib. There should be a warning to use something like instead. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Related to - I think is that we should include 'd functions in s and s, but as a short term solution, a warning is a nice idea
claim

I currently use Rust to generate a static library for FFI consumption. In some public interfaces, I call other FFI public interfaces as primarily a wrapper with a few tweaks. I'd like to mark these "inner" functions as inline, however, this seems to cause them to not show up in the final staticlib. Given this drastically simplified example: The function makes it to the static library, but the function does not: If I remove the attribute, we see both functions in the static lib: The don't seem to hint that can prevent / items from surviving all the way to the final library, or that they shouldn't be used together. I would expect any function marked and/or should be present in the final artifact, regardless of attributes. I see this behavior on stable, as well as a recent nightly. I don't know if this is a regression, as this is the first time I've run into this. Thanks! Edit: Simplified profile settings, they are not needed to reproduce. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Tried with = same result
I’ve noticed this for a while but I always assumed it was intended... It would be really nice if this was fixed
This appears to have been done deliberately: Maybe it shouldn't apply to s.
Expanding on note, I would also expect this not to apply to s as well (I used the staticlib for my example, but my use case generates code for both static and dynamic library usage).
I think I'm going to take this on claim
Change:
<ins> use std::io::Read; fn f<T: Read, U, Read>() {} //~ ERROR expected trait, found type parameter `Read` fn main() {} </ins>

Discussion:
(A better title would be appreciated) I like this part: It could have a suggestion like , especially because are very close to each other on a US keyboard and could very well be a typo. Applying the suggestion will result in a compile error. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think the label might be fitting as well.
Error: Parsing assign command in failed: ...' claim' ' +D-invali'... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.