jiebi/CodeConvo huggingface dataset:
Code change:
/// assert_eq!(*x, 1); /// ``` #[inline] <del> #[unstable(feature = "mutex_unpoison", issue = "96469")] </del> <ins> #[stable(feature = "mutex_unpoison", since = "CURRENT_RUSTC_VERSION")] </ins> pub fn clear_poison(&self) { self.poison.clear(); }

Related discussion:
text: :bell: This is now entering its final comment period, as per the . :bell:
Given the state change this method causes, I am curious about rationale behind using vs ?
If it took , it wouldn't be possible to unpoison a mutex shared between threads despite that being the main case where poisoning can happen.
I just want to add that probably before stabilizing this method we should implement a lint which catches invalid patterns of using these methods since it is very easy to misuse. Or, at the very least, include information about potential footgun in documentation for these methods.
What kind of lint do you exactly want? What are the patterns in question that you are worried about?
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.
exactly the possible error outlined by Mara Bos: calling before acquiring a lock. The only way this usage is correct is when no other thread can act on mutex - either because they don't exist or because they are all blocked on something else. I believe that these situations are rare enough to flag such a pattern as at least suspicious.
If unpoison was a method of PoisonError or of MutexGuard instead of mutex, would it prevent such problems?
That was discussed here:
Code change:
fn main() { macro_rules! test { <del> ($($fn_name:ident,)*) => { $( </del> <ins> ($($fn_name:expr,)*) => { $( </ins> test_future_yields_once_then_returns($fn_name); )* } } <ins> macro_rules! test_with_borrow { ($($fn_name:expr,)*) => { $( test_future_yields_once_then_returns(|x| { async move { await!($fn_name(&x)) } }); )* } } </ins> test! { async_block, async_nonmove_block, async_closure, async_fn, async_fn_with_internal_borrow, <ins> |x| { async move { unsafe { await!(unsafe_async_fn(x)) } } }, } test_with_borrow! { async_block_with_borrow_named_lifetime, async_fn_with_borrow, async_fn_with_borrow_named_lifetime, async_fn_with_impl_future_named_lifetime, |x| { async move { await!(async_fn_with_named_lifetime_multiple_args(x, x)) } }, </ins> } }

Related discussion:
text: suggested this is because when we lower the async function, we add `), whereas it should be parented as something outside of the impl trait context (as that is how such an expression would be parented, if it actually existing in the AST). I have a bit of code where I'd like to use a reference with a lifetime in an "async" function, which panics the compiler. I tried this code: I expected to see this happen: My understanding was that async functions are allowed to take references as parameters. helped to debug this a little bit and there is a suspicion that named lifetimes are somehow not properly propagated. I stumbled into this because I wanted to have 2 args with references, but if the lifetimes are elided the compiler asks for them to be . Adding them ICEs the compiler. Instead, this happened: I got a compiler panic. Backtrace:
suggested might be related
It would appear one can workaround this by using async blocks manually: I still need to test this does what I expect.
why do you need the immediately invoked closure there,
Yeah, just noticed. I think I also had some other issue / ICE, but I don't remember exactly what it was. Gonna have to check it again. Also, I don't think I knew that on blocks was a thing.
I didn't quite understand why I needed the move. I am trying to fix the original ICE, I think I got some time today tomorrow, hopefully, will make some progress. But compiler newbie, so might not work out.
You need to move to avoid the closure borrowing the references locally. It's the same situation as with I just removed all immeditaly invoked functions from eval :wink:
I am playing around with similar types of borrowing patterns, namely using StreamObj to carry a stream around inside of a struct. I can't seem to use the posted work-arounds: I am taking this working code and I'm refactoring it. Starts as: this works, compiles and runs. Then I try my hand at refactoring to move the stream out of the same scope as the await code pulling out values.
Code change:
fn main() { macro_rules! test { <del> ($($fn_name:ident,)*) => { $( </del> <ins> ($($fn_name:expr,)*) => { $( </ins> test_future_yields_once_then_returns($fn_name); )* } } <ins> macro_rules! test_with_borrow { ($($fn_name:expr,)*) => { $( test_future_yields_once_then_returns(|x| { async move { await!($fn_name(&x)) } }); )* } } </ins> test! { async_block, async_nonmove_block, async_closure, async_fn, async_fn_with_internal_borrow, <ins> |x| { async move { unsafe { await!(unsafe_async_fn(x)) } } }, } test_with_borrow! { async_block_with_borrow_named_lifetime, async_fn_with_borrow, async_fn_with_borrow_named_lifetime, async_fn_with_impl_future_named_lifetime, |x| { async move { await!(async_fn_with_named_lifetime_multiple_args(x, x)) } }, </ins> } }

Related discussion:
text: Now I can get the same ICE as this ticket: ICE: full backtrace: Then I try some of your posted workarounds and they don't do the trick, here's my best try: but this fails to compile due to an ownership issue I can't figure out:
your final borrow error is because Fahrenheit while your contains a local stack borrow. You could try using  instead of Fahrenheit.
Alternatively to what suggested, you could move the code in to an async fn:
Code change:
<ins> error[E0597]: `a` does not live long enough --> $DIR/location-insensitive-scopes-issue-117146.rs:10:18 | LL |     let b = |_| &a; |             --- -^ |             |   || |             |   |borrowed value does not live long enough |             |   returning this value requires that `a` is borrowed for `'static` |             value captured here ... LL | } | - `a` dropped here while still borrowed | note: due to current limitations in the borrow checker, this implies a `'static` lifetime --> $DIR/location-insensitive-scopes-issue-117146.rs:20:22 | LL | fn bad<F: Fn(&()) -> &()>(_: F) {} |                      ^^^ error: implementation of `Fn` is not general enough --> $DIR/location-insensitive-scopes-issue-117146.rs:13:5 | LL |     bad(&b); |     ^^^^^^^ implementation of `Fn` is not general enough | = note: closure with signature `fn(&'2 ()) -> &()` must implement `Fn<(&'1 (),)>`, for any lifetime `'1`... = note: ...but it actually implements `Fn<(&'2 (),)>`, for some specific lifetime `'2` error: implementation of `FnOnce` is not general enough --> $DIR/location-insensitive-scopes-issue-117146.rs:13:5 | LL |     bad(&b); |     ^^^^^^^ implementation of `FnOnce` is not general enough | = note: closure with signature `fn(&'2 ()) -> &()` must implement `FnOnce<(&'1 (),)>`, for any lifetime `'1`... = note: ...but it actually implements `FnOnce<(&'2 (),)>`, for some specific lifetime `'2` error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0597`. </ins>

Related discussion:
text: File: snippet: 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
cc removing the println macro from around the match avoids the ice :thinking:
Fun :)
A more minimal version would be:
Code change:
PYTHONPATH="$PYTHONPATH:$GDB_PYTHON_MODULE_DIRECTORY" exec ${RUST_GDB}  --directory="$GDB_PYTHON_MODULE_DIRECTORY"  -iex "add-auto-load-safe-path $GDB_PYTHON_MODULE_DIRECTORY"  <ins> -iex "set substitute-path /rustc/$RUSTC_COMMIT_HASH $RUSTC_SYSROOT/lib/rustlib/src/rust"  </ins> "$@"  No newline at end of file

Related discussion:
text: I'm trying to use on project generated by and looks like the source code path is not configured:
Visited during wg-debugging's triage meeting. We think this is most likely still an issue but probably not a high priority one. If someone wants to work on this, the first thing they should do is retest and verify this is still broken (but we think it most likely is). There may be a fairly simple resolution to modify rust-gdb to detect which toolchain it's being invoked from and then run the set substitute-path path with the appropriate paths. I'm willing to help mentor someone in fixing this
Hi, I'm looking for a first issue, would love the mentoring!
can't reproduce it, it works just fine nearly 4 yrs later, has this perhaps already been fixed ?
Past should have included a sample test case.
No, I can still reproduce it. are you maybe using a distro-packaged toolchain? Crashing program: output: To make work, don't use in the replacement.
Code change:
initial_res: Option<Res>, res: Res| { if let Some(initial_res) = initial_res { <del> if res != initial_res && res != Res::Err && this.ambiguity_errors.is_empty() { </del> <ins> if res != initial_res { </ins> // Make sure compilation does not succeed if preferred macro resolution // has changed after the macro had been expanded. In theory all such <del> // situations should be reported as ambiguity errors, so this is a bug. span_bug!(span, "inconsistent resolution for a macro"); </del> <ins> // situations should be reported as errors, so this is a bug. this.session.delay_span_bug(span, "inconsistent resolution for a macro"); </ins> } } else { // It's possible that the macro was unresolved (indeterminate) and silently

Related discussion:
text: <!-- 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
Seems to have regressed in Rust 1.33 based on testing in Godbolt.
With only the errors relevant to the ICE:
I'll fix this.
Fixed in
Code change:
<ins> // aux-build:drop-shim-relates-opaque-aux.rs // compile-flags: -Zvalidate-mir --crate-type=lib // build-pass extern crate drop_shim_relates_opaque_aux; pub fn drop_foo(_: drop_shim_relates_opaque_aux::Foo) {} pub fn drop_bar(_: drop_shim_relates_opaque_aux::Bar) {} fn main() {} </ins>

Related discussion:
text: <!-- 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. --: Not posting the entire 1.7K lines backtrace :upsidedownface: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
You can also reproduce this in the rustc repo itself where will encounter the error with
Reduced: label F-typealiasimpl_trait
Found another repro I think: this one bisects to
`
prioritize
going to also link and as other reports of the same issue
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Ok, after a bit more back ond forth , I'm tentatively bumping this issue to P-critical and raise these questions (echoing the comments from the discussion): would it make sense to revert ? cc or would it make sense to revert (which IIUC leaked in the std library an unstable nightly only feature) ? cc Next week Rust 1.72 will be released, artifacts are going to be build real soon, I think. Thanks for additional comments to help improve my understanding of the context here. label -P-medium +P-critical
The underlying issue here is an issue with TAIT. was an implementation-only change simplifying some backtrace code in that was made under the assumption that TAIT was reliable enough to be used inside . As it is not user-facing it should be easily revertible. So the question here is whether it is safer to get TAIT working (potentially by reverting ?) so it can be used internally or to just hold off on using it until the issue has been resolved, reapplying once that happens. I have no compiler experience, but my initial hunch would be that the library change is preferable for now. I'll get a PR ready until tomorrow, unless someone beats me to it.
should not be reverted.
Code change:
<ins> // aux-build:drop-shim-relates-opaque-aux.rs // compile-flags: -Zvalidate-mir --crate-type=lib // build-pass extern crate drop_shim_relates_opaque_aux; pub fn drop_foo(_: drop_shim_relates_opaque_aux::Foo) {} pub fn drop_bar(_: drop_shim_relates_opaque_aux::Bar) {} fn main() {} </ins>

Related discussion:
text: All it does is cause us to now eagerly reveal opaques that were being skipped over during normalization, which means that we're just not hitting this code anymore: It does not introduce a bug, it just reveals one that already existed. I'm gonna use the minimized example () here. What's happening here is that we're generating a drop shim for that looks like: which then tries to validate that . However, it has type , where is a , which does not hit the code I linked above. Before , we'd emit something that looks like: which is a field that is incompletely normalized, but does* hit the code above.
Submitted the PR reverting : .
fixes this issue by not considering mir validity on shims until they have been optimized, which uses the reveal-all param-env for that shim. This ICE shouldn't be possible to trigger without , since it has to do with one of the intra-pass mir validations that are only done when that flag is active: I don't personally think that needs to be reverted, either.
This was also possible to trigger even before using an associated type. The test in exercises this too.
Code change:
<ins> // compile-flags:--test /// A check of using various process termination strategies /// /// # Examples /// /// ```rust /// assert!(true); // this returns `()`, all is well /// ``` /// /// You can also simply return `Ok(())`, but you'll need to disambiguate the /// type using turbofish, because we cannot infer the type: /// /// ```rust /// Ok::<(), &'static str>(()) /// ``` /// /// You can err with anything that implements `Debug`: /// /// ```rust,should_panic /// Err("This is returned from `main`, leading to panic")?; /// Ok::<(), &'static str>(()) /// ``` pub fn check_process_termination() {} </ins>

Related discussion:
text: Rustdoc now allows us to use in our tests. Unfortunately, this requires writing the manually, which really shouldn't be needed IMHO. So we now have to write: rust ///# fn main() -Result<(), (){ /// let foo = Ok(1usize); /// assert!(foo? 0); ///# } /// where it should suffice to write: rust /// let foo = Ok(1usize); /// assert!(foo? 0); /// Doing so will make the tests shorter and hopefully lead to more and less in tests.
Feels like a no-brainer to me; would be great. :)
I think there are two things we want before doing this: , so that it can always be , and existing code will just work. The re-do, so we can make a type that accepts any error type (since it'll just error anyway).
?
Yes, that's what I'm thinking, and I'm setting up a PR for that. However, it's still unstable.
I talked about this back in March on the " in main" tracking issue: That sample you gave isn't even valid as-is, unless coercing to is also in the pipeline?
That'll be next, hopefully. I wonder if it suffices to or if we need to keep a generic error type (which might mess with type inference). In any event, having both the aforementioned and should be a no-brainer, right?
Code change:
<ins> #![feature(return_position_impl_trait_in_trait)] trait Iterable { type Item<'a> where Self: 'a; fn iter(&self) -> impl Iterator<Item = Self::Item<'missing>>; //~^ ERROR use of undeclared lifetime name `'missing` } fn main() {} </ins>

Related discussion:
text: <!-- 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
Code change:
out_filenames.push(out_filename); } <ins> if sess.opts.cg.save_temps { let _ = tmpdir.into_path(); } </ins> out_filenames }

Related discussion:
text: Tagging as E-easy and E-mentor. The fix here involves changing the code to call to prevent the temp dir from destroying itself. This should be wrapped in an if like this one:
Hi, I want to try working on this.
Go ahead! Let me know if you need any assistance - feel free to either reach out here or over IRC (simulacrum is my handle there).
Code change:
passes.into_iter().collect(), css_file_extension, renderinfo, <del> render_type) </del> <ins> render_type, sort_modules_alphabetically) </ins> .expect("failed to generate documentation"); 0 }

Related discussion:
text: Instead it should use the order that appear in the crate file. Even better, it should allow adding section headers (with a description) between them. Hypothetically: And get something like this: This would make both the source code and the documentation more accessible as the modules would be presented in a comprehensible order, with some description of each related group of modules. Edit: Rename issue to reflect that this isn't an either-or. Alphabetical order is useful, but so is programmer-specified order (to make the code accessible for newcomers) and Rustdoc should support both - see the thread below.
Shouldn't related modules be nested in submodules rather than logically ordered in the source? Finding things in long non-ordered lists is a real pain.
Yeah, I'm going to vote "alphabetical".
Hmmm. I pretty sure I put a comment here, and now its gone. Strange. Anyway. Here it goes again. Alphabetical order == random order. That's great when you know what you are looking for and just want to find it. When coming to a new non-trivial code base, being presented the content in random order is just about the worst possible way to access it. Nested modules allow us to group related modules together, and that's a good thing. If you have a long list of modules, certainly, group them. But this doesn't solve the problem. You now have a TOC where each level is randomized, which is still inaccessible. Searching for a function or module by name is an important use case, sure. But being able to access a new code base is as important, if not more so. Looking up a name in a short non-alphabetized list (at each level) isn't too hard, and one can always compensate for the lack of an alphabetical index by using ^F. Trying to understand a system presented in random order is next to impossible, and one can not compensate for the lack of a comprehensible order in a large system. If there was a way to specify the order of the entries in each level, which we agree should only contain "a few" entries, then the TOC would become accessible. If one could even add a bit of annotation for each level, so much the better.
Code change:
passes.into_iter().collect(), css_file_extension, renderinfo, <del> render_type) </del> <ins> render_type, sort_modules_alphabetically) </ins> .expect("failed to generate documentation"); 0 }

Related discussion:
text: The annotated TOC would serve as a very accessible way for a newcomer to understand the code base. And, this doesn't rule out also generating an alphabetically sorted reference index, beside the TOC. All good books do both - a TOC in reasonable order and an index for looking up data by name. We shouldn't have to choose, we should be able to get both. So, I misnamed the issue. It should be "Rustdoc shouldn't list modules only alphabetically".
Agreed. Can someone rename the title?
Rename done.
Visiting for triage. Minor, but still an issue.
Triage, still listed alphabetically. Here's a sample source file: !
Code change:
"clippy_lints", "compiletest_rs", "derive-new", <ins> "git2", </ins> "lazy_static 1.3.0", "regex", "rustc-workspace-hack", "rustc_tools_util 0.2.0", "semver", "serde", <ins> "tempfile", </ins> "tester", ]

Related discussion:
text: Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. 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.
Code change:
use crate::fluent_generated as fluent; use crate::parser; <ins> use crate::parser::attr::InnerAttrPolicy; </ins> use rustc_ast as ast; use rustc_ast::ptr::P; use rustc_ast::token::{self, Delimiter, Lit, LitKind, TokenKind};

Related discussion:
text: Error code: Metadata:
What is the issue you are reporting here ?
Well, I thought that compiler can understand that is related to the block of code, but it fails.
Can you post a minimal reproducible example that demonstrates your issue? Or at least mention exactly what you'd expect to happen and why. Even code that is cfged out is still required to parse successfully.
Let's show you what exactly problem I have. Full code: And I get this error:
You seem to already have posted this a month ago. What you're asking seems a rather big change to me, I'm not that familiar with how the compiler parser works but I believe it currently requires your program syntax to be correct before macros are expanded, which is not true for your example, so some fundamental changes would be needed.
Oh, damn, sorry. I totally forgot that I made a post. Well, if it's not a bug and parser works like this it is bad, anyway, exists alternative way to write like this. But for me my issue is a candidate to feature request or a bug. Anyway, I'm not a lang dev, so I don't know what scales of this defect (?).
The workaround for this is to wrap the expressions in a block:
I solved this issue exactly as you did.
Another way to do this is using the macro and . I personally thinks it is more clear, and should optimize the same.
Work is not the same, due to compile-time evaluating an expression that we pass in it and evaluates only it, but at the same time everything compiles what is inside of .
Code change:
<ins> error[E0599]: no function or associated item named `mew` found for struct `Vec<Q>` in the current scope --> $DIR/bad-builder.rs:2:15 | LL |     Vec::<Q>::mew() |               ^^^ |               | |               function or associated item not found in `Vec<Q>` |               help: there is an associated function with a similar name: `new` | note: if you're trying to build a new `Vec<Q>` consider using one of the following associated functions: Vec::<T>::new Vec::<T>::with_capacity Vec::<T>::from_raw_parts Vec::<T, A>::new_in and 2 others --> $SRC_DIR/alloc/src/vec/mod.rs:LL:COL error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0599`. </ins>

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: param types with same index differ in name'', 'thread 'rustc' panicked at 'assertion failed: param types with same index differ in name'' File: --auto-reduced (treereduce-rust): original: Version information ` Command:
thanks for the stack trace for this class of ICEs, it's just the right thing that I need. Minimal: