jiebi/CodeConvo huggingface dataset:
Change:
match this.resolve_macro_path(derive, Some(MacroKind::Derive), parent_scope, true, force) { Ok((Some(ext), _)) => if ext.helper_attrs.contains(&ident.name) { <del> let res = Res::NonMacroAttr(NonMacroAttrKind::DeriveHelper); result = ok(res, derive.span, this.arenas); </del> <ins> let binding = (Res::NonMacroAttr(NonMacroAttrKind::DeriveHelper), ty::Visibility::Public, derive.span, ExpnId::root()) .to_name_binding(this.arenas); result = Ok((binding, Flags::DERIVE_HELPER_COMPAT)); </ins> break; } Ok(_) | Err(Determinacy::Determined) => {}

Discussion:
So pointed out to me that some recent changes in name resolution seem to have broken . They pointed me at dealing with the fallout -- maybe you can leave a few notes as to what errors you were seeing before this commit? cc -- could this be the recent changes around name resolution of helper attributes in macros? It seems the relevant code is stuff like:
(Nominated for discussion around the breakage policy/implications here.)
Duplicate of , I'll prepare a fix.
fix Or rather a "tiebreaker" for the ambiguity, since both names are indeed in scope and create ambiguity, which is correctly detected after .
Fixed in

This is a dependency of . I was trying to compile ; it failed on both the master branch and the current published version. is ambiguous (derive helper attribute vs any other name) Indeed, the code does seem to treat as simultaneously a derive macro and an attribute macro. It works fine on stable.
Example of failing builds:
modify labels: +E-needs-bisection It'd be nice if somebody pinpointed specific PR (or nightly at least). Maybe has a clue what could have caused it.
Seems to be introduced at nightly-2019-11-17. Unfortunately I'm not able to bisect that further because cargo-bisect-rustc is telling me:
Likely
This is a consequence of , I'll provide a ASAP.
Fixed in
Change:
error[E0532]: expected tuple struct or tuple variant, found unit struct `S` --> $DIR/issue-32004.rs:16:9 | <ins> LL | struct S; | --------- `S` defined here ... </ins> LL |         S(()) => {} <del> |         ^ not a tuple struct or tuple variant </del> <ins> |         ^^^^^ help: use this syntax instead: `S` </ins> error: aborting due to 2 previous errors

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. -- The current output is: Ideally the output should look like: I'd like it to say "try to use a unit variant like "FarmAnimal::Cow" instead". For example, here's what happens if you use Tuple syntax instead of Struct syntax: So I'd like the new diagnostic to look something like: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is an example Ferrous Systems uses in our trainings, and some of our participants have tripped over this lack of suggestion here. The compiler DOES provide diagnostics when you use a struct syntax instead of a tuple syntax.
Alternatively the help could suggest a more direct: "Remove the parenthesis here".
claim
I just wanted to mention , and I wanted to thank you personally for implementing this diagnostics improvement so quickly! Let me know if you have a blog or twitter you'd like us to link to (rather than your GH profile).
Hello, linking to my GH profile is fine. I did not know I would contribute to such an interesting learning experience. Anyway thank you for mentioning me in your blog post .
Change:
/// /// [`shrink_to`]: ../ffi/struct.OsString.html#method.shrink_to /// [`OsString`]: ../ffi/struct.OsString.html <del> #[unstable(feature = "path_buf_capacity", issue = "58234")] </del> <ins> #[unstable(feature = "shrink_to", issue = "56431")] </ins> pub fn shrink_to(&mut self, min_capacity: usize) { self.inner.shrink_to(min_capacity) }

Discussion:
, should probably not be stabilized before , see
Happy to take this on as a first contribution to rust.
Great! I'd be happy to help you get started, just let me know if you want mentoring/instructions at any level!
are you able to define a list of the methods that need to be implemented as part of this PR?
I think all of these will essentially call the underlying functions on . [ ] [ ] [ ] [ ] [ ] [ ] [ ] -- this one is more of a maybe, since it's unstable on OsString. We can reuse the same tracking issue for this. We'll probably want to add all of these under the same feature gate.
thanks for that. I have the implementation drafted locally. I'm having some difficulty however in running the tests for stdlib - even a is producing errors not related to my changes. Is there any documentation I've missed for best practices on compiling / working on stdlib?
You'll want to use x.py; for your scenario I believe and/or are the commands you want. I'm not sure where the most current documentation is.
describes how to use .
Triage: since has been merged, can this be closed?
No, this is now the tracking issue for the stabilization of those APIs.
Reviewing this since then, I think it may be worth removing these APIs and replacing them with something like and . These aren't really commonly used so hiding them as such seems reasonable and is less heavy.
I'd love to see these stabilized. I have a tool that manipulates lots of paths, so I'd like to avoid needless reallocations. I generate lots of temporary paths in a loop. would work nicely to reuse the buffer. I need to concatenate several components. I know their length, so I could use I want to store lots of paths for later. is a bit smaller than , but if I can't reserve exact capacity, will reallocate.
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.
reviewed assuming we're only stabilizing capacity + withcapacity + clear + reserve + reserveexact + shrinktofit;&ensp;and shrink_to is being moved to instead.
: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. The RFC will be merged soon.
I've posted a stabilization PR in .
Change:
} #[derive(Diagnostic)] <del> #[diag(passes_break_inside_async_block, code = E0267)] pub struct BreakInsideAsyncBlock<'a> { </del> <ins> #[diag(passes_break_inside_coroutine, code = E0267)] pub struct BreakInsideCoroutine<'a> { </ins> #[primary_span] #[label] pub span: Span, <del> #[label(passes_async_block_label)] pub closure_span: Span, </del> <ins> #[label(passes_coroutine_label)] pub coroutine_span: Span, </ins> pub name: &'a str, <ins> pub kind: &'a str, pub source: &'a str, </ins> } #[derive(Diagnostic)]

Discussion:
Same issue as which was for blocks. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
if !update(true).status().map_or(false, |status| status.success()) { self.run(&mut update(false)); } <ins> self.run(Command::new("git").args(&["stash", "push"]).current_dir(&absolute_path)); </ins> self.run(Command::new("git").args(&["reset", "-q", "--hard"]).current_dir(&absolute_path)); <del> self.run(Command::new("git").args(&["clean", "-qdfx"]).current_dir(absolute_path)); </del> <ins> self.run(Command::new("git").args(&["clean", "-qdfx"]).current_dir(&absolute_path)); self.run(Command::new("git").args(&["stash", "pop"]).current_dir(absolute_path)); </ins> } /// If any submodule has been initialized already, sync it unconditionally.

Discussion:
When bootstrap updates a submodule, it performs a hard reset, discarding all local changes: This was a nasty surprise when I was editing my local , and then did a and . Fortunately, I only had some extra debugging prints , but there was no indication that my local changes would be overwritten. We should require explicit confirmation before potentially deleting local changes like this. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
There is an option in : Automatic submodule handling can still be disabled with . We'd better get confirmation if there is no explicit config parameter get from ?
This has been a frequent source of surprises for me as well going back all the way to the addition of . More generally I feel it is important that we figure out what the out-of-the-box experience is tailored for – the developers or people building rustc for distribution. Today this is a mixed bag.
I think a simple fix would be to use git stash + git apply to save changes before doing a hard reset; if that causes issues for some reason, we can remove all the flags so that we don't overwrite local changes and give a hard error instead.
Can I work on this issue? Though I need Some guidance I am new to the project
first, reproduce the original issue so you can be sure your changes are having an effect. Then modify the git commands linked in the original post () to add before and after. If that saves your changes then your work is done and you can open a PR; otherwise you'll have to do some experimenting with git to see what works.
claim
That's what I have done
Maybe a Zulip thread is a better place to show your result and receive more feedback on the solution
I think will restore the prvious local changes, so if we want to get previous changes, it should at the ending.
Yeah! It was a mistake thanks for pointing out
I have done the intended changes and opened a PR . Can someone please review it?
Change:
| = note: `#[warn(incomplete_features)]` on by default <del> error[E0741]: the types of const generic parameters must derive `PartialEq` and `Eq` </del> <ins> error[E0741]: `T` is not guaranteed to `#[derive(PartialEq, Eq)]`, so may not be used as the type of a const parameter </ins> --> $DIR/const-param-type-depends-on-type-param.rs:9:34 | LL | pub struct Dependent<T, const X: T>([(); X]); <del> |                                  ^ `T` doesn't derive both `PartialEq` and `Eq` </del> <ins> |                                  ^ `T` may not derive both `PartialEq` and `Eq` | = note: it is not currently possible to use a type parameter as the type of a const parameter </ins> error: aborting due to previous error; 1 warning emitted

Discussion:
I tried this code: This produces the following error on rustc 1.44.0-nightly: I guess that const generics with a generic type isn't supported/allowed. If that's the case, this should be mentioned in the error message. :
The type needs to derive , not just implement them. This is because only types can be used for const generics at the moment, but we don't expose that to the user. Maybe we could improve the diagnostic here by actually mentioning .
thanks for fixing this so quickly! Is there a chance that this restriction will be lifted, so the above code compiles?
We would like to lift the restriction, but probably not in the first stabilised version of const generics, as it's not easy to get right: we need to be very careful in making sure that we don't accidentally allow unsoundness to sneak in, and there are many subtleties.
Change:
sym::likely => { self.call_intrinsic("llvm.expect.i1", &[args[0].immediate(), self.const_bool(true)]) } <del> sym::is_val_statically_known => self.call_intrinsic( &format!("llvm.is.constant.{:?}", args[0].layout.immediate_llvm_type(self.cx)), &[args[0].immediate()], ), </del> <ins> sym::is_val_statically_known => { let intrinsic_type = args[0].layout.immediate_llvm_type(self.cx); match self.type_kind(intrinsic_type) { TypeKind::Pointer | TypeKind::Integer | TypeKind::Float | TypeKind::Double => { self.call_intrinsic( &format!("llvm.is.constant.{:?}", intrinsic_type), &[args[0].immediate()], ) } _ => self.const_bool(false), } } </ins> sym::unlikely => self .call_intrinsic("llvm.expect.i1", &[args[0].immediate(), self.const_bool(false)]), kw::Try => {

Discussion:
Code 2 Few ICEs with new intrinsic <!-- 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. --: <details<summary<strongBacktrace 1</strong</summary<p</p</details<details<summary<strongBacktrace 2</strong</summary<p</p, so cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
like the intrinsic wasn't to the list at 2 Appears to be the same crash, just panicking at different points. label +F-core_intrinsics -needs-triage
claim
Would that check if the pointer address is constant or the referenced value is constant? I think for , one would expect the reference to be coerced to a . I don't know what to do for slices though.
I think checks for whether or not the the pointer address is statically known. I don't think mutable variables in function bodies can be statically known and references to globals are guaranteed to fold to false. That covers all the cases I thought about but I'm fairly confident I missed something.
They can be. It is usually the result of inlineing. Detecting that is kind of the point of the intrinsic.
Change:
sym::windows, sym::proc_macro, sym::debug_assertions, <ins> sym::overflow_checks, </ins> sym::target_thread_local, ] { self.expecteds.entry(name).or_insert_with(no_values);

Discussion:
An enhancement request discussed here: (That thread also contains a hacky solution by Yandros). I propose to add a config like this: #[cfg(overflow_checks)] I would like to use it to enable/disable lines of code that perform safe unsafe "as" casts replacing them with casts when I compile with debug builds or with release builds compiled with "-C overflow-checks".
modify labels: C-enhancement
label A-attributes T-compiler
I’d also be interested in this.
Tracking issue:
Change:
/// closure returns [`None`], it will try again, and call the closure on the /// next element, seeing if it will return [`Some`]. /// <del> /// Why `filter_map` and not just [`filter`].[`map`]? The key is in this </del> <ins> /// Why `filter_map` and not just [`filter`] and [`map`]? The key is in this </ins> /// part: /// /// [`filter`]: #method.filter

Discussion:
in the rust docs it says why is filtermap not equal to filter().map() this makes no sense it should ask why is filtermap not equal to map().filter(). also would be nice to explain that filtermap is is basically map().filter(is_some).map(unwrap) might make it easier to grasp.
Addressed in
Change:
/// Takes the value out of the entry, and returns it pub fn take(self) -> V { <del> let (_, _, v) = self.elem.take(); </del> <ins> let (_, v) = pop_internal(self.elem); </ins> v } }

Discussion:
This code manipulates a HashMap using the new Entry API, checking for consistency after each step. The assertion in should never fail, but in my tests it does so reliably, almost always within the first 10 iterations of the second loop. When it does fail, the value of is not one of the values previously removed during the loop (that is, is right to return this key, and is wrong to report it as absent). I tested this with on 64-bit Linux.
cc
Fffffff--- looking into it now. cc
Oh thank god it was a simple stupid mistake, and not something complicated.
Change:
"rustc-workspace-hack", "rustc_version", "serde", <ins> "serde_json", </ins> "shell-escape", "vergen", ]

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
triage: P-medium, removing nomination.
Change:
<del> Subproject commit fb115ee43b77601b237717c21ab0a8f5b5b9d50a </del> <ins> Subproject commit f9a8d70b6e0365ac2172ca6b7f1de0341297458d </ins>

Discussion:
Code: Output in release mode: There is a similar issue about , but incorrect comparison of may be more dangerous. For example, if unsafe code checks the equality between to uphold its invariant, passing values obtained this way may break the invariant, even though the unsafe code itself didn't work with function pointers.
In some sense there's no bug here, this is expected: comparing function pointers should behave the same with or without the cast. What is more surprising is that they print the same. This indicates that comparison is non-deterministic... which is rather problematic indeed, and could break plenty of LLVM optimizations.
Indeed this can be turned into a demonstration of non-deterministic comparison: The second assertion fails, the first passes (in release mode on 1.45.2). That's no good. In principle this could lead to a soundness bug, though I am not sure if that can be actually done in practice. Cc
This is an LLVM bug:
But MIR optimizations also have to be aware that folding equality tests on functions is subtle (Cc And recently had to prevent me from making a similar mistake for pointer equality tests in CTFE (Cc
The LLVM bug has been fixed. (pinging you in lieu of there being a way to ping the LLVM WG), do you usually backport such fixes or wait for the next release?
cc (pinging LLVM WG) I suspect we'll want to backport the patch ourselves, and try to nominate it for LLVM 11 (since that's not yet released, and we're currently on a release candidate). is the thing to backport I think.
Assigning as discussed as part of the and removing .
Discussion on the LLVM bug is that it's too late for 11.0.0, but could be to 11.0.1. If someone wants to see the fix sooner in rust's fork, I'm happy to review PRs: https://rustc-dev-
Change:
<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<const N: usize>(&self) -> Self::Assoc<N>; } impl Foo for () { type Assoc<const N: usize> = [(); N]; fn foo<const N: usize>(&self) -> Self::Assoc<N> { [(); N] } } fn main() { assert_eq!(().foo::<10>(), [(); 10]); } </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:
use task::rt; use task::local_data::LocalDataKey; <del> #[cfg(notest)] use rt::rust_task; #[cfg(test)] #[allow(non_camel_case_types)] type rust_task = libc::c_void; </del> <ins> use super::rt::rust_task; </ins> pub trait LocalData { } impl<T:Durable> LocalData for @T { }

Discussion:
This is a public module of things that are exported by core but should not be considered part of the stable library interface. Some don't like the name, and indeed it's name is the opposite of it's form. What should it be renamed to?
Internal, implspecific, dontusethis, unstable, changeable, corehacks?
back?
I like "unstable"; can imagine the future bug report about it changing unexpectedly...
'unstable' sounds good to me to.
Change:
{ // Errors in expanding nodes result from a lower-bound that is // not contained by an upper-bound. <del> let (lower_bounds, lower_dup) = </del> <ins> let (mut lower_bounds, lower_dup) = </ins> self.collect_concrete_regions(graph, var_data, node_idx, graph::Incoming, dup_vec); <del> let (upper_bounds, upper_dup) = </del> <ins> let (mut upper_bounds, upper_dup) = </ins> self.collect_concrete_regions(graph, var_data, node_idx, graph::Outgoing, dup_vec);

Discussion:
For the input file below, the two distinct invocations of (but with identical arguments) are non-deterministically deciding whether or not to prompt with the "consider using an explicit lifetime parameter" hint. Input file (): Transcript: (See also for a problem with the suggestion actually provided by when it chooses to actually provide one.)
I tested it a bit, and the issue seems to be is fed slightly different information each time. In the first case we have a and in the second . In the constraint graph for some node we are trying to infer, there are multiple incoming edges and outgoing edges to and from . From my understanding the compiler only picks one node from these incoming edges and one node from these outgoing edges, and it doesn't pick the same pair each time (what I don't understand is why I didn't see the and variations).
I'm getting a non-deterministic error message using the latest nightlies: It's non-deterministic on my Fedora 20 machine but not my OSX machine.
Change:
use prelude::v1::*; <ins> use cmp; </ins> use ffi::{CStr, CString}; use fmt; use io::{self, Error, ErrorKind};

Discussion:
In a few places in there are casts from to or for Windows APIs which causes breakage on 64-bit. Some examples I have found so far: () () (rust-lang-nursery/rand, ) There may be more.
Well I didn't find any more so I'll close this.
Change:
<ins> error[E0516]: `typeof` is a reserved keyword but unimplemented --> $DIR/issue-102986.rs:2:9 | LL |     y: (typeof("hey"),), |         ^^^^^^^^^^^^^ reserved keyword | help: consider replacing `typeof(...)` with an actual type | LL |     y: (&'static str,), |         ~~~~~~~~~~~~ error: aborting due to previous error For more information about this error, try `rustc --explain E0516`. </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. --: <!-- 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 --
cc :smile:
This really should fail before rustdoc gets to it, unless rustdoc has a representation :thinking:
An (the?) interesting bit here is that it's a very recent regression, for instance does not produce an ICE:
claim
This regressed in cc
Hmm I don't know how that caused it.