jiebi/CodeConvo huggingface dataset:
Change:
} } <ins> impl From<c::DWORD> for ExitStatus { fn from(u: c::DWORD) -> ExitStatus { ExitStatus(u) } } </ins> impl fmt::Display for ExitStatus { fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { write!(f, "exit code: {}", self.0)

Discussion:
Because has a private field it is impossible to create one in user code, one must actually execute a process. This prevents testing/mocking. My use case is that I have some function which runs a process and generates data, however, for testing I want to mock the test run and just return a success exit status and some data. I can't do that because I can't create my own objects. At the least there should be a way to create a success . Preferably, there would be a way to create various fail statuses too.
Should the constructor just take an ?
I've also wanted a basically "raw constructor" in the past. I'd be fine adding some extensions which allow construction from a or ( and )
+1 I’d like to extend , but I cannot reuse for return value because I can’t construct . :(
I've opened a PR for this over at
Great, thanks! :+1:
This would help n00bs like me who start out by copying the example code and tweaking it: This example is a special case that only happens to work if the contains a or something else that immediately exits. Otherwise you need to create your own struct to return which is currently impossible.
This issue is now entering a cycle-long final comment period for stabilization
Discussed recently, the libs team decided to stabilize.
Change:
}); if is_windows { windows } else { other } } <ins> pub fn dir_is_empty(dir: &Path) -> bool { t!(std::fs::read_dir(dir)).next().is_none() } </ins>

Discussion:
This might not be a valid request (I have to tell it what to test), but surely it shouldn't just result in such an obscure panic. Cc
you don't have dir ?
it doesn't exists until fetching the submodule
Seems like I don't have that submodule checked out; I don't work on the book so it's not needed (and I keep the checked-out submodules to a minimum to avoid having to update them all the time).
I reproduced it in local, without in and don't update submodule manually, will fail like this.
I can fix it tomorrow, feel free to work on it if you want to fix it earlier.
by the way, do you know why we use those for here?
Not particularly, I am not so familiar with the compiletest code. Probably we panic there so the compiletest runner process can handle(being able to understand compiletest was failed) that.
The fix shouldn't make any changes on the compiletest side. We just need to avoid using submodules(if doesn't exists) instead of assuming that they exist.
Yes, that's another issue, I just met it today.
Change:
vec[ast.ty_param] ty_params, def_id id, ann a) -> @item)              fold_item_obj, <ins> // View Item folds. (fn(&ENV e, &span sp, ident ident, vec[@meta_item] meta_items, def_id id) -> @view_item)                fold_view_item_use, (fn(&ENV e, &span sp, vec[ident] idents, def_id id) -> @view_item)                fold_view_item_import, </ins> // Additional nodes. (fn(&ENV e, &span sp, &ast.block_) -> block)                   fold_block,

Discussion:
I was trying to build the stdlibs for the target like this: However, the build fails with the following error: Here is the full build log: I'm using Xubuntu 15.10. At the time of building, the Rust master was at .
Unfortunately is a which means that we don't guarantee that it builds in-tree right now. Patches are certainly welcome to fix this, however! We tend to not keep issues tracking build support for all Tier 3 platforms, however, so I'm going to close this. If you're interested in promoting this to at least tier 2 you could also help modify out to be able to support this target!
Change:
<ins> // check-pass #![feature(trait_alias)] trait SomeTrait { fn map(&self) {} } impl<T> SomeTrait for Option<T> {} trait SomeAlias = SomeTrait; fn main() { let x = Some(123); // This should resolve to the trait impl for Option Option::map(x, |z| z); // This should resolve to the trait impl for SomeTrait SomeTrait::map(&x); } </ins>

Discussion:
When a trait alias to a trait with a method with the same name as a method on a struct is in scope, rustc is suddenly unable to disambiguate the trait method from the struct method.
cc
cc and -- Is importing the trait with higher priority than inherent items?
Is importing the trait with higher priority than inherent items? It shouldn't do that, looks like a bug. A method introduced into scope via trait alias (import) should behave identically to methods introduced with a trait (import), that means lower priority than inherent items.
Change:
PreferMutLvalue); } ast::ExprUnary(ast::UnDeref, ref base_expr) => { <del> check::try_overloaded_deref( self.fcx, expr.span, Some(MethodCall::expr(expr.id)), Some(&**base_expr), self.fcx.expr_ty(&**base_expr), PreferMutLvalue); </del> <ins> // if this is an overloaded deref, then re-evaluate with // a preference for mut let method_call = MethodCall::expr(expr.id); if self.fcx.inh.method_map.borrow().contains_key(&method_call) { check::try_overloaded_deref( self.fcx, expr.span, Some(method_call), Some(&**base_expr), self.fcx.expr_ty(&**base_expr), PreferMutLvalue); } </ins> } _ => {} }

Discussion:
As titled. Add the following trait implementations: This allows generic code that accepts smart pointer can take references too, e.g.
cc
yes I want this :+1:
This would also allow code to be polymorphic over &T and &mut T by accepting . A huge win imho.
The branch creates some .
Change:
} _ => unreachable!(), }; <ins> if traitless_qself { let span = item.span; self.cx.dcx().emit_err(GlobDelegationTraitlessQpath { span }); return Default::default(); } </ins> return self.collect_glob_delegation(item, Node::KIND).make_ast::<Node>(); };

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'internal error: entered unreachable code'', 'thread 'rustc' panicked at 'internal error: entered unreachable code'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [resolverforloweringraw] getting the resolver for lowering -- label +F-fndelegation
^_^
Fixed in
Change:
<ins> #![allow(warnings)] fn issue_117846_repro() { let (a, _) = if true { produce() } else { (Vec::new(), &[]) //~ ERROR E0308 }; accept(&a); } struct Foo; struct Bar; fn produce() -> (Vec<Foo>, &'static [Bar]) { todo!() } fn accept(c: &[Foo]) {} fn main() {} </ins>

Discussion:
It's underlining the wrong argument. No response No response
I'm getting an entirely different and much more helpful error:
Are you sure you minimized the code correctly? Not sure how to repro the example you shared,
Arf, sorry about that... Also important to note, I'm using: I pushed the code with this issue . However it requires a mac to enter this code. Just running is enough to trigger it.
This should be re-minimized by someone who has a Mac then. label +E-needs-mcve
Minimization: Note that: in all cases (including when I ran the original code), there is now a more sensible type error, and the unsized local error is not actually pointing at the wrong thing, it's talking about the type of the part of the tuple unrelated to the if/else type mismatch. It seems like the type mismatch is causing the compiler to fail to properly perform the deref coercion of the , even though it's not the part of the tuple that has the type mismatch. Tested on versions:
label -E-needs-mcve
Change:
//! Performs various peephole optimizations. <ins> use crate::simplify::combine_duplicate_switch_targets; </ins> use crate::MirPass; use rustc_hir::Mutability; <del> use rustc_middle::mir::{ BinOp, Body, CastKind, Constant, ConstantKind, LocalDecls, Operand, Place, ProjectionElem, Rvalue, SourceInfo, Statement, StatementKind, SwitchTargets, Terminator, TerminatorKind, UnOp, }; </del> <ins> use rustc_middle::mir::*; </ins> use rustc_middle::ty::layout::ValidityRequirement; use rustc_middle::ty::util::IntTypeExt; use rustc_middle::ty::{self, ParamEnv, SubstsRef, Ty, TyCtxt};

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: no branch instructions emitted, makes an assumption that is , so should be inlined and optimized as a panic. Instead, this happened: there is a discriminant check still emitted. <!-- Provide the most recent version this worked on, for example: It most recently worked on: --It most recently worked on: nightly-2023-03-26 <!-- Provide the version you are using that has the regression. --See godbolt: Regression occurred in (cc searched nightlies: from nightly-2023-03-01 to nightly-2023-04-01 regressed nightly: nightly-2023-03-27 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: aarch64-unknown-linux-gnu Reproduce with: </details<details</summary(if you want to test on replace with ) </details<details</summary</details originally noticed the problem and opened , then suggested that this is a compiler issue, then that this is a regression, then bisected and opened this issue.
The end of this regression window is over 2 weeks from now. Why? Godbolt usually has pretty old nightlies. If I add : you can see we have duplicate switch targets, which means that either this commit is broken or godbolt doesn't have it:
godbolt seems to have ?
Because I knew that reproduces the regression, and wanted to cut some time bisecting. For reference I can reproduce the same issue with . <details<summary+nightly-2023-04-19 --emit=mir</summary</details
To be clear, separate from this issue I believe that this MIR: is a bug. I do not know what impact resolving that would have on this issue. But the helper that combines switch targets was (notionally) supposed to prevent this.
Yeah, I'm pretty sure that is the root cause.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
} fn enter_default<'r>(bcx: @mut Block, <del> dm: DefMap, m: &[Match<'r>], col: uint, val: ValueRef) </del> <ins> dm: DefMap, m: &[Match<'r>], col: uint, val: ValueRef, chk: Option<mk_fail>) </ins> -> ~[Match<'r>] { debug!("enter_default(bcx=%s, m=%s, col=%u, val=%s)", bcx.to_str(),

Discussion:
This should print , but prints . The problem seems to be the pattern, since if this is replaced by aokok_` is not important.)
Confirmed. Bugs where we actually generate the wrong code are pretty bad, so fixing this is probably decently high priority. Not sure it actually fits for a milestone, though?
OK, I've figured out what is going on. The problem is that the matcher is too strict when deciding what patterns are included in some condition. Essentially the problem is that it decides that the condition that are relevant are "length 1" and "length 0" and decides that [2, .. ] is the only pattern that matches "length 1", which is obviously bogus. Fixing this seems a bit tricky, since we need to be able to properly expand out the patterns while still properly handling bindings. Note that this seems like a degenerate case, since the last pattern could just be replaced with a , but there are more complicated and interesting things where this happens too.
Oh, no, there is a pretty simple solution to this. The trick is, when checking submatches generated by a vector length check, set it up so that if none of the subpatterns match, it goes to the next vector length check. I'm explaining it poorly, but it is a really simple fix.
Simple fix has problems, though. So have a more complex fix. Which also has problems. Still investigating.
OK, have it all fixed. Just trying to document it well at this point.
Change:
// Swap the found pair of out-of-order elements. r -= 1; <del> ptr::swap(v.get_unchecked_mut(l), v.get_unchecked_mut(r)); </del> <ins> let ptr = v.as_mut_ptr(); ptr::swap(ptr.add(l), ptr.add(r)); </ins> l += 1; } }

Discussion:
Similar to I tried this code: I expected to see this happen: Miri does not detect UB Instead, this happened: Miri detects UB (experimentally) <!-- 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<summaryBacktrace</summary<p</p</details
cc
FWIW, I have now detected this bug through the tests in and .
Looks like the problem is in this line: re-borrows an on the entire slice, thus invalidation previously created pointers. So this is yet another instance of
Actually, just to be sure, are we interested in patching out all such instances of this in std/alloc/core? I know I personally would like the standard library to be clean against Miri with so that I can check libraries for stacked borrows issues. I just did a quick skim now that I understand the rules and I think I can spot a few other issues, so I'm not sure if these were deliberately left in, or if I'm just the first person to be looking this carefully.
So far we fixed various issues of this sort that people noticed, but there was never a concerted effort to find all of them. So they were not deliberately left in, just not found yet. Whether we want to fix them all is up to who ultimately decide about the std library implementation.
So far the fixes have been localized enough that it's been easy to take them (eg ). If anything comes up that requires drastic changes to fix then there might be a conversation about it, but for simple ones that don't increase maintenance burden I think they'll be happily accepted.
Change:
<ins> // run-pass #![feature(decl_macro)] pub fn moo() { pub macro ABC() {{}} } fn main() {} </ins>

Discussion:
Seems to be something to do with Rocket. Having a on the internal function is causing the compiler to blow up. Version: Stack trace:
I think this issue might be better-suited for the Rocket repository.
Ah OK. The output told me to file an issue here so I thought it might be a compiler problem rather than something specific to Rocket. Can we leave it open for a bit just until it's confirmed as Rocket-specific?
Hm, this bug probably originates with interesting codegen in Rocket, but is likely a bug in rustc in the end. I would keep it here, though letting Rocket know about it might not be a bad idea.
I'm going to label this as P-high for now since it affects Rocket. cc re. macros & privacy.
Without looking too deeply I would wager that we're getting a here, although it could be any other which would be worrisome:
Would be great to have a reproducer that did not depend on Rocket and codegen, if it is possible.
Trying to get a simple reproducible example and am unable to :( It got a little time-consuming and I really need to get work done so have worked around it for now. I could possibly publish everything in a repo, but it would still be rocket + codegen and not a very simple example!
Latest nightly (2019-08-11) still panics, but with different error message:
Also as a sidenote: Rocket master does not ICE anymore. The ICE "was fixed" by so it may be a problem with decl_macro ?
I would still wan't not to ICE on the face of malformed input.
For future reference, when panicking or using for not finding what you expect it is a good idea to include in the message what the found value was. :)
I think you got me wrong. I haven't said, that this should be closed because upstream code has changed, but I said, that upstream does not ICE anymore, so I looked into it, what caused it to not ICE anymore.

I try to go that ;) Confirmed, that it is related to decl maros modify labels: +A-macros-2.0
I need your help with the tags here please ^^
<details<summaryBacktraces</summary<details<summary60960a260</summary</details<details<summarydddb7fca0</summary</details</details modify labels: -E-needs-mcve
What is the appropriate visibility scope for ? is failing because we get the following instead: In my mind the expected semantics of this could would be to scope to inside , but currently with a macro by example it would be scoped to the current module. I can implement either semantic. Edit: I'm talking out of my ass, matches my intuition. Don't know why I thought otherwise.
Change:
Span {lo: lo, hi: hi, expn_info: None} } <ins> /// Return the span itself if it doesn't come from a macro expansion, /// otherwise return the call site span up to the `enclosing_sp` by /// following the `expn_info` chain. pub fn original_sp(sp: Span, enclosing_sp: Span) -> Span { match (sp.expn_info, enclosing_sp.expn_info) { (None, _) => sp, (Some(expn1), Some(expn2)) if expn1.call_site == expn2.call_site => sp, (Some(expn1), _) => original_sp(expn1.call_site, enclosing_sp), } } </ins> /// A source code location used for error reporting pub struct Loc { /// Information about the original source

Discussion:
Code: Compilation attempt: It should be pointing at the semi-colon on the next line, not the comma on this line.
The note message was introduced in . It doesn't seem to handle this situation properly.
Change:
})); let their_thread = my_thread.clone(); <del> let my_packet: Arc<Packet<'scope, T>> = Arc::new(Packet { scope: scope_data, result: UnsafeCell::new(None) }); </del> <ins> let my_packet: Arc<Packet<'scope, T>> = Arc::new(Packet { scope: scope_data, result: UnsafeCell::new(None), _marker: PhantomData, }); </ins> let their_packet = my_packet.clone(); let output_capture = crate::io::set_output_capture(None);

Discussion:
The following code sometimes causes a data race to be reported by Miri: Miri reports: The deallocation occurs when returns and its local variable gets deallocated. The read occurs here (I am fairly sure): This reads the contents of the field after the . But the moment the is done, the memory backing might be deallocated. That makes the read a potential use-after-free, and a race with the deallocation. Cc
The following patch fixes this: However, even with this patch, we still run into a problem like the gets deallocated while still runs. This is still UB even after my proposed because contains a field that is not inside an (the field). So that part of what points to is expected to stay live for the entire duration of the function call. Another alternative might be to put the entire into an rather than allocating it on the stack frame of .
Going to attach this to the 1.63 milestone, since this is in a newly stabilized feature -- we may wish to back out stabilization for a cycle or backport fixes.
Re-opening for beta backport.
The fix was backported in .
Change:
<ins> // Ensure inout asm! operands are marked as used by the liveness pass // only-x86_64 // check-pass #![feature(asm)] #![allow(dead_code)] #![warn(unused_assignments)] #![warn(unused_variables)] // Test the single inout case unsafe fn f1(mut src: *const u8) { asm!("/*{0}*/", inout(reg) src); //~ WARN value assigned to `src` is never read } unsafe fn f2(mut src: *const u8) -> *const u8 { asm!("/*{0}*/", inout(reg) src); src } // Test the split inout case unsafe fn f3(mut src: *const u8) { asm!("/*{0}*/", inout(reg) src => src); //~ WARN value assigned to `src` is never read } unsafe fn f4(mut src: *const u8) -> *const u8 { asm!("/*{0}*/", inout(reg) src => src); src } // Tests the use of field projections struct S { field: *mut u8, } unsafe fn f5(src: &mut S) { asm!("/*{0}*/", inout(reg) src.field); } unsafe fn f6(src: &mut S) { asm!("/*{0}*/", inout(reg) src.field => src.field); } fn main() {} </ins>

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. --I tried this code: I expected to see this happen: Compiler doesn't generate any warnings Instead, this happened: Rustc says that is unused, even though it is declared as in asm. Adding arrows () fixes it <!-- 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Interesting bug! I used to determine that this bug has been around . and doing some debugging, I found that for all live nodes in , is never marked as being used in the RWU table. It only gets marked as read/written. , this is part of the information used to determine that is unused. That doesn't really make much sense though- does seem to fit the case where a variable is used as both an input and an output to some arbitrary assembly instruction. I'll go ahead and claim this. I have a solution in mind, just going to ask around zulip first before putting out a PR. claim
Change:
<del> // 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; } </del>

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:
} _ => intravisit::walk_expr(self, expr), } <ins> ExprKind::Path(qpath) => { let res = self.fcx.tables.borrow().qpath_res(qpath, expr.hir_id); if let Res::Def(DefKind::Static, def_id) = res { // Statics are lowered to temporary references or // pointers in MIR, so record that type. let ptr_ty = self.fcx.tcx.static_ptr_ty(def_id); self.record(ptr_ty, scope, Some(expr), expr.span); } } </ins> _ => intravisit::walk_expr(self, expr), } self.expr_count += 1; <del> let scope = self.region_scope_tree.temporary_scope(expr.hir_id.local_id); </del> // If there are adjustments, then record the final type -- // this is the actual value that is being produced. if let Some(adjusted_ty) = self.fcx.tables.borrow().expr_ty_adjusted_opt(expr) {

Discussion:
I have some code which asynchronously computes an integer, and selects an item from a static slice in the same expression. This used to work (it does on stable), but after a nightly update the compiler ICEs when computing generator layout. The bug stops reproducing if I change the static to a local variable, or extract the index into a separate variable. rustc 1.41.0-nightly ( 2019-11-23) binary: rustc commit-hash: commit-date: 2019-11-23 host: x86_64-unknown-linux-gnu release: 1.41.0-nightly LLVM version: 9.0
De-nominating from compiler team as we have a fix pending.
triage: P-high.