jiebi/CodeConvo huggingface dataset:
Change:
| RegionNameSource::SynthesizedFreeEnvRegion(span, _) | RegionNameSource::AnonRegionFromUpvar(span, _) | RegionNameSource::AnonRegionFromYieldTy(span, _) <del> | RegionNameSource::AnonRegionFromAsyncFn(span) => Some(span), </del> <ins> | RegionNameSource::AnonRegionFromAsyncFn(span) | RegionNameSource::AnonRegionFromImplSignature(span, _) => Some(span), </ins> RegionNameSource::AnonRegionFromArgument(ref highlight) | RegionNameSource::AnonRegionFromOutput(ref highlight, _) => match *highlight { RegionNameHighlight::MatchedHirTy(span)

Discussion:
<details<summary<strongBacktrace</strong</summary<p</p</details
Changing Self{field} to MyStruct{field} makes it build btw.
I haven't done a search for the exact commit, but on the playground this regressed between beta and nightly. label +regression-from-stable-to-nightly
This is due to the NLL stabilization PR , since it manifests with on 1.61 (with to allow feature flags). I'll be looking at it in a few hours when I get home!
Change:
let _tables = tcx.typeck(body_owner); &*path } <del> _ => span_bug!(DUMMY_SP, "unexpected const parent path {:?}", parent_node), </del> <ins> _ => { tcx.sess.delay_span_bug( tcx.def_span(def_id), &format!("unexpected const parent path {:?}", parent_node), ); return None; } </ins> }; // We've encountered an `AnonConst` in some path, so we need to

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</detailsNOTE: The bug is found by our work-in-progress compiler testing tool Kira, and the test program is reduced/minimized by
Output on 1.46: modify labels: +regression-from-stable-to-stable
Assigning and removing as in the prioritization working group.
Change:
pub(crate) fn strip_private(mut krate: clean::Crate, cx: &mut DocContext<'_>) -> clean::Crate { // This stripper collects all *retained* nodes. let mut retained = ItemIdSet::default(); <ins> let is_json_output = cx.output_format.is_json() && !cx.show_coverage; </ins> // strip all private items {

Discussion:
cc label +A-docs +A-rustdoc-ui +C-enhancement +T-rustdoc This is technically a regression, but it doesn't feel appropriate to label it as such.
Here is an example of a block that should be hidden when is not passed:
Change:
<ins> // Copyright 2018 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. fn main() { | } //~^ ERROR expected `|`, found `}` | //~^ ERROR expected item, found `|` </ins>

Discussion:
Even more minimal test case: The parser for some reason is expecting a pattern by end of the second .
The ICE is fixed in nightly.
Change:
displayName: Install msys2 condition: and(succeeded(), not(variables.SKIP_JOB)) <del> - bash: src/ci/scripts/install-msys2-packages.sh displayName: Install msys2 packages condition: and(succeeded(), not(variables.SKIP_JOB)) </del> - bash: src/ci/scripts/install-mingw.sh displayName: Install MinGW condition: and(succeeded(), not(variables.SKIP_JOB))

Discussion:
On 2019-10-24 we had a CI outage due to the ca-certificates msys2 package being broken. The hack implemented (:heart:) is to download an older, known good package beforehand and install it after msys2 updated its packages. Once is fixed we should revert the hack, but I think at this point it's worth investing in vendoring msys2 as a whole.
msys2 is using and other tools from archlinux distro. Arch Linux provides per-day official repositories snapshots. User can "pin" to a specific date. I think it is possible to reuse that mechanism to vendoring msys2 as a whole, by providing a mirror of a specific date's version. See here for more descriptions .
that would be nice but msys doesn't remove old packages from their repo so the mirror would be enormous. Search for in , only those packages take dozens of GiB. Also extracting it from archive would make CI a bit faster because you won't be modifying thousands of small files over and over. On Linux that is not a problem but working through cygwin emulation a bit struggles on this part.
No update on this, planning to discuss what to vendor at the all hands.
At the last infra meeting we decided a good step is to move towards using the pre-installed msys2 packages. In theory this is as simple as removing the msys2 installation step and pointing things at the right location on the images in CI.
Change:
let mut _a = (0); //~ ERROR unnecessary parentheses around assigned value _a = (0); //~ ERROR unnecessary parentheses around assigned value _a += (1); //~ ERROR unnecessary parentheses around assigned value <ins> let _a = baz!(3, 4); let _b = baz!(3); </ins> }

Discussion:
The latest beta contains a new? l lint that triggers on macro by example code. This does not necessarily make sense because macros could be used to construct nearly arbitrary custom syntax for example something requiring to wrap a single element into a parenthesis. The strange thing here is that seems to only happen on beta, not on nightly, not on current stable. Found via Error message: rustc version:
My head can't come up with an example that requires parentheses. macros are hygenic, so there should be no problem in omitting the parentheses and just writing will be fine. Can you give me a counter example?
A real world example is the diesel  macro. Somewhere in the inner it does some clever things to support plain types and tuples by just saying where is some repeated type variable. Depending on the number of actual types there this will result in which is a single type or which is a tuple. It's probably possible to rewrite that code doing the same stuff but that would involve a lot of duplication (Because than you would need to have a special case for a single type everywhere).
So somehing like this: You're right. The question is: should we remove the lint for all macros? Only for macros that contain repetitive expansions? (Is that even possible to detect?)
modify labels: A-lint T-compiler
Would be great to get that fixed till it is part of the next stable release.
This seems to occur first on nightly-2019-11-02
nominating for discussing at T-compiler + T-lang meeting, namely to take peoples' temperature with respect to the idea of just not linting this case when the flagged code appears as part of a macro definition.
also, marking as P-high w.r.t. answer the question(s) posed here. (I personally don't think the severity of the actual impact is likely to be worth a P-high rating; the priority is likely just temporary until the discussion happens.)
The language team discussed this last week. The general consensus was that we can stop linting when the redundant parens are inside the macro (as opposed to e.g. where the spans are from the outside). We believe this is fine as the lint is mostly a style thing which does not protect from anything correctness or performance related.
I've played a bit around with this issue today.

Seems like conditions need to be adjusted to also check if we are in macro expanded code. I've tried something like but that does remove more warnings that we want.
I think the questions have been basically answered in terms of what path we see best going forward. Self-assigning, removing I-nominated.
Change:
<ins> error[E0061]: this function takes 1 argument but 3 arguments were supplied --> $DIR/issue-109854.rs:2:5 | LL |       String::with_capacity( |       ^^^^^^^^^^^^^^^^^^^^^ ... LL | /     r#" LL | | pub(crate) struct Person<T: Clone> {} LL | | "#, | |__- unexpected argument of type `&'static str` LL |        r#""#, |        ----- unexpected argument of type `&'static str` | note: expected `usize`, found fn item --> $DIR/issue-109854.rs:4:5 | LL |     generate_setter, |     ^^^^^^^^^^^^^^^ = note: expected type `usize` found fn item `fn() {generate_setter}` note: associated function defined here --> $SRC_DIR/alloc/src/string.rs:LL:COL help: remove the extra arguments | LL -     generate_setter, LL +     /* usize */, | error: aborting due to previous error For more information about this error, try `rustc --explain E0061`. </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. --code is from clippy: :warning: you need rustc build with debug assertions :warning: <!-- 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
Run into this while fuzzing, here is a minimized test case: Note that you need rustc with debug assertions enabled. Reproduced in nightly 2022-02-25.
Another test case:
OP and seem to be fixed on latest master (). now outputs "Span must not be empty and have no suggestion" <details<summarybacktrace</summary</details
I can confirm that both of my examples have been fixed on latest master () so this issue can be closed.
Change:
Self::new(List::empty(), self.reveal()) } <del> /// Creates a suitable environment in which to perform trait /// queries on the given value. When type-checking, this is simply /// the pair of the environment plus value. But when reveal is set to /// All, then if `value` does not reference any type parameters, we will /// pair it with the empty environment. This improves caching and is generally /// invisible. /// /// N.B., we preserve the environment when type-checking because it /// is possible for the user to have wacky where-clauses like /// `where Box<u32>: Copy`, which are clearly never /// satisfiable. We generally want to behave as if they were true, /// although the surrounding function is never reachable. </del> <ins> /// Creates a pair of param-env and value for use in queries. </ins> pub fn and<T: TypeVisitable<TyCtxt<'tcx>>>(self, value: T) -> ParamEnvAnd<'tcx, T> { <del> match self.reveal() { Reveal::UserFacing => ParamEnvAnd { param_env: self, value }, Reveal::All => { if value.is_global() { ParamEnvAnd { param_env: self.without_caller_bounds(), value } } else { ParamEnvAnd { param_env: self, value } } } } </del> <ins> ParamEnvAnd { param_env: self, value } </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
This one works okay:
This one also (Just proxying a type, that means that something strange with struct's generics):
Bisected to but it probably just bubbles up a pre-existing issue that the OP could be massaged to emit without this PR, cc author just in case.
This worked fine before 1.70.0 so it's a regression.
minimized
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Once this will be fixed.
Change:
} ty::Projection(ref data) => { <del> let tcx = self.tcx(); self.add_constraints_from_trait_ref(current, data.trait_ref(tcx), variance); </del> <ins> self.add_constraints_from_invariant_substs(current, data.substs, variance); </ins> } ty::Opaque(_, substs) => {

Discussion:
This is a follow up on , which now works. The following doesn't (): Error is: however, this lifetime clearly is used and is required.
The variance code in is: It seems to me that this is disregarding the substitutions for if I'm understanding what does here wrt. the substitutions (this pretty poorly documented right now). cc
BTW how long do we need to keep this warning around? I understand that this is basically a given when using nightly features. (It puts me off using it in my normal build path — but presumably that's exactly what is wanted, in order to detect bugs like the one reported here.)
We only use for those that have been ICE-prone in the past or are generally not in a "considered implemented modulo bugs" state. It's quite a small set of features that are incomplete like this. GATs specifically are to my knowledge nowhere near ready to be "implemented modulo bugs".
On this topic, the following builds, but the bound fails with:
Also, the following fails: with: This bound may not make much sense (since there is another lifetime parameter), but I believe it should be valid to specify here.
I'm running into a similar issue which I believe is the same as this:
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. pub trait Foo { type A; } type I<'a> = &'a (Foo + 'a); //~^ ERROR the value of the associated type `A` (from the trait `Foo`) must be specified fn main() {} </ins>

Discussion:
As far as I can tell, the following type alias is unusable: This isn't a complete type because is unspecified and isn't usable because there is no way to specify (as far as I know) after the fact. Personally, I feel type aliases like this should be compile time errors. I'm bringing this nitpick up now because fixing it is technically a breaking change .
now gives: So this looks fixed!
Change:
/// `join!` is variadic, so you can pass any number of futures: /// /// ``` <del> /// #![feature(future_join, future_poll_fn)] </del> <ins> /// #![feature(future_join)] </ins> /// /// use std::future::join; ///

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. --The feature gate for the issue is . <!-- 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. --- [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide]) [ ] Stabilization PR () [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev- <!-- Include any open questions that need to be answered before the feature can be stabilised. --- Should this be named instead? <!-- Include a list of all the PRs that were involved in implementing the feature. --- Initial implementation in - closed as it's ambiguous, see the discussion on that PR
This exists in futures-lite, and people use it. It seems worth having available in the standard library. The naming discussion doesn't seem likely to change, and all else being equal there's a history for the name . Shall we stabilize this? 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.
There are some soundness issues with (not strictly speaking a soundness bug, but we might still want to do a breaking change now before there are too many people relying on this): the fact that is always is a problem. It should require for that. See for details, in particular .
I am proposing to change the impl in
Change:
<ins> // run-rustfix use std::pin::Pin; fn foo(_: &mut ()) {} fn main() { let mut uwu = (); let mut r = Pin::new(&mut uwu); foo(r.as_mut().get_mut()); foo(r.get_mut()); //~ ERROR use of moved value } </ins>

Discussion:
searched nightlies: from nightly-2023-01-27 to nightly-2023-01-28 regressed nightly: nightly-2023-01-28 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details label +I-ICE +F-typealiasimpltrait
Minimized it further:
Change:
assert!(cmd.status().unwrap().success()); assert!(fdes.inner_write("extra writen".as_bytes()).is_ok()); }) <ins> #[test] #[cfg(windows)] fn env_map_keys_ci() { use super::EnvKey; let mut cmd = Command::new(""); cmd.env("path", "foo"); cmd.env("Path", "bar"); let env = &cmd.env.unwrap(); let val = env.find(&EnvKey("PATH".to_c_str())); assert!(val.unwrap() == &"bar".to_c_str()); } </ins> }

Discussion:
The following program demonstrates the problem: When compiled and executed on WIndows, it randomly displays either 'foo' or 'BAR'. This happens because process::Command represents environment block as a HasMap<CString, CString, so it treats "foo" and "FOO" as different variables, whereas Windows considers them to be the same one. When child process is spawned, both get into the environment block, however Windows keeps only the last one.
Change:
<ins> error: recursion limit reached while expanding `test!` --> $DIR/zero.rs:10:1 | LL | test!(test); | ^^^^^^^^^^^^ | = help: consider adding a `#![recursion_limit="0"]` attribute to your crate (`zero`) error: aborting due to previous error </ins>

Discussion:
The following code since it exceeds the default recursion limit. Using as the recursion limit works as expected. This is because we don't check for integer overflow errors when parsing limits: There's a few options here. My preference would be to silently default to when overflow occurs. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Hi! I'd like to try and handle this. If I understand this correctly, we should check if there is an , and if that error is an overflow. If it's an overflow, we default to ? claim
correct
Change:
<ins> error: identifiers cannot contain emoji: `🐛` --> $DIR/emoji-literal-prefix.rs:3:8 | LL | lexes!(🐛#); |        ^^ LL | lexes!(🐛"foo"); |        ^^ LL | lexes!(🐛'q'); |        ^^ LL | lexes!(🐛'q); |        ^^ error: aborting due to 1 previous error </ins>

Discussion:
In the 2015 and 2018 editions, the following compiles (with warnings): ` [playground] The is taken as an identifier, although emoji aren't generally permitted in identifiers in any edition. I tested with 1.77.1. I think the underlying problem is that and in distinguish "identifiers" containing emoji (as rather than ), but don't have a way to make that distinction for . [playground]:
Regression from 1.57 to 1.58 (stable to stable). Very likely in , cc Regression from error to pass. Previous error: .
WG-prioritization assigning priority (). label -I-prioritize +P-low
thank you for the detailed report. will fix this.
Change:
/// /// Should always be run for all inner scopes when a drop is pushed into some scope enclosing a /// larger extent of code. <del> fn invalidate_cache(&mut self) { self.cached_exits = FnvHashMap(); </del> <ins> /// /// `unwind` controls whether caches for the unwind branch are also invalidated. fn invalidate_cache(&mut self, unwind: bool) { self.cached_exits.clear(); if !unwind { return; } </ins> for dropdata in &mut self.drops { if let DropKind::Value { ref mut cached_block } = dropdata.kind { *cached_block = None;

Discussion:
This was discovered in database connection pooling where connections were not returned to the pool properly, and reported under Unfortunately I do not have example code small enough to share at this point. I narrowed down the rust-nightly version that introduced the bug to nightly-2016-08-03-x86_64-unknown-linux-gnu
when compiled with RUSTFLAGS="-Zorbit=off" the issue does not appear, so yes it is the MIR as suspected.
The compiler not running drop glue is not considered unsafe behaviour (i.e. it is allowed to happen), but it is still weird this happens. cc could be your drop elaboration not catching this () case? Something that we could run without having postgresql installed would be ideal test case, even if it depended on other crates for now.
Minimal reproduction:
More minimal: Removing either of early s in the function makes the issue go away. Seems like a scoping issue.
regression-from-stable-to-nightly (for a two more days at least).
Yeah I jumped the gun on the tag, but the beta is building right now.
I saw your commit -- I feel like the extent should be unique for the cleanup scope. That is, we should push a given extent only once -- but perhaps I am wrong about this? It'd be good to add an assertion (or warning) for when we push cleanup scopes with the same extent more than once so we can see what it happens.
Ah, but reading IRC chatter I see that the problem is that the extent of the "outermost scope" changed and thus the helper is out of date? That seems pretty plausible.
As pointed out on the IRC the commit linked above is a shot in the dark and is not a fix.