jiebi/CodeConvo huggingface dataset:
Change:
<ins> // Copyright 2014 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. // Test that the `Fn` traits require `()` form without a feature gate. fn bar1(x: &Fn<(),()>) { //~^ ERROR angle-bracket notation is not stable when used with the `Fn` family } fn bar2<T>(x: &T) where T: Fn<(),()> { //~^ ERROR angle-bracket notation is not stable when used with the `Fn` family } fn main() { } </ins>

Discussion:
We do not expect to completely "unfeature-gate" unboxed closures for 1.0. We wish to reserve the flexibility to change a few aspects: to variadic generics in place of auto-tupling. the and arguments from input types to (possibly) associated types. (cc ) the coherence story with respect to fn-trait hierarchy. (cc ) To this end we will adjust the features to: [ ] Disallow references to the traits using angle bracket notation [x] Disallow user impls of the traits [x] Disallow direct calls to [x] Disallow parenthetical notation () from being used with anything other than the traits In short, we permit unboxed closures to be used as if they are a language builtin, but disallow (for now) a lot of the more generic uses. We should be able to drop this feature gate shortly after 1.0. cc
Nominating for 1.0 or something. :)
P-backcompat-lang, 1.0.
Note that some of this works today though it ought not, e.g. manually implementing traits.
To expand on comment, the following code fails to compile due to the lack of a feature that should be gated: The current solution is to put on the function.
This was done, or done enough.
Oops, I totally overlooked that is still considered legal. It's important to adjust that too!
Change:
} ty::FnPtr(sig) => (sig, None), _ => { <ins> for arg in arg_exprs { self.check_expr(arg); } </ins> if let hir::ExprKind::Path(hir::QPath::Resolved(_, path)) = &callee_expr.kind && let [segment] = path.segments && let Some(mut diag) = self

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
Regression in /
Perhaps ? :thinking: cc
list of files that reproduce the crash ( is eough) `
I think we should change to a

Found with a From : From : Deep recursion involving ? Regression in nightly-2022-10-07, apparently in rollup . I suspect (
Change:
use rustc::middle::region::CodeExtent; use rustc::hir::pat_util; use rustc::ty::{self, VariantDef, Ty}; <ins> use rustc::ty::cast::CastKind as TyCastKind; </ins> use rustc::mir::repr::*; use rustc::hir; use syntax::ptr::P;

Discussion:
Compiling the crate with on ARM Linux: or : This was my first contact with mir and it wasn't peaceful :) Maybe I should have tried a , erm instead...
More ICEy stuff: coming from crate.
Minimal reproduction: It's the that is the problem. What happens is that we first reify to a function pointer, then try to cast the function pointer itself. It seems that we don't expect an cast in the MIR. I'm pretty sure that is only valid when it's a no-op, so we can probably just handle it MIR translation. that seem correct?
I some code to not build noop casts, the lifetimes may be different here though?
possibly, doing first and using in the cast works, so I'd say that lifetimes are the most likely source of difference between the two types in the cast. Do we have a lifetime-ignoring comparison we could use in this case?
Problem is, you can't ignore lifetimes, what if this is a to cast? There might be another way to tell that a cast only triggered a coercion, at the HAIR level. EDIT: Well, actually, the good old is a reification coercion + ptr-to-int cast.
do you mind giving a backtrace for that second error and opening a new issue for it (since it's unrelated to the two in the main post). If you could reduce it to a smaller reproduction, that would be even better.
There were no backtraces, unfortunately. Let's clarify one thing though - is turning off for a single crate and then resuming the mir'ed build, ok? That's how I arrived at the latter issue. (edit: wasn't the problem)
Actually MIR compilation has been bootstrappable for the compiler for a while now, so trying to use it for more complex codebases is really valuable, since it finds bugs like this.
The compiler doesn't generate a backtrace even if you set ?
That was the case indeed. (both ended in a segfault) -original message- Subject: Re: From: Eduard-Mihai Burtescu Date: 01.05.2016 12:22 The compiler doesn't generate a backtrace even if you set ? You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub:
Yeah, that's why I tried it - that whole sentence was a big pun on the word mir. (meaning both peace and world)
Change:
<ins> #![feature(ptr_mask)] #![feature(strict_provenance)] fn main() { let v: u32 = 0xABCDABCD; let ptr: *const u32 = &v; // u32 is 4 aligned, // so the lower `log2(4) = 2` bits of the address are always 0 assert_eq!(ptr.addr() & 0b11, 0); let tagged_ptr = ptr.map_addr(|a| a | 0b11); let tag = tagged_ptr.addr() & 0b11; let masked_ptr = tagged_ptr.mask(!0b11); assert_eq!(tag, 0b11); assert_eq!(unsafe { *masked_ptr }, 0xABCDABCD); } </ins>

Discussion:
Specifically, this manifested with indexing into a dvec. Not all of the code that was manipulating s was handling the case. Already fixed it, about to check in a fix. Thanks to for the test case.

It's currently ignored on Windows.
The code in question looks like: When I commented-out the ignore and a then this test passed on my Windows machine (Mingw32 + 64 bit Windows 7). So perhaps this particular issue is no more?
Fixed in

A comment suggests the type should be something richer, perhaps, than just .
Blocked on or something similar
Definitely not backwards incompatible for 1.0 if this depends on Rust 2.0 features. Renominating.
Nominating for "far-future" (does that require nomination?)
FIXME is gone, bug is too vague, closing

as per a FIXME.
Ok, so, the strings "globalenv" and "getglobalenvchan" don't appear in the source anymore, so I'm going to close this bug...
Change:
let block_and = match expr.kind { ExprKind::Scope { region_scope, lint_level, value } => { let region_scope = (region_scope, source_info); <del> this.in_scope(region_scope, lint_level, |this| this.into(destination, block, value)) </del> <ins> ensure_sufficient_stack(|| { this.in_scope(region_scope, lint_level, |this| { this.into(destination, block, value) }) }) </ins> } ExprKind::Block { body: ast_block } => { this.ast_block(destination, block, ast_block, source_info)

Discussion:
First reported to me at I believe the stack overflow is in rustc itself. when compiled yields: where nightly today is:
Assigning as and removing .
It would be nice to bisect this one if possible ... 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-05 to nightly-2020-07-22 regressed nightly: nightly-2020-05-08 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailscc
cc for anyone wanting to fix this, these kind of bugs are very easy to fix. You run rustc in until you get a stack overflow, then you look at the backtrace and look for recursion in there. Then you break the recursion overflow by inserting a use of at the recursive call site.
That sounds a good first bug to me. I'll give it a shot.
Change:
//~^ ERROR this function takes 1 argument but 0 arguments were supplied let ans = s("burma", "shave"); //~^ ERROR this function takes 1 argument but 2 arguments were supplied <ins> //~| ERROR mismatched types </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. --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. --: <!-- 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 --
searched toolchains through Regression in probably cc
I can look into this claim
Change:
(false, false, false) => c::OPEN_EXISTING, (true, false, false) => c::OPEN_ALWAYS, (false, true, false) => c::TRUNCATE_EXISTING, <del> (true, true, false) => c::CREATE_ALWAYS, </del> <ins> // `CREATE_ALWAYS` has weird semantics so we emulate it using // `OPEN_ALWAYS` and a manual truncation step. See #115745. (true, true, false) => c::OPEN_ALWAYS, </ins> (_, _, true) => c::CREATE_NEW, }) }

Discussion:
Reported on discord, using will fail on Windows if the file is hidden. This also affects methods like or that open the file the same way. The reason for this is that we use , which has : So to make it work the caller needs to match the requested attributes to the existing attributes at the time of opening. It was suggested we could instead use and then manually truncate the file using to zero.
Manually truncating would require also clearing the alternate data streams too, right? And it would presumably stop erroring if another process still has the file open and instead corrupt the file fron the view of the other process.
No? The proposed solution would work the same was as in the case where the file already exists. Which we use for .
Right, got confused with .
Change:
.source .sidebar > *:not(#sidebar-toggle) { opacity: 0; visibility: hidden; <del> transition: opacity 0.5s; </del> } .source .sidebar.expanded {

Discussion:
Load Open files panel on the left. Refresh page. You'll notice everytime you load the page, the file list slides again. So we now have to wait 1s for it to stop sliding before starting to read the file we clicked on. Btw, I'd rather this never slides at all. This is time loss anyway. Could there be an option to disable this?
So there are two different things here apparently: removing the animation Don't remember the file sidebar state Did I get it right?
Yes absolutely A single simple solution to both "things" could be to completely remove the animation. I don't know of any IDE that does this - probably because it isn't optimal with regards to ergonomics. The fact the new panel now slides the code so we can read the code and have the panel open at the same time is still an improvement over the previous panel, even if we revert the animation part.
I think the idea behind the animation is to allow the reader to see that it's not hovering the code. As for the setting, not sure. What do you think
I agree with we should remove the animation. It bothers me as well, I just haven't found the time to file an issue / PR about it. :-) I don't think we should add a setting.
Ok, I'll remove the animation then. Will send a PR tomorrow. For the setting, it's that we keep the current save the state of the sidebar. Should I remove it as well?
My idea of new setting was rather "should there be an animation or should it be static", if we didn't want to remove the animation completely, for those of us that don't think the animation is worth the wait (so no need for a such new setting if we just remove the animation completely :) ) With regards to the other setting idea you seem to be talking about, it seems reasonable to me to always keep the current state of the sidebar, as we currently do, and not add an extra setting for that either :)
Oh ok. Well, that cleared things up. I'll just remove the animation then.
Change:
<ins> error[E0573]: expected type, found built-in attribute `feature` --> $DIR/issue-78654.rs:10:15 | LL | impl<const H: feature> Foo { |               ^^^^^^^ not a type error[E0207]: the const parameter `H` is not constrained by the impl trait, self type, or predicates --> $DIR/issue-78654.rs:10:12 | LL | impl<const H: feature> Foo { |            ^ unconstrained const parameter | = note: expressions using a const parameter must map each value to a distinct output value = note: proving the result of expressions other than the parameter are unique is not supported error: aborting due to 2 previous errors Some errors have detailed explanations: E0207, E0573. For more information about an error, try `rustc --explain E0207`. </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</detailsNOTE: The bug is found by our work-in-progress compiler testing tool Kira, and the test program is reduced/minimized by <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Related to .
My hunch is that this code: needs to be generalized to also accept a . The function could just return (or maybe ) in that case and I expect the ICE would go away.
I'm tagging this as E-mentor because of the above instructions (feel free to also ping me on Zulip)
claim
Change:
LL |     extern "rust-call" fn call_mut(&mut self, args: Args) -> Self::Output; |                           ^^^^^^^^ <del> error: aborting due to 3 previous errors </del> <ins> error: aborting due to 4 previous errors </ins> Some errors have detailed explanations: E0057, E0308. For more information about an error, try `rustc --explain E0057`.

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. --: <!-- 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 --
searched toolchains through Regression in probably cc
I can look into this claim
Change:
# Extra flags needed to compile a working executable with the standard library ifdef IS_WINDOWS ifdef IS_MSVC <del> EXTRACFLAGS := ws2_32.lib userenv.lib shell32.lib advapi32.lib </del> <ins> EXTRACFLAGS := ws2_32.lib userenv.lib advapi32.lib </ins> else EXTRACFLAGS := -lws2_32 -luserenv endif

Discussion:
An showed that removing the dependency from LLVM speed up its test suite by a huge amount. For us libstd doesn't depend on directly but it does depend on which depends on (according to the blog post). Specificaly it looks like , the same function as LLVM, is used by us! It'd be great to investigate removing the shell32 dependency from libstd (may be a few other functions here and there). We should run some tests on Windows to see if this improves rustc cycle times!
Based on my limited investigation, it's likely that replacing with a pure Rust equivalent should be good enough to get rid of the gdi32 dependency in things that only use libstd. So really someone just needs to write that pure Rust implementation which should be easy to do.
It would be nice to get rid of this in the compiler too. We spawn a lot of compiler instances during bootstrapping.
So now that the change has been implemented, have we actually investigated how much of an impact the change made?
Perf, an lolbench are both linux only. So nether help with this question. So don't waste your time like I did.
Here are just number for on 8 cores / 16 threads on Windows 10 v1809: Without the dependency: 333.012 325.587 320.650 With : 310.852 319.165 323.645
For what it's worth, though there's no good way to differentiate PR-to-PR due to very high variance, it does look like there was a recent regression in PR build times: <img width="1409" alt="image" src="https://user-"
I see that the CPU usage averages about 40% when running , so maybe we'd see some real improvements if we got rid of in the compiler too. Something is certainly holding things back.
Yeah, I saw that the compiler doesn't load . So there's probably some other reason why doesn't load all the cores.
Change:
return false; } <ins> if !please_inline && let mut visitor = OneLevelVisitor::new(self.cx.tcx.hir(), res_did) && let Some(item) = visitor.find_target(self.cx.tcx, def_id.to_def_id(), path) && let item_def_id = item.owner_id.def_id && item_def_id != def_id && self .cx .cache .effective_visibilities .is_directly_public(self.cx.tcx, item_def_id.to_def_id()) && !inherits_doc_hidden(self.cx.tcx, item_def_id) { // The imported item is public and not `doc(hidden)` so no need to inline it. return false; } </ins> let ret = match tcx.hir().get_by_def_id(res_did) { Node::Item(&hir::Item { kind: hir::ItemKind::Mod(ref m), .. }) if glob => { let prev = mem::replace(&mut self.inlining, true);

Discussion:
When running with the above code, the docs list the following items: <details<summaryDocs</summary </detailsI would expect to be listed as a reexport, not a struct. The way it is now, it looks like and are different types, which is not the case. If is made , everything looks as it's supposed to. label +T-rustdoc
It's the intended behaviour. Since the module is private, is inlining the item into .
Yes, but is public, so should it really be inlined a second time?
Ok sorry I misunderstood what you meant. No, it shouldn't be inlined a second time.
Change:
)), Some( "the question mark operation (`?`) implicitly performs a  <del> conversion on the error value using the `From` trait" </del> <ins> conversion on the error value using the `From` trait" </ins> .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:
<ins> // Checks that the following does not ICE. // // Previously, this test ICEs when the `unused_must_use` lint is suppressed via the combination of // `-A warnings` and `--cap-lints=warn`, because: // // - Its lint diagnostic struct `UnusedDef` implements `LintDiagnostic` manually and in the impl //   `def_path_str` was called (which calls `trimmed_def_path`, which will produce a //   `must_produce_diag` ICE if a trimmed def path is constructed but never emitted in a diagnostic //   because it is expensive to compute). // - A `LintDiagnostic` has a `decorate_lint` method which decorates a `Diag` with lint-specific //   information. This method is wrapped by a `decorate` closure in `TyCtxt` diagnostic emission //   machinery, and the `decorate` closure called as late as possible. // - `decorate`'s invocation is delayed as late as possible until `lint_level` is called. // - If a lint's corresponding diagnostic is suppressed (to be effectively allow at the final //   emission time) via `-A warnings` or `--cap-lints=allow` (or `-A warnings` + `--cap-lints=warn` //   like in this test case), `decorate` is still called and a diagnostic is still constructed -- //   but the diagnostic is never eventually emitted, triggering the aforementioned //   `must_produce_diag` ICE due to use of `trimmed_def_path`. // // Issue: <https://github.com/rust-lang/rust/issues/121774>. //@ compile-flags: -Dunused_must_use -Awarnings --cap-lints=warn --crate-type=lib //@ check-pass #[must_use] fn f() {} pub fn g() { f(); } </ins>

Discussion:
Input:
Bisects to Rust 1.55.0, and nightly-2021-07-20. In older stable and nightly releases, this compiles successfully.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
bisection points to rollup If I had to guess, I'd say that looks like the one. It's the only one in the rollup touching diagnostic code. Possibly my reasoning is off (pls correct me).
Something went wrong with your bisect, as is from 2022-02-02, whereas this ICE is present in nightly-2021-07-20. looks the most likely to me.
Either way, this is probably easier to debug from scratch instead of digging around commits. Previous issue with this ICE message should reveal information on how to fix these issues, which arise from eagerly formatting paths in lints instead of only when they're emitted.
Fix for a similar issue :
Change:
_ => visit::walk_stmt(self, stmt), } } <ins> fn visit_token(&mut self, t: Token) { if let Token::Interpolated(nt) = t { match nt.0 { token::NtExpr(ref expr) => { if let ExprKind::Mac(..) = expr.node { self.visit_macro_invoc(expr.id, false); } } _ => {} } } } </ins> }

Discussion:
This issue probably needs a better title, perhaps someone more familiar with the compiler's handling of macros can suggest a better one. Some kind of error message, at least. panic with exit code :
Simplified: Same ICE will happen if is changed to ///. Update: Panic happens at this line: has keys and , but the is .
Change:
p: P, } <ins> pub struct StructWithPublicUndocumentedFields { pub first: u32, pub second: u32, } </ins> pub const CONST: u8 = 0; pub trait TraitWithoutGenerics {

Discussion:
! label A-rustdoc-ui T-rustdoc C-bug regression-from-stable-to-nightly
Regressed in . Out of these it's probably cc
Change:
<del> Subproject commit 84abffda0e03b03c62bdfc3cfeda1c2cf1f88c85 </del> <ins> Subproject commit eb38a1888d1d29b2d2c6b31428a5201cd8fba0ff </ins>

Discussion:
Unfortunately I can't get a backtrace as running inside a debugger prevents it from crashing. Reproduction: Clone Checkout commit and follow the instructions on the top of the readme. Sometimes the execution succeeds, so you may have to remove the dir when it succeeded.
Got backtraces for all thread by loading a core dump:
After trying compiling it many times it does succeed, but the resulting wasm file is corrupt: . This may have the same cause, but I am not sure.
Based on ^-- I'm tentatively labeling as a soundness hole since it seems that type preservation is violated? (Haven't looked closely)
Reduced repro: <details</summary</detailsEdit: Reduced it even more.
I've got a bit more specific one from
LLVM IR for reproducer: Running this through against current LLVM master gives the following assertion failure: With backtrace:
Reduced test case:
Upstream report:
Fixed upstream:
Thanks so much for tracking that down and fixing it! I've opened an update of our submodule at