jiebi/CodeConvo huggingface dataset:
Change:
// immutability is so important. alloc.mutability = Mutability::Not; } <del> InternKind::Constant | InternKind::ConstProp => { </del> <ins> InternKind::Constant => { </ins> // If it's a constant, we should not have any "leftovers" as everything // is tracked by const-checking. // FIXME: downgrade this to a warning? It rejects some legitimate consts,

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. --code from ./src/test/ui/consts/constconstructor/const-construct- <!-- 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. --rustc @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Might be caused by That should have reduced the number of ICEs, not increased it, but who knows.^^

<!-- 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. --core reduced from <!-- 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. --: repo is @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This does not reproduce with though, so it's a very recent regression.
` produces the same error it seems.
Change:
where S: Storage, for<'a> SaveUser<'a>: StorageRequest<S>, <ins> for<'a> SaveUser<'a>: StorageRequestReturnType, </ins> { User { dep }.save().await; }

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. --code from <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: This crashes nightly, beta and stable <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Looks like this is happens during codegen which is why this didn't show up in the test (note the ´check-pass`) ...?
Hmm... this should be normalized somewhere above codegen I think? Curious to investigate though. claim
I suspect that this is caused by a bug in how we handle higher-ranked region variables (possibly during trait selection caching).
Change:
OpenOptions::new().write(true).create(true).truncate(true).open(path) } <del> /// Returns the original path that was used to open this file. </del> <ins> /// Returns `None`. </ins> #[unstable(feature = "file_path", <del> reason = "this abstraction is imposed by this library instead  of the underlying OS and may be removed")] </del> <ins> reason = "this abstraction was imposed by this library and was removed")] #[deprecated(since = "1.0.0", reason = "abstraction was removed")] </ins> pub fn path(&self) -> Option<&Path> { <del> self.path.as_ref().map(|p| &**p) </del> <ins> None </ins> } /// Attempt to sync all OS-internal metadata to disk.

Discussion:
takes a object as reference, although it only clones it afterwards. It's also impossible to re-use the allocation for the file path, because it's only dropped at the end.
It is pretty hard to not involve allocations because Rust-native strings will have to be converted into null terminated one to pass into the native API at some point anyway.
That's true.. Maybe we can avoid the double-allocation?
The path is cloned only so that it can later be used in error messages, which is a somewhat debatable use case. We could resolve this in the future by taking an bound (if we had a trait like that). cc
In that case it would probably be better to just take a PathBuf. But does it really justify an extra allocation just to provide error messages?
That would be a lot less ergonomic -- I want to be able to feed in a string literal with no extra steps. Probably not, hence why I said it was a "somewhat debatable use case." :)
What about a variable-length stack allocation?
allocating on stack comes with its own downsides. Also, it doesn’t guarantee a trailing null byte either, AFAIK?
If you had a stack allocation, you could just append a null byte.
As tbu- said. And the downsides of are nothing compared to linking in 195kB of jemalloc (the absolute minimum jemalloc size on OS X x86_64 with LTO).
Change:
{ let old_len = self.in_scope_lifetimes.len(); let lt_def_names = params.iter().filter_map(|param| match param.kind { <del> GenericParamKind::Lifetime { .. } => Some(param.ident.modern()), </del> <ins> GenericParamKind::Lifetime { .. } => Some(ParamName::Plain(param.ident.modern())), </ins> _ => None, }); self.in_scope_lifetimes.extend(lt_def_names);

Discussion:
The following breaks on nightly (see ) With: CC: dtolnay/async-trait
Reduced:
Forgot to mention in case this helps, giving the inner fn a matching lifetime avoids this issue for some reason:
The reason this is happening is that the desugared version of applies all in-scope lifetimes to the returned existential type, which in this case is creating , which is invalid. I'm not sure exactly what the best fix is for this, though, since elided lifetimes in the impl signature are intentionally unnameable. The closest idea I have would be to create some special new lifetime that is but can refer to lifetimes originating from the impl header. cc who may have opinions.
Hmm wouldn't you expect the nested to not inherit anything from its enclosing scopes? Seems like a bug to me that it does? Am I confused about something?
The function in the middle is actually a bit of a source of confusion here, although it does indicate that there's a second bug since we shouldn't be inheriting generics since the nested isn't part of the . The bug I was focusing on is better illustrated by this example: which produces this error: This is because the code is transformed into and in that case does not refer back to the usage from the header.
I see. Indeed, I would expect that, internally, we'd have some way to refer back to the from the impl header. I believe this should be possible, no? In particular, the in impls expands (internally) to for some integer N, which I believe is basically treated like any other named lifetime.
Yep, I would've expected so as well-- I'm not sure why that isn't working, I'd have to take a look.
I was looking and I think the bug lies here: Probably needs to be a instead, or we need to use something else for this purpose.
A closer reading suggests I was mistaken. The lifetimes from the impl should show up in -- includes only the explicitly declared lifetimes written by the user on the impl. I'm not quite sure what the problem is yet.
OK, no, I was correct. When processing impl items, we convert the lifetimes into entries. EDIT: Er, I'm still not entirely sure. Reading more. =)
OK, I have a fix for the method issue, but not the nested async fn item issue.

I forked off for the method issue
I didn't prep a fix for this one yet. It seems obvious that some internal state is not being reset when we enter a new item.
but if you have a chance to investigate, would be appreciated
Presumably the problem is that doesn't "reset" the vector -- it only seems to extend it...
Indeed, in-band lifetimes are broken in the same way. This fails to compile ():
Working on a possible fix
Yep, have a fix.
Inband lifetimes looks similar to fwiw
thanks
Change:
<ins> error[E0308]: mismatched types --> $DIR/issue-78262.rs:12:28 | LL |     let f = |x: &dyn TT| x.func(); |                            ^^^^ lifetime mismatch | = note: expected reference `&(dyn TT + 'static)` found reference `&dyn TT` note: the anonymous lifetime #1 defined on the body at 12:13... --> $DIR/issue-78262.rs:12:13 | LL |     let f = |x: &dyn TT| x.func(); |             ^^^^^^^^^^^^^^^^^^^^^ = note: ...does not necessarily outlive the static lifetime error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </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. --: This bug also exists at . <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Output on 1.46: Changing the closure argument type to compiles successfully on both verions. modify labels: +A-diagnostics +A-lifetimes +regression-from-stable-to-stable
With instead of it compiles successfully too. <details<summaryCode</summary</details
We probably have to check for closures in here.
Assigning as and removing I-prioritize.
Change:
pub mod back { pub mod archive; pub mod link; <ins> pub mod manifest; </ins> pub mod abi; pub mod upcall; pub mod arm;

Discussion:
Windows executables should contain embedded application manifests [1]. This is especially important for 32-bit executables, because in the absence of a manifest they are subject to UAC installer detection heuristics [2], which may cause unexpected UAC prompts or even complete failure to execute (in unattended contexts) depending on presence of certain keywords in executable's file name.
You beat me by a few hours :) Here is the description I had in : The UAC issue in is caused by a missing in the binaries. We should include the following in all binaries: In an ideal world, we would allow the user to provide a custom manifest should they wish to require UAC elevation, for example. As another example, a user might want to provide entries in order to fully support Windows 8.1 (where the / functions unless is present in the manifest). The VC++ linker has the option for the UAC part. In a traditional MinGW build, this would be implemented something like this: Where would contain something like this (application.manifest would contain the XML stuff above):
I wonder if it would be easier to skip windres altogether and write resource directly into linked executable using .
I use to add manifest but I always felt this is a hack.
As of MSVC 2008, passing to should add the necessary manifest bits for UAC.
In case anyone finds this issue, you can use in a script to solve this:
Hello. It is over 1 year later now since this comment was posted. Is this nasty work around still necessary? Or does the Rust Compiler finally supports embedding Windows Manifest Files and Resources etc. (in anyway whatsoever)? Thanks!
Change:
<ins> // This is a regression test for issue https://github.com/rust-lang/rust/issues/106629. // It ensures that transparent types where all fields are PhantomData are marked as // FFI-safe. // check-pass #[repr(transparent)] #[derive(Copy, Clone)] struct MyPhantom(core::marker::PhantomData<u8>); #[repr(C)] #[derive(Copy, Clone)] pub struct Bar { pub x: i32, _marker: MyPhantom, } extern "C" { pub fn foo(bar: *mut Bar); } fn main() {} </ins>

Discussion:
If I have a wrapper around a , it's considered an improper C type when used in a struct field, even though the wrapped would be allowed. Specifically () produces the error This is over-zealous for a few reasons. on its own is allowed in C structs, so changing this to would solve the warning (but defeats the point of my use case[^1]). is supposed to be treated as the inner type for purposes of ABI, and the lint is about ABI. instead of solves this technically (it shuts the warning up), but seems pretty dodgy, since it's not actually laid out the way C would lay it out anymore (that is, we've guaranteed that is never going to impact layout at all, and we haven't guaranteed this for zero-sized types which are notably not a real thing in C). TLDR: this lint fires on wrappers around when they're used as struct fields. IMO these should be fine since doesn't emit a warning in that case, and is supposed to defer to the inner type. . It's important that the type not be a direct (basically is not really usable for FFI, but C has cases where considers appending new fields to the end of a type to be a non-breaking change). (That said, firing this lint on a type passed by pointer is pretty weird anyway, since the indirection means doesn't actually have to be a valid C type (for the ABI), which is the basic complaint behind , which is not what I'm complaining about. IMO this shouldn't fire even if were being passed by value, as making the field (instead of a wrapper around one) doesn't fire in that case) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I'd like to take a look at this. claim
Related:
Change:
// This isn't an "LLVM intrinsic", but LLVM's optimization passes // recognize it like one and we assume it exists in `core::slice::cmp` <del> ifn!("memcmp", fn(i8p, i8p, t_isize) -> t_i32); </del> <ins> match self.sess().target.arch.as_str() { "avr" | "msp430" => ifn!("memcmp", fn(i8p, i8p, t_isize) -> t_i16), _ => ifn!("memcmp", fn(i8p, i8p, t_isize) -> t_i32), } </ins> // variadic intrinsics ifn!("llvm.va_start", fn(i8p) -> void);

Discussion:
uses , and declares it to return i32, in reality it returns c_int, so this is a potential portability concern. Maybe memcmp can be made an intrinsic to resolve this.
It also takes a parameter, not a .
Neither of these are a practical issue (yet). crate libc does not support any other configuration than so far.
cc
The extern function is now in
What should we do next? Should we try to create a intrinsic?
Hi, I believe this issue is causing array comparisons on the AVR architecture to break (see the linked issue, ). Is there any consensus on a path forward here?
Change:
This feature is unstable, so you can enable it by calling Rustdoc with the unstable `rustdoc-scrape-examples` flag: ```bash <del> cargo doc -Zunstable-options -Zrustdoc-scrape-examples=examples </del> <ins> cargo doc -Zunstable-options -Zrustdoc-scrape-examples </ins> ``` To enable this feature on [docs.rs](https://docs.rs), add this to your Cargo.toml: ```toml [package.metadata.docs.rs] <del> cargo-args = ["-Zunstable-options", "-Zrustdoc-scrape-examples=examples"] </del> <ins> cargo-args = ["-Zunstable-options", "-Zrustdoc-scrape-examples"] </ins> ```

Discussion:
Tello-edu The says use my build failed with error <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc could you provide some input here? Thanks!
The rustdoc book documents rustdoc flags. You are passing this flag to cargo. I don't remember how to configure cargo for this argument off the top of my head, but you should look in the cargo book for how.
Oh wait, apparently the rustdoc book directly documents using this with it's probably just outdated then - I'll transfer this to rust-lang/rust.
Btw it works fine after taking out the "=examples"
claim
Change:
<del> struct Wrapper<'rom>(T); //~^ ERROR cannot find type `T` in this scope </del> <ins> struct Wrapper<'rom>(&'rom ()); </ins> trait Foo { fn bar() -> Wrapper<impl Sized>;

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'expect 0 RPITITs in call to '', 'thread 'rustc' panicked at 'expect 0 RPITITs in call to '' File: --auto-reduced (treereduce-rust): original: 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: [collectreturnpositionimpltraitintraittys] comparing an impl and trait method signature, inferring any hidden types in the process [typeof] computing type of [checkwellformed] checking that is well-formed [checkmodtype_wf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
Okay, lol, here the types obviously do unify and therefore isn't effective in this situation.
More fundamentally, the thing that goes “wrong” in these kinds of situations is the fact that we call if we have which is the case because generated one because the HIR (!) type visitor inside found an opaque type in the HIR type (here ) while the lowered type (here ) no longer contains any opaque types ultimately leading to the assert triggering. In short: visit the HIR ty , see an opaque type and take note of that synthesize an assoc ty for the RPITIT (I think) because of (1) lower the ty to due to the argument kind mismatch try to collect RPITITs on the lowered type & fail to find the opaque type I don't know if this is actually useful in general :thinking: What kinds of bugs is it supposed to catch?
cc
So either we delay the detection of RPITITs and the synthesis of RPITIT assoc tys until after HIR ty lowering / AstConv (but I don't know if that's an option) or we modify the assert (either remove it outright or check the corresp. HIR ty, I don't know if that makes sense; furthermore oli is/was on a roll to remove HIR operations from this part of the code base iirc).

Yeah, this assertion was simply there to make sure we weren't incorrectly calling for methods that had no RPITITs themselves (b/c it's expensive, and it actually is a bit stronger in what it enforces in the method signatures since it uses rather than in the signature relation for lifetime reasons), but now that this code isn't being changed much, I doubt that will ever happen. Feel free to remove it, or else I can do.
We could also delay a bug on mismatch
Change:
.map(|v| v.get(tcx)) } <ins> /// Determines whether can we safely cache the result /// of selecting an obligation. This is almost always 'true', /// except when dealing with certain ParamCandidates. /// /// Ordinarily, a ParamCandidate will contain no inference variables, /// since it was usually produced directly from a DefId. However, /// certain cases (currently only librustdoc's blanket impl finder), /// a ParamEnv may be explicitly constructed with inference types. /// When this is the case, we do *not* want to cache the resulting selection /// candidate. This is due to the fact that it might not always be possible /// to equate the obligation's trait ref and the candidate's trait ref, /// if more constraints end up getting added to an inference variable. /// /// Because of this, we always want to re-run the full selection /// process for our obligation the next time we see it, since /// we might end up picking a different SelectionCandidate (or none at all) fn can_cache_candidate(&self, result: &SelectionResult<'tcx, SelectionCandidate<'tcx>> ) -> bool { match result { Ok(Some(SelectionCandidate::ParamCandidate(trait_ref))) => { !trait_ref.skip_binder().input_types().any(|t| t.walk().any(|t_| t_.is_ty_infer())) }, _ => true } } </ins> fn insert_candidate_cache( &mut self, param_env: ty::ParamEnv<'tcx>,

Discussion:
When using the nightly with the bugfix for the problems with , this error happens when trying to document the crate: note: rustc 1.31.0-nightly ( 2018-10-01) running on x86_64-apple-darwin
cc: FYI
it seemed to document fine for me on the most recent nightly build
This is fixed as of
Closing then! Thanks! :D
Will this need backporting at all?
Change:
fn test11(x: &usize) -> &_ { //~^ ERROR the placeholder `_` is not allowed within types on item signatures for return types <del> &x //~ ERROR cannot return reference to function parameter </del> <ins> &x </ins> } unsafe fn test12(x: *const usize) -> *const *const _ {

Discussion:
The code Emits this diagnostic, which is wrong in this case. It should say cc: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Cannot reproduce: the code snippet as given produces on stable 1.78.0
Did you mean to write this code snippet instead?
Ooops yes :sweat_smile:, edited
claim
Change:
// Prepare the lldb_batchmode which executes the debugger script let lldb_script_path = rust_src_root.join("src/etc/lldb_batchmode.py"); self.cmd2procres( <del> Command::new(&self.config.lldb_python) </del> <ins> Command::new(&self.config.python) </ins> .arg(&lldb_script_path) .arg(test_executable) .arg(debugger_script)

Discussion:
Compiletest currently has two different arguments telling it which python to use. Since , both are always the same. We should change it to just one argument to simplify things. Mentoring instructions: Change to be a single argument, then change to use the updated arguments. are you interested in tackling this one too? :) label +A-rustbuild +A-testsuite +E-easy +E-mentor Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Change:
changed: true }; <ins> let nodes_po = cfg.graph.nodes_in_postorder(OUTGOING, cfg.entry); </ins> let mut temp = vec![0; words_per_id]; <ins> let mut num_passes = 0; </ins> while propcx.changed { <ins> num_passes += 1; </ins> propcx.changed = false; propcx.reset(&mut temp); <del> propcx.walk_cfg(cfg, &mut temp); </del> <ins> propcx.walk_cfg(cfg, &nodes_po, &mut temp); </ins> } <ins> debug!("finished in {} iterations", num_passes); </ins> } debug!("Dataflow result for {}:", self.analysis_name);

Discussion:
See . Here is a chart giving time output from with of the lines of the form uncommented. n -------- With this gist I've tried to create a fairly minimal example. It's not as minimal as maybe it could be because it's a little tricky to figure out what's causing the slow compiles and I've spent as much time as I can on this right now. It's very sensitive to seemingly irrelevant changes in the code. If I remove the unused variable, compile times dramatically improve. If I remove the empty loop, compile times dramatically improve. On my actual project, I am getting compile times in excess of 20 minutes. To compile a few thousand lines of code.
cc
Umm this is not an expansion problem but rather a borrowck problem - dataflow somehow takes O(n) iterations to converge.
Change:
use crate::infer::InferCtxt; use crate::traits::normalize_projection_type; <ins> use rustc_data_structures::stack::ensure_sufficient_stack; </ins> use rustc_errors::{error_code, struct_span_err, Applicability, DiagnosticBuilder, Style}; use rustc_hir as hir; use rustc_hir::def::DefKind;

Discussion:
I would expect to error with "overflow evaluating the requirement", or compile without issue. Instead it segfaults. () Errors:
This segfault occurs since 1.45.0, 1.44.1 emits the expected error. It'd be great if we could bisect if possible.
18 out of backtrace frames: <details<summaryDetails</summary</detailsProbably not very useful.
I believe that we still have the bors artifacts, so it should be possible to use . ping cleanup
Error: Only Rust team members can ping teams. Please let know if you're having trouble with this bot.
ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
searched nightlies: from nightly-2020-05-07 to nightly-2020-05-08 regressed nightly: nightly-2020-05-08 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
It's likely related -- cc
Does fix this issue?
Hm, I don't think so, let me confirm it. -- Confirmed with the master toolchain, it doesn't fix this.
I believe we need to wrap and the similar invocations further down with