jiebi/CodeConvo huggingface dataset:
Change:
use dep_graph::DepGraph; use middle::infer::InferCtxt; <del> use middle::ty::{self, Ty, TypeFoldable}; </del> <ins> use middle::ty::{self, Ty, TypeFoldable, ToPolyTraitRef}; </ins> use rustc_data_structures::obligation_forest::{Backtrace, ObligationForest, Error}; use std::iter; use syntax::ast;

Discussion:
This takes ~2 seconds to type check (according to ): Doubling (respectively, halving) the number of invocations multiplies (resp. divides) the time by 4. It applies to arithmetic in s/s too which is, I imagine, where this will occur most often in practice (it's how I found it). Observations: for , , and , annotating either side (e.g. ) or both sides makes it take only 0.03s and behave linearly (AFAICT) for and : annotating the LHS () reduces the time to ~1.5s, annotating the RHS () reduces it to ~1.1s but both are still quadratic, annotating both takes it to 0.04s and linear it seems to only be dependent on the number of operations in a single function/item, separating the 4 big chunks above across 4 functions reduces the time to ~0.5s. there's no significant difference between using the macro or writing the operations inline (I only use to allow easier experimentation) cc
This must be what's making my old macro-abusing inflate implementation take almost 300 seconds in typeck. It almost sounds like type-checking a function is quadratic over the number of inference variables. Having ran callgrind on the sample and also half of it, I'm seeing the following trace: An unrefined conclusion is that either shouldn't call or should be constant-time.
Is this the same issue as ?
I'm not too familiar with fulfill and infer, but couldn't track the latest snapshot it processed and look at the new information there?
We have exactly for this reason. It doesn't work for some reason tho.
This is the same issue as This is a different issue from (I think I will fix that one separately).
Change:
//! `ExprUseVisitor` determines how expressions are being used. pub use self::ConsumeMode::*; <del> use self::OverloadedCallType::*; </del> // Export these here so that Clippy can use them. pub use mc::{Place, PlaceBase, Projection};

Discussion:
Problematic code: Minimal reproduction: This ICE happens on both nightly and stable. rustc 1.42.0-nightly ( 2020-01-06) binary: rustc commit-hash: commit-date: 2020-01-06 host: x86_64-unknown-linux-gnu release: 1.42.0-nightly LLVM version: 9.0 Backtrace:
I'm not sure how to reproduce the ICE given the two snippets at the top. Can you clarify the minimal reproduction: how do I reproduce it in the playground?
Simplified:
The failure occurs here: I guess we can add to first arm (), is it safe?
triage: P-high. Removing I-nominated label.
Change:
} /// LTO mode used for compiling rustc itself. <del> #[derive(Default, Clone)] </del> <ins> #[derive(Default, Clone, PartialEq)] </ins> pub enum RustcLto { <ins> Off, </ins> #[default] ThinLocal, Thin,

Discussion:
Currently bootstrap supports LTO flavors thin-local (default), thin and fat. Adding the option to completely disable it can speed up develop cycles, especially with incremental compilation. See for benchmarks. When LTO is disabled the standard library still has to be built with so that it can be used by other crates which enable LTO. Disabling should become the default for the library and compiler profile templates. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim to not loose it to time, but feel free to claim it if you want, I might not start work on this until February.
Error: Parsing assign command in failed: ...' claim' ' to not lo'... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
claim Shouldn't this bot be able to detect end of command and silently ignore the rest of the line ?
Change:
} pub fn sign_extend(&self, value: u128, ty: Ty<'tcx>) -> EvalResult<'tcx, u128> { <del> let layout = self.layout_of(ty)?; let size = layout.size.bits(); assert!(layout.abi.is_signed()); // sign extend let amt = 128 - size; // shift the unsigned value to the left // and back to the right as signed (essentially fills with FF on the left) Ok((((value << amt) as i128) >> amt) as u128) </del> <ins> super::sign_extend(self.tcx.tcx, value, ty) </ins> } pub fn truncate(&self, value: u128, ty: Ty<'tcx>) -> EvalResult<'tcx, u128> { <del> let size = self.layout_of(ty)?.size.bits(); let amt = 128 - size; // truncate (shift left to drop out leftover values, shift right to fill with zeroes) Ok((value << amt) >> amt) </del> <ins> super::truncate(self.tcx.tcx, value, ty) </ins> } }

Discussion:
The previous version of the crate fails to compile with the error (see the build log). No error nor warning was present in the 1.25 release. Since is actually , the error is wrong and should be fixed. regressed from stable to beta () cc
cc -- initial git log dive notes that this could be related to miri transition? Not sure.
Jup it's a regression. :
Not yet fixed on beta, this needs a backport.
Backported to beta! Thanks!
Change:
| = help: unlike in C++, Java, and C#, functions are declared in `impl` blocks = help: see https://doc.rust-lang.org/book/ch05-03-method-syntax.html for more information <ins> = help: enum variants can be `Variant`, `Variant = <integer>`, `Variant(Type, ..., TypeN)` or `Variant { fields: Types }` </ins> error: aborting due to 3 previous errors

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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Although I know Enums take to form of: I sometimes find myself accidentally defining them as I would a Struct (): The current output is: This always takes more than a few seconds to parse and then realize my mistake. Is it possible to change this to something like: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Do you have any suggestion for how the compiler should distinguish between "trying to write an enum with struct syntax" and "trying to write a struct but used the enum keyword"?
Linking to the topic on internals where some other folks have left suggestions (). Although none of those directly address your question. My gut reaction is to assume that if the "enum" keyword is used that truly was the intention of the developer, but if it wasn't, hopefully some help message like the : Would provide enough information to trigger an "Oh wait did I really want to use an enum here?"
claim
Change:
let mut native: libc::pthread_t = intrinsics::uninit(); let mut attr: libc::pthread_attr_t = intrinsics::uninit(); assert_eq!(pthread_attr_init(&mut attr), 0); <ins> let min_stack = get_min_stack(&attr); </ins> assert_eq!(pthread_attr_setstacksize(&mut attr, <del> stack as libc::size_t), 0); </del> <ins> min_stack + stack as libc::size_t), 0); </ins> assert_eq!(pthread_attr_setdetachstate(&mut attr, PTHREAD_CREATE_JOINABLE), 0);

Discussion:
Linking with certain external libraries can inflate the required amount of thread local storage to astronomical proportions. When the Rust runtime tries to create its threads, it requests a stack size independent of the TLS size, which can lead to pthreadcreate() failing with EINVAL when the stack size is smaller than the TLS size. This was apparently an issue for the Go runtime as well (). A potential workaround is to add statictls_size (+ possibly a guard page) to the requested stack size, but it's arguably a bug in glibc that TLS comes out of the requested stack, instead of being to it. This solution is also admittedly not very pleasing...
I made a mistake. The workaround should actually be to add _pthreadgetminstack(&attr) to the requested size in It's still not very pleasing.
This is the bug in glibc
Still relevant, but it's an upstream bug. Removing E-easy
Triage: we still call without adjusting for so I assume that the work-around hasn't been implemented, and the upstream bug is still open (and without activity for more than 3 months).
Triage: still a bug even with the pure Rust runtime. With it crashes with: and without that it runs fine. I'll attempt to fix it now.
(The above crash appears to not happen on Mac OSX; I'm on Linux.) I opened ; but I don't think that work-around is complete enough to close this.
My patch caused people linking errors ( is apparently not in all versions of glibc (works in 2.17, fails with 2.13), being a private function), so I'm reverting it in .
Change:
// Tests that we can compare various kinds of extern fn signatures. #![allow(non_camel_case_types)] <del> extern fn voidret1() {} extern fn voidret2() {} </del> <ins> // `dbg!()` differentiates these functions to ensure they won't be merged. extern fn voidret1() { dbg!() } extern fn voidret2() { dbg!() } </ins> extern fn uintret() -> usize { 22 }

Discussion:
Code: Output in release mode: There is a similar issue about , but incorrect comparison of may be more dangerous. For example, if unsafe code checks the equality between to uphold its invariant, passing values obtained this way may break the invariant, even though the unsafe code itself didn't work with function pointers.
In some sense there's no bug here, this is expected: comparing function pointers should behave the same with or without the cast. What is more surprising is that they print the same. This indicates that comparison is non-deterministic... which is rather problematic indeed, and could break plenty of LLVM optimizations.
Indeed this can be turned into a demonstration of non-deterministic comparison: The second assertion fails, the first passes (in release mode on 1.45.2). That's no good. In principle this could lead to a soundness bug, though I am not sure if that can be actually done in practice. Cc
This is an LLVM bug:
But MIR optimizations also have to be aware that folding equality tests on functions is subtle (Cc And recently had to prevent me from making a similar mistake for pointer equality tests in CTFE (Cc
The LLVM bug has been fixed. (pinging you in lieu of there being a way to ping the LLVM WG), do you usually backport such fixes or wait for the next release?
cc (pinging LLVM WG) I suspect we'll want to backport the patch ourselves, and try to nominate it for LLVM 11 (since that's not yet released, and we're currently on a release candidate). is the thing to backport I think.
Assigning as discussed as part of the and removing .
Discussion on the LLVM bug is that it's too late for 11.0.0, but could be to 11.0.1. If someone wants to see the fix sooner in rust's fork, I'm happy to review PRs: https://rustc-dev-
Change:
let reachable = traversal::reachable_as_bitset(body); <ins> let drop_flags = IndexVec::from_elem(None, &env.move_data.move_paths); </ins> ElaborateDropsCtxt { tcx, body, env: &env, init_data: InitializationData { inits, uninits }, <del> drop_flags: Default::default(), </del> <ins> drop_flags, </ins> patch: MirPatch::new(body), un_derefer: un_derefer, reachable,

Discussion:
This code creates MIR statements based on an iteration order: is defined as: Since FxHashMap's fixed seed is different between 32 and 64 bit platforms, we may end up creating statements in a different order on 32-bit vs 64-bit hosts (the target platform passed to the compiler has no effect). We should probably sort by before creating the statements.
Perhaps it should just use instead?
Revisiting this issue to evaluate the priority. unsure about the status and global direction of this issue. Do we have some work in progress somewhere? I've tried following the breadcrumbs and landed on . Unsure if it helps and - if yes - how much does that pull request covers to fix this issue. opinions? thanks :)
Change:
// We enter it into the search. write: (".search-input", "HasALongTraitWithParams") wait-for-document-property: {"title": "HasALongTraitWithParams in lib2 - Rust"} <del> assert-document-property: ({"URL": "/lib2/struct.HasALongTraitWithParams.html"}, ENDS_WITH) </del> <ins> assert-window-property: ({"location": "/lib2/struct.HasALongTraitWithParams.html"}, ENDS_WITH) // Regression test for <https://github.com/rust-lang/rust/issues/112676>. // If "go-to-only-result" is enabled and you go back to history, it should not lead you back to the // page result again automatically. history-go-back: wait-for-document-property: {"title": "lib2 - Rust"} assert-window-property: ({"location": "/lib2/index.html"}, ENDS_WITH) </ins> // We try again to see if it goes to the only result go-to: "file://" + |DOC_PATH| + "/lib2/index.html?search=HasALongTraitWithParams"

Discussion:
Reproduction: Go to Click the gear next to the search field, enable "Directly go to item in search if there is only one result" Refresh page to ensure it's enabled (was required the first time I tried to reproduce, but seemed to work straight away the second time) Search for You should be taken straight to Press "Back" in your browser I expected this to happen: Go back to Instead, this happened: Goes back to then instantly redirects forward again
Taking a look.
Fixed in
Change:
<ins> // The `Trait` is not pulled into the crate resulting in doc links in its methods being resolved. // aux-build:issue-103463-aux.rs extern crate issue_103463_aux; use issue_103463_aux::Trait; fn main() {} </ins>

Discussion:
Run on this and get an ICE. Note that documenting itself does not panic, and that the is necessary. <!-- 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. --: Also reproduces on Linux (GitHub Actions) with the same nightly version. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details label +T-rustdoc -T-compiler
It looks like this started after commit . () I was able to create a MCVE: <details<summaryBacktrace:</summary</details
cc
Further minimized: The issue disappears if the private is removed. Looks like some logic in rustdoc is over-eager to pull in stuff through private imports, links in 's methods are not visible in the generated documentation and shouldn't be resolved at all.
--are responsible for including the trait into the rustdoc's crate representation, still unclear why.
Fixed in
Change:
<ins> // Copyright 2018 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // error-pattern: `main` function is not allowed to have lifetime parameters fn main<'a>() { } </ins>

Discussion:
The error says type parameters when it should say lifetime parameters in this case. This is definitely a low priority issue. Might make a good first issue though?
I propose to work on that one.
Change:
crate_name: crate_name, deriving_hash_type_parameter: false, enable_quotes: false, <ins> recursion_limit: 64, </ins> } } }

Discussion:
Defining macros recursively like so will lead rustc to cause a stack overflow. It would be useful to improve the error message for that problem. There is currently no error message specified for that issue.
We already have a field in . We can copy it to libsyntax's and then track the recursion depth in .
I am looking into this issue. Howerver it seems like the same and are used for macro expansion, so it seems like recursion depth cannot be tracked naively.
The methods and already maintain a sort of stack of macro invocations. They can also maintain a counter so that we don't have to walk that stack on every check (it's a kind of indirect linked list).
Now that recursion depth is limited, is there anyway to configure it from the command line? The current depth setting (64?) is too aggressive for some macro magic I am working on, that recurses heavily.
I could at least increase it to 256 if that would help. Other than that someone else ( maybe) should look into it.
My patch did not include any method to customize the depth limit. I just used 64 because defaults to that as well. I am not aware of a command line interface to change session attributes, but I am not very familiar with rustc`s command line interface. Another way to customize the recursion depth for macro expansions could be using something like for macros which result in deeper recursions, but no in an infinite recursion. Anyhow, if there is a decision to do it one way or another, I'd be happy to work on a patch.
Could we at least for now bump the limit up to something much larger? The current setting of 64 is probably too low for macros that rely on reduction rules. (ie that match a portion of a statement and pass the remainder to another macro (often itself) for further expansion). I don't have a good handle on the expense of each macro expansion in terms of compiler memory/time ... but is there any reason for it not to be a number on a much larger scale, such as 1024?
I like the idea of a file/crate attribute to govern the recursion depth of macros expanded within that crate.
I will try to increase it to 2048. Someone else should maybe look into the attribute or command line argument thing.
Seems that 2048 is way to high and already causes stack overflows.

If just the compiler wouldn't compile forever...
Seems surprising ... are you changing the to be 2048, or changing it at the level as well?
Just the ExpansionConfig limit, since the session limit won't go crazy way too far. I guess 1024 is still ok for macros. It is compiling and testing right now, so I can tell you more later.
Ah, I misunderstood you, I thought you meant the overflows were happening when compiling the compiler! You mean rather that an infinite recursion test will overflow before it hits the 2048 limit I think.
Yes
I got a workaround, but I guess it is not the best way. Sadly I got ill, so I won't be able to work on it further. Maybe someone else could go on? /cc ()
Change:
} } } <ins> forward_ref_binop! { impl Shr, shr for Wrapping<$t>, $f, #[stable(feature = "wrapping_ref_ops", since = "1.39.0")] } </ins> #[stable(feature = "op_assign_traits", since = "1.8.0")] impl ShrAssign<$f> for Wrapping<$t> {

Discussion:
The other day I noticed that only implements and co. for , which contradicts that without the shift amount can be any type. So, I think it may be useful to create tests which use macros to shove together all the types we expect to have impls for and check that we're consistent there. What I've noticed: For every operation three extra impls are , with the combinations of single-level references on both sides, e.g. , , for . Assignment ops do the same as the above, with only one extra impl, e.g. for . , , , , exist for all int and float types with themselves , , exist for all int types and bool and allow any integer type for both the left and the right side exists for all ints and floats exists for all ints and bool should mimic all of the above, where references are of the form and not . Like, I wouldn't be surprised if rearranging some macros might add or remove impls for these and adding comprehensive tests might help make sure we covered everything. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This seems like a simple but useful task, I will try to finish it.
I am reformulating the task to make sure it is clear (to myself at least) : Create tests using a set of macros to check that every numerical instances of for the following operations are implemented for every combination of numerical instances (, , ...) : with : * having the integer and float types with themselves, ¤ having the integer and bool types with themselves, having the integer and float types with themselves, and Am I correct ? How does this relate to ?(e.g. is it possible to bypass the bug and still implement the test ? I could not see from the issue if a solution had been found)
claim isn't implemented for and /. So this is probably only useful for integer types.
This doesn't actually fix the issue; it should be tested for all types, not just .
Hi ! Are you or anyone else working on adding the missed tests?
They're free for anyone to implement right now!
Nope, not right now. Feel free to take over.

It should be pretty similar to , just add the missing types (bool, fp) and operators (bit wise operators).
Thank you very much and , I'll send a PR.
unassign
claim I'll try to get a PR in by next weekend, If nothing happens past that I'm afraid I may have been too busy so [anyone] feel free to overtake :smile:
claim
Hi, are you still working on this issue
I'm sorry, I couldn't do it. Please feel free to reassign this.
No worries release-assignment
Change:
<ins> fn main() { let e: i32; match e { //~^ ERROR use of possibly uninitialized variable ref u if true => {} ref v if true => { let tx = 0; &tx; } _ => (), } } </ins>

Discussion:
ICE with the borrow checker on nightly. Tried on stable/beta and it correctly errors with in nightly, I get : Backtrace:
Reduced: cc
Bisected this one to and , that is, PR . cc
Change:
}; } <ins> // Only d_reclen bytes of *entry_ptr are valid, so we can't just copy the // whole thing (#93384).  Instead, copy everything except the name. let entry_bytes = entry_ptr as *const u8; let entry_name = ptr::addr_of!((*entry_ptr).d_name) as *const u8; let name_offset = entry_name.offset_from(entry_bytes) as usize; let mut entry: dirent64 = mem::zeroed(); ptr::copy_nonoverlapping(entry_bytes, &mut entry as *mut _ as *mut u8, name_offset); </ins> let ret = DirEntry { <del> entry: *entry_ptr, </del> <ins> entry, </ins> // d_name is guaranteed to be null-terminated. <del> name: CStr::from_ptr((*entry_ptr).d_name.as_ptr()).to_owned(), </del> <ins> name: CStr::from_ptr(entry_name as *const _).to_owned(), </ins> dir: Arc::clone(&self.inner), }; if ret.name_bytes() != b"." && ret.name_bytes() != b".." {

Discussion:
runner: x8664-gnu-llvm-12, ubuntu-20.04-xl Occured in multiple pr across CI: : : : : and others
Possibly this was ? Looking at what's been merged in the last day, that seems to be the most relevant thing
You mean it might have introduced a new miscompilation that made compiletest crash?
Maybe. Its also possible that there was some existing UB elsewhere that happened to get set off by this, don't really know. My observation just mostly comes from where the segfault is happening and what commits in the last day have touched nearby code
Why this even triggered? Looks unrelated, but still suspicious.
Those warnings are unrelated. I'll post a patch soon to fix it. EDIT:
Funny thing: been merged even with crashed compiletest: , how this works?
The comment by is about the CI run not the bors run.
Yes, it failed on PR check, not on check-all-platforms-and-merge. So fast approving PR, so it merged even with failed PR check :-(
can you try to revert that pr and see, will it fail or not on test?
Yeah, I can do that before the end of the day
Reverting didn't fix it. Its still very suspicious that this started right after that got merged though. I'll leave the branch up on my fork for a little in case anyone else wants to re-run things or something.
The issue appears to be caused by a copy of dirent made in . Only a part of the structure as described by is actually dereferenceable: Which was recently changed for Linux and Android in .
It sounds like reverting that PR would be a good first step, since the bugs it fixes look less critical to me given that diagnosis. (Of course, maybe there is a more forward-moving fix, but a revert seems like something we can merge with less caution). cc
I'll take a look. do you mean the part? I didn't expect but maybe it's possible.
Oh indeed that seems to happen all the time. One sec I'll put up a patch