jiebi/CodeConvo huggingface dataset:
Change:
14|       | 15|       |macro_rules! on_error { 16|       |    ($value:expr, $error_message:expr) => { <del> 17|      0|        $value.or_else(|e| { 18|      0|            let message = format!($error_message, e); 19|      0|            if message.len() > 0 { 20|      0|                println!("{}", message); 21|      0|                Ok(String::from("ok")) </del> <ins> 17|       |        $value.or_else(|e| { // FIXME(85000): no coverage in closure macros 18|       |            let message = format!($error_message, e); 19|       |            if message.len() > 0 { 20|       |                println!("{}", message); 21|       |                Ok(String::from("ok")) </ins> 22|       |            } else { <del> 23|      0|                bail!("error"); </del> <ins> 23|       |                bail!("error"); </ins> 24|       |            } <del> 25|      0|        }) </del> <ins> 25|       |        }) </ins> 26|       |    }; 27|       |} 28|       |

Discussion:
I expect something that looks like the result, for a similar (non-macro) closure: But instead we get results like the following: This issue is demonstrated in the coverage results from the test: I have a new PR in progress to show more examples, and those examples expose the fact that the coverage for is actually being to the macro's source itself. Note that there were 5 macro calls with missing coverage in the corresponding test case, and the coverage report shows 5 . So all are taken into account. Nevertheless, this is a function-like macro, and it should behave like a function call, and show the coverage at the calling site.
I suspect the problem is related to how the expansion is handled for the macro body. When defined without braces, it is (likely) "de-sugared" (adding braces perhaps?) in a way that confuses the macro expansion handling in .
+A-code-coverage fyi:
I looked into this (reviewing debug logs) and the issue it not exactly a macro problem, I think. The closure tests I used all call , and that macro is defined as follows: Note the expansion starts with . That creates a closure that looks like it starts: Since the opening brace comes from the macro, the closure MIR body source starts within the macro. Generating the coverage relative to the source that contains the first character of the function body is generally reasonable, and even in this case it might be hard to argue that it's wrong. But it's probably not right either. The issue is, where should coverage be generated? If the macro is more complex, instrumenting the macro is good. If the caller (which could be another macro, by the way) is more complex, instrumenting the caller source is often better. For example, intuitively we want the coverage results of the two macros below to look similar. Putting the coverage results in the source for the macro loses a lot of coverage span detail! I'm not exactly sure what to do. I'm thinking of treating closures (at least closures that start with a macro) as a special case (at least, when coverage is enabled), and find some way of handling the body span as if it included its own block braces.
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. // Check that coercions are propagated through match and if expressions. // pretty-expanded FIXME #23616 use std::boxed::Box; pub fn main() { let _: Box<[isize]> = if true { Box::new([1, 2, 3]) } else { Box::new([1]) }; let _: Box<[isize]> = match true { true => Box::new([1, 2, 3]), false => Box::new([1]) }; // Check we don't get over-keen at propagating coercions in the case of casts. let x = if true { 42 } else { 42u8 } as u16; let x = match true { true => 42, false => 42u8 } as u16; } </ins>

Discussion:
Put (copies of?) coercematch{,calls} and related tests into run-pass-valgrind. Because our current testing infrastructure is not aggressive enough in checking that tests like this are actually behaving in a sound manner. spawned off of: (I did not attempt this in PR because I wanted to expedite landing the fix for the trans bug.)
clarified the situation to me: even if is not available on a host, the tests in will be run (just without checking them). So resolving this is probably just a matter of moving the tests over. (having said that, I am wary of the risk of injecting usage of will cause a PR to be inadvertently blocked, and thus I still want to wait to fix this until after PR lands.)
Triage: it looks like these two tests are not yet in . This should be easy to do, though which tests exactly are "related" isn't quite clear to me.
Triage: no news.
Change:
let mut total = start; for i in 0..layout.fields.count() { <ins> let field = layout.field(cx, i); if field.is_1zst() { // No data here and no impact on layout, can be ignored. // (We might be able to also ignore all aligned ZST but that's less clear.) continue; } </ins> if !is_union && total != layout.fields.offset(i) { <ins> // This field isn't just after the previous one we considered, abort. </ins> return Err(Heterogeneous); } <del> let field = layout.field(cx, i); </del> result = result.merge(field.homogeneous_aggregate(cx)?)?; // Keep track of the offset (without padding).

Discussion:
On aarch64-unknown-linux-gnu (a tier 1 target), consider this testcase: passes its argument as uses IOW, uses float registers and uses int registers. This violates our promise that types are ABI-compatible. I think this might indicate a bug in the function? At least I don't see anything in the aarch64 adjustment that would be obviously wrong.
This also affects arm32 targets like arm-unknown-linux-gnueabihf.
Yes, that is definitely the issue -- that is heterogeneous.
Should be fixed by
Change:
use rustc::mir::{NullOp, StatementKind, Statement, BasicBlock, LocalKind}; use rustc::mir::{TerminatorKind, ClearCrossCrate, SourceInfo, BinOp, ProjectionElem}; use rustc::mir::visit::{Visitor, PlaceContext}; <del> use rustc::mir::interpret::ConstEvalErr; </del> <ins> use rustc::mir::interpret::{ConstEvalErr, EvalErrorKind}; </ins> use rustc::ty::{TyCtxt, self, Instance}; use rustc::mir::interpret::{Value, Scalar, GlobalId, EvalResult}; use interpret::EvalContext;

Discussion:
inlined inside a , I get a warning: however, when I involve a variable there is no warning at all but looking at the generated code it is quite clear that this panics:
It warns on current stable, but not on beta and nightly. Might be miri fallout? cc Curiously, when you take a reference (to trigger promotion to static) you get a hard error on beta and nightly (stable is still a warning). Isn't that a regression?
triage: P-medium Still want to get those warnings, but no longer P-high
Hm, what is the status of this? The PR was merged, but with , I don't get a compiler warning for the first example. For the second one I get two though? :confused:
The PR was just for the compilation error. The missing warnings just need an impl for this branch: The warning duplication is unfortunate, but if we deduplicate it, we loose warnings in other edge cases. We could deduplicate it similar to the way the notes about where the lint level was set are deduplicated (note how the second warning has no message). That would probably be the cleanest solution.
Change:
#[inline] fn overflowing_signed_offset(&self, val: u64, i: i64) -> (u64, bool) { // We need to make sure that i fits in a machine isize. <del> let n = uabs(i); </del> <ins> let n = i.unsigned_abs(); </ins> if i >= 0 { let (val, over) = self.overflowing_offset(val, n); (val, over || i > self.machine_isize_max())

Discussion:
<!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilisation. Make sure to include the relevant RFC for the feature if it has one. Otherwise provide a short summary of the feature and link any relevant PRs or issues, and remove any sections that are not relevant to the feature. Remember to add team labels to the tracking issue. For a language team feature, this would e.g., be . Such a feature should also be labeled with e.g., . This label is used to associate issues (e.g., bugs and design questions) to the feature. --This is a tracking issue for on signed integral types. The feature gate for the issue is . Tracking issues are used to record the overall progress of implementation. They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label. <!-- Include each step required to complete the feature. Typically this is a PR implementing a feature, followed by a PR that stabilises the feature. However for larger features an implementation could be broken up into multiple PRs. --- [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide]) [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev- First implemented in <!-- Include a list of all the PRs that were involved in implementing the feature. --
Are there any outstanding issues with this feature gate? It has a trivial implementation that is unquestionably correct, and it seemed quite clear in the RFC that it was desired.
One significant issue I see is currently the implementation for returns instead of . Edit: I found the reason. The is instead of as . This was not a problem so far because didn't appear in any function signature until now. So changing the call site for all pointer sizes should be enough.
Hmm…the behavior for different widths (16, 32, or 64). However, usize and u16/32/64 are not the same type. I'll make a modification locally and open a PR shortly.
Yes, exactly. Good job with the PR!
Why of returns instead of ? IMHO, it is not valid.
This is fixed on nightly (that you need anyway to use this for now)
Nice, thank you!
Change:
<ins> // Regression test for #63952, shouldn't hang. use std::usize; #[repr(C)] #[derive(Copy, Clone)] struct SliceRepr { ptr: *const u8, len: usize, } union SliceTransmute { repr: SliceRepr, slice: &'static [u8], } // bad slice: length too big to even exist anywhere const SLICE_WAY_TOO_LONG: &[u8] = unsafe { //~ ERROR: it is undefined behavior to use this value SliceTransmute { repr: SliceRepr { ptr: &42, len: usize::MAX, }, } .slice }; fn main() {} </ins>

Discussion:
I'm sorry, I haven't reduced this at all, and I'm sure the code is awful, but the error message said you'd appreciate a bug report. I tried this code: jeremyBanks/0dmg using I expected to see this happen: my program would run, or the compiler would give one of its typical helpful error messages! Instead, this happened: I am using the Windows Linux Subsystem thing with Debian or Ubuntu, I think. : : Backtrace:
If I use cargo doc I get a different stack trace:
The crash stopped occurring in my code when I fixed an invalid import: see jeremyBanks/0dmg
I'm pretty certain this is caused by being directly indexed without being checked here: But, really, it'd be nice to have a reduced test case so we can confirm the bug is fixed afterwards.
Makes sense. I'll try to pare it down to something useful.
I'm failing to reproduce this crash without using multiple crates, so I can't figure out how to put it in a Playground example or doc test, but here's a reduced example ().
Okay, I've got the failure occurring in a compiler test at jeremyBanks/rust Result: If I understand correctly, it will be possible to turn this into a regression test by annotating it with the desired non-panic output, once this issue has been fixed and we know what the fixed output looks like. But since we're not sure what the will look like, there'd be no point trying to get this merged yet.
now that is merged and should be in the next Nightly, could you check your test-case again to see whether it's fixed? I didn't have time to add your test case before it was merged. Thanks!
I think it's fixed. My stand-alone test case produces the same initial error message of "no type-dependent def for method call", but it no longer displays any panic; it seems to exit cleanly. Using built from : Using : (Now running in a normal Debian VM. Sorry for the constantly-changing platform. :P)
Sorry! I didn't mean to submit the post yet, or close the issue, but I mis-clicked. I'm still trying to figure out the appropriate annotations to make this pass as a test.

If I get the test working behaving properly, would it be useful to send a PR to add my regression test, or is this too small of an issue to warrant one?
yes, a regression test would be useful here. Actually, I don't think the behaviour is even correct here — it shouldn't be displaying that error at all, even if it's not actually crashing.
Did a test ever get here?

Compiling this code results in: There is no backtrace. If I disable specialization feature, rustc reports an error: ` Rustc details:
This seems to compile as of the most recent nightly.
Good to hear that! Would it make sense to add this example to the test suite to prevent regressions in the future?
Change:
} impl<'cx, 'tcx> Resolver<'cx, 'tcx> { <del> crate fn new( </del> <ins> fn new( </ins> fcx: &'cx FnCtxt<'cx, 'tcx>, span: &'cx dyn Locatable, body: &'tcx hir::Body<'tcx>,

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. --Removing allows the code to compile successfully. <!-- 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 --<!-- TRIAGEBOT_END --
cc
I dont have too much context on how type folding works, but my guess is we are calling fold sooner that we should. I have this to the for RFC 2229, I'll bring it up during our sync tomorrow.
We want to use .
assign
Error: Parsing assign command in failed: ...'bot assign' ''... Please let know if you're having trouble with this bot.
claim
Thanks
Change:
<ins> error[E0631]: type mismatch in function arguments --> $DIR/issue-43623.rs:14:5 | LL |     break_me::<Type, fn(_)>; |     ^^^^^^^^^^^^^^^^^^^^^^^ |     | |     expected signature of `for<'b> fn(<Type as Trait<'b>>::Assoc) -> _` |     found signature of `fn(_) -> _` | note: required by `break_me` --> $DIR/issue-43623.rs:11:1 | LL | / pub fn break_me<T, F>(f: F) LL | | where T: for<'b> Trait<'b>, LL | |       F: for<'b> FnMut(<T as Trait<'b>>::Assoc) { LL | |     break_me::<Type, fn(_)>; LL | | LL | | LL | | } | |_^ error[E0271]: type mismatch resolving `for<'b> <fn(_) as std::ops::FnOnce<(<Type as Trait<'b>>::Assoc,)>>::Output == ()` --> $DIR/issue-43623.rs:14:5 | LL |     break_me::<Type, fn(_)>; |     ^^^^^^^^^^^^^^^^^^^^^^^ expected bound lifetime parameter 'b, found concrete lifetime | note: required by `break_me` --> $DIR/issue-43623.rs:11:1 | LL | / pub fn break_me<T, F>(f: F) LL | | where T: for<'b> Trait<'b>, LL | |       F: for<'b> FnMut(<T as Trait<'b>>::Assoc) { LL | |     break_me::<Type, fn(_)>; LL | | LL | | LL | | } | |_^ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0271`. </ins>

Discussion:
The compiler ices with error "Failed to unify obligation" when I try to compile the following code: I get the following error: : Backtrace:
Another version:
triage: p-medium
minimal version Note that if you pass in the closure to it doesn't ICE the compiler when I used , bud did ICE the compiler when I used /. i.e.
none of the programs provided seem to ICE with the latest nightly.
Change:
} } <ins> #[stable(feature = "vec_as_mut", since = "1.5.0")] impl<T> AsMut<[T]> for Vec<T> { fn as_mut(&mut self) -> &mut [T] { self } } </ins> #[stable(feature = "rust1", since = "1.0.0")] impl<'a, T: Clone> From<&'a [T]> for Vec<T> { #[cfg(not(test))]

Discussion:
In I have this trait like this: I'd like to switch the bound on to be , but then I can no longer use a bare for , because there is currently no . It seems to me that such an impl ought to exist, especially because already exists.
Yes, and .
Since it landed now, it should appear first in Rust 1.5 (and will be stable).
Thank you!
Change:
<del> warning: unknown lint: `unnameable_types` --> $DIR/feature-gate-type_privacy_lints.rs:3:1 | LL | #![warn(unnameable_types)] | ^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: the `unnameable_types` lint is unstable = note: see issue #48054 <https://github.com/rust-lang/rust/issues/48054> for more information = help: add `#![feature(type_privacy_lints)]` to the crate attributes to enable = note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date = note: `#[warn(unknown_lints)]` on by default warning: 1 warning emitted </del>

Discussion:
This is a tracking issue for the RFC "Type privacy and private-in-public lints " (rust-lang/rfcs). Steps: [ ] Implement the RFC (cc ) [ ] Adjust documentation ([see instructions on forge][doc-guide]) [ ] Stabilization PR ([see instructions on forge][stabilization-guide]) [stabilization-guide]: [doc-guide]: Unresolved questions: [ ] It's not fully clear if the restriction for associated type definitions required for type privacy soundness, or it's just a workaround for a technical difficulty. [ ] Interactions between macros 2.0 and the notions of reachability / effective visibility used for the lints are unclear. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Oops - I didn't mean for that to un-assign you. Is there a way to prevent these lints from becoming insta-stable? Would it make sense to put them behind a feature gate?
Perhaps we could only fire the lints if an unstable compiler flag (maybe ) is passed? This would still make the lint names insta-stable, though.
in core ffi There is a fixme about , how to fixes that?
By implementing this RFC, I guess. Until that workarounds like this sealed trait will need to be used.
Where is the impl, the RFC is already accepted...
An RFC being accepted just means the feature can be implemented, not that it has been implemented. It doesn't even mean that implementing it is a priority. I believe there has been more discussion of this RFC over at as well as other issues that I can't seem to track down right now.
Hello! I know y'all are busy, but I'm curious if there's an update, particularly on for Voldemort Types - which I'd love to see. I was actually a bit surprised to find that it wasn't included in the existing lint. Appreciate the work that y'all are doing, especially who seems to have put in a lot of legwork.
The tentative plan is that will work on this in March-May.
Cool! Good luck! I'm happy to be a guinea pig to try it out or do code review if that would be helpful.
This issue should be closed by Two follow up issues about improving the effective visibility tables
Change:
}; let last_expr_ty = self.node_ty(last_expr.hir_id); let needs_box = match (last_expr_ty.kind(), expected_ty.kind()) { <ins> (ty::Opaque(last_def_id, _), ty::Opaque(exp_def_id, _)) if last_def_id == exp_def_id => { StatementAsExpression::CorrectType } </ins> (ty::Opaque(last_def_id, last_bounds), ty::Opaque(exp_def_id, exp_bounds)) => { debug!( "both opaque, likely future {:?} {:?} {:?} {:?}", last_def_id, last_bounds, exp_def_id, exp_bounds ); <del> let last_hir_id = self.tcx.hir().local_def_id_to_hir_id(last_def_id.expect_local()); let exp_hir_id = self.tcx.hir().local_def_id_to_hir_id(exp_def_id.expect_local()); </del> <ins> let (last_local_id, exp_local_id) = match (last_def_id.as_local(), exp_def_id.as_local()) { (Some(last_hir_id), Some(exp_hir_id)) => (last_hir_id, exp_hir_id), (_, _) => return None, }; let last_hir_id = self.tcx.hir().local_def_id_to_hir_id(last_local_id); let exp_hir_id = self.tcx.hir().local_def_id_to_hir_id(exp_local_id); </ins> match ( &self.tcx.hir().expect_item(last_hir_id).kind, &self.tcx.hir().expect_item(exp_hir_id).kind,

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. --The code is based on this example and the following : (commit ) <!-- 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. --It fails on stable and nightly: : $ rustc --version --verbose rustc 1.49.0 ( 2020-12-29) binary: rustc commit-hash: commit-date: 2020-12-29 host: x8664-unknown-linux-gnu release: 1.49.0 and rustc 1.51.0-nightly ( 2021-01-30) binary: rustc commit-hash: commit-date: 2021-01-30 host: x8664-unknown-linux-gnu release: 1.51.0-nightly LLVM version: 11.0.1 From stable, non verbose: <!-- 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 --
This looks like an incremental compilation ICE. Does it disappear after running ?
I can't reproduce the ICE, so it does look like an incremental bug
It does. I have cloned that repo, modified the file as in the git diff above and run fresh too.
<details<p</p</details
Sorry I had misread. No, it does not. Sorry for the confusion
Thanks for the report! I can reproduce with:
This is caused by: There is no guarantee that either or is actually local.
I've never committed to this repository; if you want to guide me to fix this issue, I'm happy to do it. If it's better if you do it, no worries
Assigning as discussed as part of the and removing .
claim
Change:
assert_eq!(v, box 2i); } assert!(called); <del> m.insert(2, box 1i); </del> <ins> } #[test] fn test_drain_iterator() { let mut map = VecMap::new(); map.insert(1, "a"); map.insert(3, "c"); map.insert(2, "b"); let vec: Vec<(usize, &str)> = map.drain().collect(); assert_eq!(vec, vec![(1, "a"), (2, "b"), (3, "c")]); assert_eq!(map.len(), 0); </ins> } #[test]

Discussion:
cc I'm in the process of -ifying the collections, and I've discovered that the takes a instead of the convention of consuming the value. It's also marked stable, even though the type itself is marked unstable. Should this instead be a candidate for the method discussed in the collection reform trait?
Yeah this is just a mistake. Feel free to fix it to match conventions.
Just to be clear, the solution to this is to make consume the value and introduce a function (and iterator). Is this right or am I missing something?
Yep!
Change:
scope: region::CodeExtent, depth: uint) { <del> let origin = |&:| infer::SubregionOrigin::SafeDestructor(span); </del> <ins> let origin = || infer::SubregionOrigin::SafeDestructor(span); </ins> let mut walker = ty_root.walk(); let opt_phantom_data_def_id = rcx.tcx().lang_items.phantom_data();

Discussion:
and are obsolete, but is not.
I think I spotted the problem, testing...
Fix in