jiebi/CodeConvo huggingface dataset:
Change:
<del> // run-pass // ignore-windows - this is a unix-specific test // ignore-emscripten no processes // ignore-sgx no processes use std::os::unix::process::CommandExt; use std::process::Command; fn main() { let mut command = Command::new("some-boring-name"); assert_eq!(format!("{:?}", command), r#""some-boring-name""#); command.args(&["1", "2", "3"]); assert_eq!(format!("{:?}", command), r#""some-boring-name" "1" "2" "3""#); command.arg0("exciting-name"); assert_eq!(format!("{:?}", command), r#"["some-boring-name"] "exciting-name" "1" "2" "3""#); } </del>

Discussion:
currently only outputs the program and it's arguments. It should also output the environment variables and the current path, as set by , and . This would help with figuring out what's going on :-)
We also currently have no way to extract most of this information without utilizing Debug, so out of tree implementations can't be implemented.
Would/should this be the specific additions to the environment set by , or the actual environment? The most straightforward implementation of this (debug-printing the individual fields of the internal struct) seems to do the latter. That is, this patch (in )— results in program behavior like this (scroll right to see the very bulky output; should be verbose, but how verbose is too verbose??):
I'd be fine with the verbose output. The debug output is only meant for debug purposes and generating the full environment saves us from oh-that's-why-it's-not-working-this-stupid-thing moments
Seems reasonable. I would be ready to consider a PR implementing this.
Triage: no changes here. I've actually wanted this too, but don't have the bandwidth to work on it, personally.
Change:
let field_index = field.index(); let field = base_layout.field(self, field_index)?; if field.size.bytes() == 0 { <del> return Ok(Some((Value::Scalar(Scalar::undef()), field.ty))) </del> <ins> return Ok(ValTy { value: Value::Scalar(Scalar::undef()), ty: field.ty, }); </ins> } let offset = base_layout.fields.offset(field_index); <del> match base { </del> <ins> let value = match base { </ins> // the field covers the entire type Value::ScalarPair(..) | <del> Value::Scalar(_) if offset.bytes() == 0 && field.size == base_layout.size => Ok(Some((base, field.ty))), // split fat pointers, 2 element tuples, ... Value::ScalarPair(a, b) if base_layout.fields.count() == 2 => { let val = [a, b][field_index]; Ok(Some((Value::Scalar(val), field.ty))) </del> <ins> Value::Scalar(_) if offset.bytes() == 0 && field.size == base_layout.size => base, // extract fields from types with `ScalarPair` ABI Value::ScalarPair(a, b) => { let val = if offset.bytes() == 0 { a } else { b }; Value::Scalar(val) </ins> }, <del> // FIXME(oli-obk): figure out whether we should be calling `try_read_value` here _ => Ok(None), } </del> <ins> Value::ByRef(base_ptr, align) => { let offset = base_layout.fields.offset(field_index); let ptr = base_ptr.ptr_offset(offset, self)?; let align = align.min(base_layout.align).min(field.align); assert!(!field.is_unsized()); Value::ByRef(ptr, align) }, Value::Scalar(val) => bug!("field access on non aggregate {:?}, {:?}", val, base_ty), }; Ok(ValTy { value, ty: field.ty, }) </ins> } fn try_read_place_projection(

Discussion:
I saw that was closed when was merged so I thought it would fix the same error on my own code as well however as of nightly: it still happens. Code: Playground: From what I can tell its an alignment issue because changing id from a to a fixes the issue.
Change:
<ins> // Regression test for #75118. use std::ptr::NonNull; pub const fn dangling_slice<T>() -> NonNull<[T]> { NonNull::<[T; 0]>::dangling() //~^ ERROR: unsizing casts are only allowed for references right now } fn main() {} </ins>

Discussion:
: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Is it a regression from stable to beta if it doesn't compile on stable? I this to the original comment: On rust stable 1.45.1, it causes this compilation error instead:
Yes, the error message regressed. I don't know if the code is supposed to compile on beta or if it should still fail with the same error, but an ICE is a regression either way.
I think the failure is introduced in and this unwrap causes it: So, my thought is we shouldn't unwrap here and return instead if it's . is this correct?
Yes, return an error mentioning that unsizing is only allowed for references right now.
Change:
result.flags } <ins> pub fn bound_var_flags(vars: &ty::List<ty::BoundVariableKind>) -> FlagComputation { let mut computation = FlagComputation::new(); for bv in vars { match bv { ty::BoundVariableKind::Ty(_) => { computation.flags |= TypeFlags::HAS_TY_LATE_BOUND; } ty::BoundVariableKind::Region(_) => { computation.flags |= TypeFlags::HAS_RE_LATE_BOUND; } ty::BoundVariableKind::Const => { computation.flags |= TypeFlags::HAS_CT_LATE_BOUND; } } } computation } </ins> fn add_flags(&mut self, flags: TypeFlags) { self.flags = self.flags | flags; }

Discussion:
: The bug seems to be present in the latest nightly at well as stable. <details<summary<strongBacktrace</strong</summary<p</p</details
It seems like this has something to do with appearing multiple times, once in 's bound, then again in 's. Switching the order of the two bounds seems to avoid the error.
Regression in nightly-2021-07-25 commit[0] 2021-07-23: Auto merge of - JohnTitor:rollup-dht22jk, r=JohnTitor commit[1] 2021-07-23: Auto merge of - JohnTitor:get-by-key-enum-part-2, r=oli-obk commit[2] 2021-07-24: Auto merge of - SparrowLii:MaybeTrait, r=wesleywiser commit[3] 2021-07-24: Auto merge of - Mark-Simulacrum:bump-version, r=Mark-Simulacrum commit[4] 2021-07-24: Auto merge of - In-line:zircon-thread-name, r=JohnTitor commit[5] 2021-07-24: Auto merge of - crlf0710:rich_vtable, r=nikomatsakis commit[6] 2021-07-24: Auto merge of - Aaron1011:inert-warn, r=petrochenkov commit[7] 2021-07-24: Auto merge of - Manishearth:rollup-b09njin, r=Manishearth commit[8] 2021-07-24: Auto merge of - BoxyUwU:cgd-subst-ice, r=nikomatsakis
Change:
/// let b2: Result<Ref<u32>, _> = Ref::filter_map(b1, |v| v.get(1)); /// assert_eq!(*b2.unwrap(), 2); /// ``` <del> #[unstable(feature = "cell_filter_map", reason = "recently added", issue = "81061")] </del> <ins> #[stable(feature = "cell_filter_map", since = "1.63.0")] </ins> #[inline] pub fn filter_map<U: ?Sized, F>(orig: Ref<'b, T>, f: F) -> Result<Ref<'b, U>, Self> where

Discussion:
Feature gate: This is a tracking issue for and , which lets you optionally project data inside a or , wrapped in a or . If the projection returns then these methods return a so that you can still get the original or back out. [x] Implementation: [x] Final commenting period (FCP) [ ] Stabilization PRNaming and signature: We wanted to call this method and accept a closure like , but that's not sound with bound lifetimes. This method is only ok when the mapping closure uses HRTB. So we opted to call it instead, with the closure returning a .
I am in need of this API for my library in order to be able to have an efficient implementation that avoids unsafe Rust code. I wonder, why is the goal to have instead of since I can see a great value in having both APIs available. So if is already good to go we could stabilize that one and later add as soon as all open questions for it are resolved.
The name seems unusual for something that returns a - for example, returns an iterator with filtering built in. The equivalent method already exists in the Mutex implementations of , under the name . In both cases the closure it accepts returns and not the more general . So maybe the name should be reconsidered in that light.
I'm also interested in the stabilization of this API for the same reason as However, I also agree that should be named since it returns a . As an API user it makes more sense to me.
I wonder if we can have a generic filter & map for any inner enum instead of just Option. For example in this code As the code show, ref is compared twice to get the result. Is there any way to make it simpler?
fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [x] [ ] [x] [x] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the .

:bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon.
Change:
<ins> // Regression test for issue #98833. // compile-flags: -Zinline-mir fn main() { println!("{}", live::<false>()); } #[inline] fn live<const B: bool>() -> u32 { if B { dead() } else { 0 } } #[inline] fn dead() -> u32 { 42 } </ins>

Discussion:
This can be seen here: To reproduce:
Last passing run was so this regressed between 2022-06-30 and 2022-07-02.
Minimized a reproducer. : : Execution:
label regression-untriaged
Bisection says searched nightlies: from nightly-2022-06-29 to nightly-2022-07-03 regressed nightly: nightly-2022-07-03 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsSo,
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Unfortunately while this fixes the minimal reproducer, it doesn't fix the full case. Would you prefer I file a new bug, or should this one be re-opened? To reproduce:
It's not very minimized, but slightly better. : : Empty
searched nightlies: from nightly-2022-07-07 to nightly-2022-07-22 regressed nightly: nightly-2022-07-09 searched commits: from to regressed commit:
Interesting, I had assumed based on the matching panic message that it'd have the same regressing commit.
Happy to report that with the latest nightly we're back to green on nightly. Thanks much
Thanks the first fix was enough for Suricata :-)
Thanks so much, pydantic-core has been pinned to but is not back on nightly.
Change:
/// Test whether this file type represents a symbolic link. /// <ins> /// The underlying [`Metadata`] struct needs to be retrieved /// with the [`fs::symlink_metadata`] function and not the /// [`fs::metadata`] function. The [`fs::metadata`] function /// follows symbolic links, so [`is_symlink`] would always /// return false for the target file. /// /// [`Metadata`]: struct.Metadata.html /// [`fs::metadata`]: fn.metadata.html /// [`fs::symlink_metadata`]: fn.symlink_metadata.html /// [`is_symlink`]: struct.FileType.html#method.is_symlink /// </ins> /// # Examples /// /// ``` /// # fn foo() -> std::io::Result<()> { /// use std::fs; /// <del> /// let metadata = try!(fs::metadata("foo.txt")); </del> <ins> /// let metadata = try!(fs::symlink_metadata("foo.txt")); </ins> /// let file_type = metadata.file_type(); /// /// assert_eq!(file_type.is_symlink(), false);

Discussion:
It's always false.
I'm on Linux Mint, the kernel version is
The file system is ext4
Duplicate of ; not a bug. EDIT: Or rather, is a documentation bug.
Update the docs for to note that a common source of confusion is to call this on the result of not .
Hi. I'm new to rust, and have been looking through the E-easy tagged bugs for one it would be easy to start with. (Thank you very much for making easy bugs available as on-ramps, it is very very much appreciated.) I think the appropriate change is in in the documentation for issymlink(). Adding a second line to the description warning that you should use symlinkmetadata by default, and changing the example to use fs::symlink_metadata() not fs::metadata(). I have made and tested that change locally. Does that sound right?
Yes. I would suggest just submitting a PR. Reviewing (commenting on) code directly both spares you the effort describing the changes and us from parsing the description.
I believe this one is done?
Assuming I'm right, yes, I think my commit fixed this particular issue, did everything suggested, and is now merged safely to master.
Addressed by in . Thanks again!
Change:
<ins> warning: trait method `try_into` will become ambiguous in Rust 2021 --> $DIR/future-prelude-collision-turbofish.rs:19:5 | LL |     x.try_into::<usize>().or(Err("foo"))?.checked_sub(1); |     ^^^^^^^^^^^^^^^^^^^^^ help: disambiguate the associated function: `AnnotatableTryInto::try_into::<usize>(x)` | note: the lint level is defined here --> $DIR/future-prelude-collision-turbofish.rs:6:9 | LL | #![warn(rust_2021_prelude_collisions)] |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ = warning: this is accepted in the current edition (Rust 2018) but is a hard error in Rust 2021! = note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2021/prelude.html> warning: trait method `try_into` will become ambiguous in Rust 2021 --> $DIR/future-prelude-collision-turbofish.rs:23:5 | LL |     x.try_into::<usize>().or(Err("foo"))?; |     ^^^^^^^^^^^^^^^^^^^^^ help: disambiguate the associated function: `AnnotatableTryInto::try_into::<usize>(x)` | = warning: this is accepted in the current edition (Rust 2018) but is a hard error in Rust 2021! = note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2021/prelude.html> warning: 2 warnings emitted </ins>

Discussion:
Given the following code: The lint provides two suggestions, both of which fail with different errors. The first: fails with "type annotations needed" because the generics in the path are lost. The second: fails with "the trait bound is not satisfied". Ideally I think the suggestions should be: Found in the 2021 crate run migrating https://crater-
Looks like the turbofishes are swimming away! grabs turbofish food
Change:
<ins> // Regression test for the issue #63460. // check-pass #[macro_export] macro_rules! separator { () => { "/" }; } #[macro_export] macro_rules! concat_separator { ( $e:literal, $($other:literal),+ ) => { concat!($e, $crate::separator!(), $crate::concat_separator!($($other),+)) }; ( $e:literal ) => { $e } } fn main() { println!("{}", concat_separator!(2, 3, 4)) } </ins>

Discussion:
This code ([playpen]) compiles on stable but not on nightly and beta: [playpen]: Standard Error Edit: Removed macro Originally posted by in
modify labels: A-macros A-resolve C-bug T-compiler
I updated the snippet to remove the module.
This is a regression from (cc Slightly more minimized reproduction will look like this: performs eager expansion on its arguments and hygienic context of produced by such expansion looks like it was produced by the opaque for some reason, so it's resolved at ' definition site. It maybe either some issue with hygiene infra interacting with eager expansion, but it also may be caused by incorrect spans produced by .
(I'm currently looking into the details.) UPD: I have a fix locally, will submit tomorrow.
Fixed in

() Errors: If either the recursion () or the is removed (), this compiles exactly as expected. Additionally, if I explicitly name my crate, it works as expected, but would be vulnerable to crate renames in user code (can't reproduce in playground because it doesn't build a library).
If you try and build Rustup, you get a similar failure, but without recursion or . Seems that just using another macro and is enough in some circumstances
cc for the hygiene macro in
This code () compiles on stable but not on nightly and beta:
Please, file a separate issue for the regression, I'll prioritize it over pre-existing issues (which the original issue seems to be).
Thanks, I filed it in
Fixed in
Thanks for your work on this!
Change:
pub struct RawTable<K, V> { capacity: uint, size:     uint, <del> hashes:   Unique<u64>, </del> <ins> hashes:   *mut u64, </ins> // Because K/V do not appear directly in any of the types in the struct, // inform rustc that in fact instances of K and V are reachable from here. marker:   marker::CovariantType<(K,V)>, } <ins> unsafe impl<K: Send, V: Send> Send for RawTable<K, V> {} unsafe impl<K: Sync, V: Sync> Sync for RawTable<K, V> {} </ins> struct RawBucket<K, V> { hash: *mut u64, key:  *mut K,

Discussion:
This compiles, despite Rc<T: !Send. I'm guessing this is because RawTable only uses K and V with marker::CovariantType, and I guess that isn't enough for the negative-impl to propagate. I haven't checked which other collections might be unsafe.
It appears that this also isn't specifically related to trait bounds: cc
Ah, yeah. RawTable contains only a , which is of course always Send/Sync. It should presumably just contain a plain and impl Send/Sync conditionally?
Or we need a more rich marker type.
may be a good replacement for the current system as it could contain a marker of and for example. For now though a manual impl of and will probably be required. Should other collections with an unsafe representation also be audited?
I can say confidently this is the only problem case in collections. It's the only collection that uses basically a pointer.
ok cool, good to know!
Change:
{ match error { NoMatch(static_sources) => { <ins> let cx = fcx.tcx(); let method_ustring = method_name.user_string(cx); // True if the type is a struct and contains a field with // the same name as the not-found method let is_field = match ty::get(rcvr_ty).sty { ty_struct(did, _) => ty::lookup_struct_fields(cx, did) .iter() .any(|f| f.name.user_string(cx) == method_ustring), _ => false }; </ins> fcx.type_error_message( span, |actual| { format!("type `{}` does not implement any  method in scope named `{}`", actual, <del> method_name.user_string(fcx.tcx())) </del> <ins> method_ustring) </ins> }, rcvr_ty, None); <ins> // If the method has the name of a field, give a help note if is_field { cx.sess.span_note(span, format!("use `(s.{0})(...)` if you meant to call the  function stored in the `{0}` field", method_ustring).as_slice()); } </ins> if static_sources.len() > 0 { fcx.tcx().sess.fileline_note( span,

Discussion:
I tried to do this: And I got the error: S It seems to try to look for a member function and ignore the member variable. One person(alexchandel) in the rust irc channel said this was a bug and should work, another(p1start) said the error message should be improved.
To get this working, you need to write . The problem is that Rust will search only for methods named and not for fields. I don't know if there are plans of changing this behavior. If not, then I guess it would be nice to get a clearer error message which explains this.
I've tagged the bug so that it covers improving the error message by adding something like (s.func)(...)func.
I guess we would need to check if the type has a field with the same name as the method.
I got it working with the nice people in the channel but thanks anyway. Alright, sounds good.
Change:
impl<T: Write> OutputFormatter for JsonFormatter<T> { fn write_run_start(&mut self, test_count: usize) -> io::Result<()> { self.write_message(&*format!( <del> r#"{{ "type": "suite", "event": "started", "test_count": "{}" }}"#, </del> <ins> r#"{{ "type": "suite", "event": "started", "test_count": {} }}"#, </ins> test_count )) }

Discussion:
The output of a test suite starting when using the json formatter represents "test_count" as a json string, like so: I would expect it to be a number like this:
It also seems like "filtered_out" on run finish is also unexectedly a string.
Change:
<ins> // run-pass #![feature(generic_associated_types)] #![allow(incomplete_features)] // This test unsures that with_opt_const_param returns the // def_id of the N param in the Foo::Assoc GAT. trait Foo { type Assoc<const N: usize>; fn foo(&self) -> Self::Assoc<3>; } impl Foo for () { type Assoc<const N: usize> = [(); N]; fn foo(&self) -> Self::Assoc<3> { [(); 3] } } fn main() { assert_eq!(().foo(), [(); 3]); } </ins>

Discussion:
<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
glacier ""
cc
Guess I should claim this too since its likely a duplicate of that issue? claim

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This no longer needs since minconst_generics has been stabilized. cc
claim
Change:
<ins> #![crate_name = "foo"] #![feature(doc_cfg)] pub mod tag { #[deprecated(since = "0.1.8", note = "Use bar() instead")] pub trait Deprecated {} #[doc(cfg(feature = "sync"))] pub trait Portability {} #[deprecated(since = "0.1.8", note = "Use bar() instead")] #[doc(cfg(feature = "sync"))] pub trait Both {} pub trait None {} } // @has foo/mod1/index.html pub mod mod1 { // @has - '//code' 'pub use tag::Deprecated;' // @has - '//span' 'Deprecated' // @!has - '//span' 'sync' pub use tag::Deprecated; } // @has foo/mod2/index.html pub mod mod2 { // @has - '//code' 'pub use tag::Portability;' // @!has - '//span' 'Deprecated' // @has - '//span' 'sync' pub use tag::Portability; } // @has foo/mod3/index.html pub mod mod3 { // @has - '//code' 'pub use tag::Both;' // @has - '//span' 'Deprecated' // @has - '//span' 'sync' pub use tag::Both; } // @has foo/mod4/index.html pub mod mod4 { // @has - '//code' 'pub use tag::None;' // @!has - '//span' 'Deprecated' // @!has - '//span' 'sync' pub use tag::None; } </ins>

Discussion:
See is unstable, however there is no unstable tag showing that, it would be nice if it would, just so it can be seen at a glance without going to their respective pages. cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Note that rustdoc already does something similar for : ! It could use a similar format for re-exports.
Really could just copy the existing tags (see -asm) and put em after the path.
claim