jiebi/CodeConvo huggingface dataset:
Change:
<ins> warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/issue-70167.rs:3:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default </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. --I was writing some generic code over vectors using the under-construction feature of const generics, and had a circular chain of super-traits that required me to cast the Self type to the trait as can be seen in the supertrait requirement. I believe that is causing the MIR error. I think this may be related to but it is subtly different so I'm putting the issue up regardless. <!-- 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. --: I updated my rust version on nightly right before I ran this so hopefully it is up to date: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
minimized: claim
Looks like maybe constants in trait paths don't get their type correctly? cc
Initially I thought this was about bounds but no, this also fails: ()
I believe this code is responsible: And the problem is that this doesn't handle associated types which need the same treatment:
Alternatively, instead of using to get the , maybe we could use the olution from the segment we found the const parameter in? I believe nowadays we have per-segment resolutions, which would avoid breaking GATs in the future. Actually, I expect is also broken, let's try it... Yupp: () EDIT: took a second look and that is in a , which has to be resolved by the body of , which means it's as bad as the method call form (which I just ). Maybe we should disallow passing explicit generic args to methods for now? Since I have no idea how one would figure out the expected type.
If you look at this later btw, my comment above () still isn't addressed, but I haven't made an issue yet about it.
Change:
<ins> // check-pass pub trait Foo { type Error: Error; fn foo(&self, stream: &<Self::Error as Error>::Span); } pub struct Wrapper<Inner>(Inner); impl<E: Error, Inner> Foo for Wrapper<Inner> where Inner: Foo<Error = E>, { type Error = E; fn foo(&self, stream: &<Self::Error as Error>::Span) { todo!() } } pub trait Error { type Span; } 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. --This code compiles on the and channels, but crashes with an ICE on the channel. : (Backtrace omitted) .. And so on for , , etc. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Minimized (from the chumsky crate) to: or (from the above) to: Bisected with v0.6.6 to , which is and that PR does look like it's in the right area to have caused this.
Change:
The arguments to this flag are the same as those for the `-C` flag on rustc. Run `rustc -C help` to get the full list. <del> ## `--passes`: add more rustdoc passes Using this flag looks like this: ```bash $ rustdoc --passes list $ rustdoc src/lib.rs --passes strip-priv-imports ``` An argument of "list" will print a list of possible "rustdoc passes", and other arguments will be the name of which passes to run in addition to the defaults. For more details on passes, see [the chapter on them](passes.md). See also `--no-defaults`. ## `--no-defaults`: don't run default passes Using this flag looks like this: ```bash $ rustdoc src/lib.rs --no-defaults ``` By default, `rustdoc` will run several passes over your code. This removes those defaults, allowing you to use `--passes` to specify exactly which passes you want. For more details on passes, see [the chapter on them](passes.md). See also `--passes`. </del> ## `--test`: run code examples as tests Using this flag looks like this:

Discussion:
From So not sure which way seems better? What do you think ?
Yeah I think we should document the new stuff and remove the docs for the deprecated stuff (perhaps mention that these deprecated features exist, but not document them in depth)
I've felt confused about this before: Why do we even let people customize which passes are run? That seems like unnecessary entanglement with rustdoc internals.
Also, there doesn't seem to be a flag. Are you thinking of ? If so, rustdoc says that's deprecated. Edit: It looks like is deprecated as well.
What is "the new stuff"? Do you mean things like ? Other than my confusion about that, I agree with Manish here. I think we should mention the deprecated features, but not document them extensively since they shouldn't be used anyway. If we extensively document deprecated features, we are wasting our time and our readers' time.
Yes. I do think the pass infra should stay mostly internal, with specific options being exposed via specific attributes. How we construct it internally should not be something the user should ever have to care about.
Change:
ty::TyProjection(ref proj) => Some(proj.item_def_id), ty::TyFnDef(def_id, ..) | ty::TyClosure(def_id, ..) | <ins> ty::TyGenerator(def_id, ..) | </ins> ty::TyAnon(def_id, _) => Some(def_id), _ => None };

Discussion:
I've hit an ICE with the new generator support that has just landed (nightly 2017-08-29). I've reduced it to the following : This is essentially the same issue as . I can't reproduce the original ICE with closures as described there, but I run into it with generators.
I believe this ICE is more related to "impl Trait" rather than generators, but we'll find out!
I think also needs to be adapted for generators.
looks like ! Thanks for the pointer!
Change:
pub fn try_send(&self, t: T) -> bool { // In order to prevent starvation of other tasks in situations where // a task sends repeatedly without ever receiving, we occassionally <del> // yield instead of doing a send immediately.  Only doing this if // we're doing a rescheduling send, otherwise the caller is // expecting not to context switch. </del> <ins> // yield instead of doing a send immediately. </ins> // <del> // Note that we don't unconditionally attempt to yield because the // TLS overhead can be a bit much. </del> <ins> // Don't unconditionally attempt to yield because the TLS overhead can // be a bit much, and also use `try_take` instead of `take` because // there's no reason that this send shouldn't be usable off the // runtime. </ins> let cnt = self.sends.get() + 1; self.sends.set(cnt); if cnt % (RESCHED_FREQ as uint) == 0 { <del> let task: ~Task = Local::take(); task.maybe_yield(); </del> <ins> let task: Option<~Task> = Local::try_take(); task.map(|t| t.maybe_yield()); </ins> } let (new_inner, ret) = match self.inner {

Discussion:
Reporting this here after asking in IRC something like this: where c_callback is called from a thread created by the c library crashes the application after a while with: previously SharedChan seemed to work without problem
cc It looks like the new can no longer be used outside a runtime?
Whoops, testing a fix now (sorry about that!)
thanks!
sorry to post on a closed issue, but i'm finding the same problem now in SyncChan/SyncPort not sure if it's a real bug or in this case it's supposed to work like that?
You won't be able to use those off the runtime because a send involves then receiving which blocks the task. You're only able to block if you have a local rust task available.
that's what i was suspecting, thanks!
Change:
struct_span_err!(sess, sp, E0004, "{}", &error_message) } <ins> #[derive(PartialEq)] enum RefutableFlag { Irrefutable, Refutable, } use RefutableFlag::*; </ins> struct MatchVisitor<'a, 'p, 'tcx> { tcx: TyCtxt<'tcx>, typeck_results: &'a ty::TypeckResults<'tcx>,

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. --Given the following code: The current output is: Ideally the lint should not trigger on such a pattern, it does not really make sense and the suggestion is wrong altogether,
label: +D-confusing +D-incorrect
Note that the suggestion isn't wrong in this particular case, because can actually match any Foo. It's wrong only when has 2+ variants.
Right, the real world case of this was with the ascii crate with the AsciiChar enum, this is just a tiny test case
Change:
<ins> #![feature(type_alias_impl_trait, generator_trait, generators)] use std::ops::Generator; trait Runnable { type Gen: Generator<Yield = (), Return = ()>; fn run(&mut self) -> Self::Gen; } struct Implementor {} impl Runnable for Implementor { type Gen = impl Generator<Yield = (), Return = ()>; fn run(&mut self) -> Self::Gen { move || { //~ ERROR: type mismatch resolving yield 1; } } } fn main() {} </ins>

Discussion:
Possibly related to as both ICEs arise from , but this ICE occurs on a different line. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
No longer ICEs since

I tried this code: I expected to see this happen: code compiles successfully Instead, this happened: : : modify labels: +requires-nightly +F-typealiasimpl_trait
This is fixed now

I'm writing a simple Generator that takes a reference to an RNG, and yields values from it. This makes sense as long as the generator doesn't outlive the RNG which it references. I want to name the type of the generator with an existential type, but I can't do so unless I wrap a version of the function that uses an formulation. Here's the direct version which doesn't work and here's the more convoluted version which does and here's a playground link containing both versions, as well as a bit of scaffolding The full error message I'm seeing looks like this
I don't know if this properly counts as a compiler bug, but it feels like one because the "fix" is a very mechanical code transformation.
cc
Yea that's definitely a bug. I'll investigate where this unnamed lifetime is coming from. Maybe I'm accidentally erasing lifetimes somewhere
This is fixed in master. A more minimal example that probably still failed previously (needs to be checked) that doesn't depend on or never type:

I assumed that the following code would be legal, as it does not require indefinitely sized types, but apparently somewhere the existential type is revealed too early: () Errors:
Updated version: This still doesn't compile.
Using min-type-alias-impl-trait (), you get an error. I think this is ok, though, as it is we don't support cyclic types like this. I'm going to mark this as E-needs-test.
If we adopted a different model of impl trait, one where they were more "nominal" and hence could be cyclic, that'd be a different thing.
Change:
set ALLOW_NONZERO_RLIMIT_CORE to ignore this warning """ % (soft)) <ins> @only_on(['win32']) def check_console_code_page(): if '65001' not in subprocess.check_output(['cmd', '/c', 'chcp']): sys.stderr.write('Warning: the console output code page is not UTF-8,  some tests may fail. Use `cmd /c "chcp 65001"` to setup UTF-8 code page.n') </ins> def main(): <ins> check_console_code_page() </ins> check_rlimit_core() if __name__ == '__main__':

Discussion:
The failure happens in when the output of the command used in the test contains cyrillic letters. Changing the system locale to English (USA) or replacing with something like makes this error go away. cc
Hm interesting! This probably isn't so much connected to locales so much that something in the environment/output isn't valid UTF-8. Could you get a backtrace of this failure? I would be surprised if this was coming from , but the test looks pretty innocuous, so it may very well be coming from std!
The problem may actually reside in compiletest, it captures the output of the test and then can interpret it incorrectly. If the test is run as a standalone program outside of the test suite then no panic happens and the test works as expected. I'm still investigating. Here's the backtrace, but it's not very helpful:
Aha! It looks like . I suspect it would be fine for to just use
Change:
<ins> // Regression test for #29988 // compile-flags: -C no-prepopulate-passes // only-x86_64 // ignore-windows #[repr(C)] struct S { f1: i32, f2: i32, f3: i32, } extern { fn foo(s: S); } fn main() { let s = S { f1: 1, f2: 2, f3: 3 }; unsafe { // CHECK: load { i64, i32 }, { i64, i32 }* {{.*}}, align 4 // CHECK: call void @foo({ i64, i32 } {{.*}}) foo(s); } } </ins>

Discussion:
Given this Rust code: A call to generates IR like this on x86_64 Linux: So we have a 12 byte alloca from which we then read 16 bytes.
Isn't this subject to alignment by LLVM?
what do you mean? The alloca is only 12 bytes large. That's also the amount of bytes we write in the , but then we ask to read data for a type that is 16 bytes large. I don't see how alignment is relevant here.
here's a demo: Build without optimizations on x86_64 Linux, and you should be able to observe in the C code, although it hasn't been passed as an argument. The mismatch in the struct type definitions is deliberate to show the problem.
Reading past the end of an alloca has well-defined behavior in LLVM IR. I guess we might end up with false positives if we ever support msan.
are you implying that the generated IR is fine? If so, what is the defined behaviour / where can I read up on that? reads as if it is undefined. Without optimizations, this gives random output: With optimizations, SROA ignores the out-of-bounds read and emits a warning in debug mode, which doesn't seem like it is well-defined behaviour to me either.
Basically, if a pointer points to valid memory, and is sufficiently aligned, you can load bytes up to the alignment... LLVM itself does this at etc. That said, looking a bit more closely, the given testcase performs an "align 8" load from an "align 4" pointer, which is more problematic.
Thanks! That looks like it just assumes that the load won't trap. Part of my concern here is that we might expose additional data this way, like observing in that C code example. Though I guess optimizations might eventually leave the upper 32bits undefined and expose data anyway, so this might be moot. The alignment problem is probably due to bad usage of . Ultimately, we should load and pass the struct elements individually anyway.
This has been fixed, we now only load 12 bytes: instead of . Marking as E-needstest.
Change:
hir::ExprKind::AddrOf(hir::BorrowKind::Ref, _, ref expr), _, &ty::Ref(_, checked, _), <del> ) if { self.infcx.can_sub(self.param_env, checked, &expected).is_ok() && !is_macro } => { </del> <ins> ) if self.infcx.can_sub(self.param_env, checked, &expected).is_ok() => { </ins> // We have `&T`, check if what was expected was `T`. If so, // we may want to suggest removing a `&`. if sm.is_imported(expr.span) {

Discussion:
The tokens generated by procmacro (e.g. from ) use , which makes some suggestions produce invalid output: It's a bit tricky, because this callsite span does point into the current crate (to ), so this situaiton isn't detected in the same way as external .
Looks like should be used in more places. That one detects this span by checking if is a dummy or imported.
I'm working on a fix specifically for these typeck/borrowing suggestions. Not sure how many other suggestions have the same problem.
this is a prevalent problem. We need to add metadata to spans to distinguish call sites explicitly in an easy way and always ignore suggestions in them.
Change:
] [[package]] <del> name = "pulldown-cmark" version = "0.9.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "acd16514d1af5f7a71f909a44ef253cdb712a376d7ebc8ae4a471a9be9743548" dependencies = [ "bitflags", "memchr", "unicase", ] [[package]] </del> name = "punycode" version = "0.4.1" source = "registry+https://github.com/rust-lang/crates.io-index"

Discussion:
Nested markdown lists as below are not rendered as nested lists, but as single-level lists. Works as expected: stable (, ) beta (, ) Produces unintended output: nightly (, ) Initially reported at foo bar baz With (with stable toolchain): ! foo + bar + baz With with nightly toolchain: !
I need to confirm if it comes from rustdoc or pulldown-cmark. I'll try to fix it in the next days.
This is a regression in pulldown-cmark, I have opened
This also affects
Thanks !
A patch release of pulldown-cmark is about to be released. Could someone open a PR to update to it?
Ok, release is out.
Just opened for it.
Marking as P-high: regression that breaks relatively simple Markdown syntax
Change:
#![allow(unused_assignments, dead_code)] <del> // compile-flags: --edition=2018 -C opt-level=1 # fix in rustc_mir/monomorphize/partitioning/mod.rs </del> <ins> // compile-flags: --edition=2018 -C opt-level=1 </ins> async fn c(x: u8) -> u8 { if x == 8 {

Discussion:
I tried to generate test code coverage with this source file using and the LLVM tools. Source File: I expected to see this happen: Instead, this happened: . cargo-kcov, -Zprofile+grcov, and tarpaulin agree on 76%. In the output below lines , , were not executable but should have been executable+uncovered. Line should be executable+covered. <details<summarycoverage output</summary<p</p</details:
label: +A-code-coverage cc
Thanks for the bug report ! There was a recent bug fix (PR ) that addresses most of the missing coverage in your example (except for the last one). I just tested with and I see the expected coverage now for the first three ranges you reported seeing no coverage. These three are now showing coverage (with 0 executions) as expected: I was surprised to see no coverage for line 169, and I do see the did print, so that does seem to be a bug. So as of today, this issue is still a bug that I will need to look into further:
cc: Note, here is a snippet showing the missing coverage and code relevant to its codepath. I haven't thoroughly investigated this. I should be able to reproduce this in a simplified test (without the asynctrait and executor dependencies) that I can add to our unit tests. I don't have a theory yet. It could either be the closure's MIR is not included in coverage (seems unlikely to me), or is silently dropping coverage because it doesn't like something. (This is what was happening for the other missing coverage reported in this issue, that has since been resolved.) The test (shown at the bottom) calls and awaits the implementation of below: I do see the test output, including the from above, and from the awaited call to , below: The async closure seems to be missing coverage, as shown here. Note the wrapper function is covered and called (showing the coverage of on line 168), but there should also be coverage for the awaited implicit closure (lines 168-170, I believe). Since the program output proves this is called, the coverage should be showing execution. And the test that invokes it is covered:
Thank you. I see improvement in the latest nightly.

I minified the test case to the async issues for anyone looking at this (but it still uses executor and asynctrait.) Since this function is missing coverage too the issue isn't specific to async_trait thought.
So it turns out that the internal (auto-generated) closure actually does get coverage, but for some reason the code region for the macro, by itself, is not or not counted. I've created a draft PR with a new test and current results, demonstrating this issue. Once I figure out how to fix it, I'll submit the PR with the updated results.
Update: fixes the issue.
Change:
fn bar(_1: Bar) -> usize { debug bar => _1;                     // in scope 0 at $DIR/enum_cast.rs:+0:8: +0:11 let mut _0: usize;                   // return place in scope 0 at $DIR/enum_cast.rs:+0:21: +0:26 <del> let mut _2: isize;                   // in scope 0 at $DIR/enum_cast.rs:+1:5: +1:8 </del> <ins> let _2: Bar;                         // in scope 0 at $DIR/enum_cast.rs:+1:5: +1:8 let mut _3: isize;                   // in scope 0 at $DIR/enum_cast.rs:+1:5: +1:8 </ins> bb0: { <del> _2 = discriminant(_1);           // scope 0 at $DIR/enum_cast.rs:+1:5: +1:17 _0 = move _2 as usize (IntToInt); // scope 0 at $DIR/enum_cast.rs:+1:5: +1:17 </del> <ins> StorageLive(_2);                 // scope 0 at $DIR/enum_cast.rs:+1:5: +1:8 _2 = move _1;                    // scope 0 at $DIR/enum_cast.rs:+1:5: +1:8 _3 = discriminant(_2);           // scope 0 at $DIR/enum_cast.rs:+1:5: +1:17 _0 = move _3 as usize (IntToInt); // scope 0 at $DIR/enum_cast.rs:+1:5: +1:17 StorageDead(_2);                 // scope 0 at $DIR/enum_cast.rs:+1:16: +1:17 </ins> return;                          // scope 0 at $DIR/enum_cast.rs:+2:2: +2:2 } }

Discussion:
noticed this 1.63→1.64 change in I tried this code: I expected to see this happen: because is non-, an error about moving out from behind a reference, like happened in 1.63 , this happened: it compiles fine in 1.64 in nightly is probably cased by Change enum-int casts to not go through MIR casts which is mentioned in It's unclear to me whether this is intentional under the banner of " behaviour", since there's no trait involved.
Prioritized as P-critical in meeting just now. This needs to be fixed by 1.65 at a minimum.
labels +T-compiler This needs work from T-compiler! :)
labels -I-lang-nominated Meeting consensus is that the current behavior is wrong and needs to be fixed.