jiebi/CodeConvo huggingface dataset:
Encountered an ICE when building  0.18.0 on edition 2021. I have roughly narrowed it down to the following (can probably be reduced further). Seems to be an issue with closure captures. <!-- 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</detailscc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
The code can be further simplified to: The issue seems to be around using type annotation. If a type annotation is included, the right hand side of the let statement should always be read.
Is there a runtime check/ is MIR generated for checking if is valid? Because if that's the case then we need props2 to be caputred.
claim I should have a fix later tonight
We found another instance of this ICE that still fails with included: Found trying to migrate . Let me know if you need any more information.
Feature gate: This is a tracking issue for functions to clear the poisoned flag on and . [x] [x] Implementation: [x] Final comment period (FCP) [ ] Stabilization PR <!-- Once the feature has gone through a few release cycles and there are no unresolved questions left, the feature might be ready for stabilization. If this feature didn't go through the RFC process, a final comment period (FCP) is always needed before stabilization. This works as follows: A library API team member can kick off the stabilization process, at which point the rfcbot will ask all the team members to verify they agree with stabilization. Once enough members agree and there are no concerns, the final comment period begins: this issue will be marked as such and will be listed in the next This Week in Rust newsletter. If no blocking concerns are raised in that period of 10 days, a stabilzation PR can be opened by anyone. --<!-- Include any open questions that need to be answered before the feature can be stabilised. If multiple (unrelated) big questions come up, it can be a good idea to open a separate issue for each, to make it easier to keep track of the discussions. It's useful to link any relevant discussions and conclusions (whether on GitHub, Zulip, or the internals forum) here. --- None yet.
Hi, I read (wich got automatically closed by the way) and the PR It seems all good. What is the next step to make it in the stable API ? Can I help somehow ?
Hi, sorry if flooding but are there any updates regarding this issue?
I think the next step is one of the rust developers needs to start the final comment period. IDK what the criteria for doing so are.
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] 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.
I was wondering whether the idea of had been considered and found that addressed it. SGTM!
: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:
I tried this code: I expected to see this happen: Instead, this happened: This is caused by different quote handling. The first (correct) command line for the spawned process (as observed by ) is: The broken one is: The command for must be in additional set of quotes, as the first and last one are stripped. It works when there are no spaces in the arguments due to the exception rule, see Stable. It worked up until nightly-2021-11-20 nightly-2021-11-21 modify labels: +regression-from-stable-to-nightly -regression-untriaged
This is caused by Rust now handling finding the exe to run itself (for security reasons). The fix here would be. as you say, to detect or extensions and add the extra quotes. The underlying function call here is . As the documentation says, this can only be used to run files. However, an undocumented feature of is that it will do this for us if given a or file. Previously we used to leave the argument blank and let it guess the right application from the argument. So apparently it would fill in for the application name and add plus the extra quotes to . But now that we do fill in the ourselves, it will still change to and add to but evidentially doesn't add the extra quotes. Thus we need to do this ourselves.
That seems reasonable; could you or someone on the Windows team submit a PR adding the requisite quoting (since quoting is hard to get right)?
Oops, sorry! I had a PR lined up but forgot to submit.
<!-- 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. --Playground stable: Playground nightly: Somewhat similar to Edit: Actually, it's identical except this is with two lifetimes. Edit 2: And this one crashes stable, while the other does not. Also crashes without enabling features, and complains that However, constraining removes this error, but not the crash. Two lifetimes are required for the crash. <!-- 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. --: Also crashes on Rust Playground with stable <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
glacier ""
Seems related to
No longer ICEs since
<!-- 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 --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
modify labels to +A-inline-assembly +F-asm +requires-nightly +O-riscv
Interestingly this does not reproduce when change register names to x86 ones; a error will be generated correctly.
I think I've located the issue. claim
claim
Would you like to fix this issue? I'm dealing with a case where I have to send a byte array buffer to a destructive function multiple times. This function requires the buffer to start with an initialization sequence that I have to set. I want to be able to efficiently reset the header bytes but the size of the initialization sequence is less than the total buffer and so I hit the error. The real question is, why is this required? Here's the current code: In theory, if is big enough to hold shouldn't that be enough? The adjusted call should be this then: I think the same should be done for clonefromslice.
The discussion of that decision is in
Holy bikeshed Batman! It’s impossible to find in all those comments! Thanks for pointing me there. It does seem from the first 30 or so posts that it was intentionally meant to fill the destination. If it does stick around, I do think the size checking should be done a little smarter.
Isn't fine? Personally, I find a bunch of value in the explicitness of requiring equal lengths since slicing to get the other three possible behaviours is so easy.
That's not a bad argument. Maybe we can adjust this to suggest that in the error message? I wouldn't have found that on my own.
some examples to the docs of using subslices with these methods. I don't know what the libs policy is on adding guidance to panics -- it does feel like one wouldn't want a long explanatory string built into one's binary in release mode, at least...
Agreed. In general, the longer the message the less likely people are going to read it clearly. I also believe not just stating the problem, but also offering a suggestion. “Destination and source slices have different lengths. Try sub-slicing the longer of the two.” This offers a jumping off point for Googling and reminds those (like me) that sub-slicing is a thing.
I'm personally against lengthening panic messages to suggest fixes, rather I'd expect someone to ask a question about this on StackOverflow or a similar platform eventually which would then get indexed by search engines. I'm going to mark this as an easy documentation issue; we can update documentation to note that subslicing is likely what users want to fix the panic in the panic section or the main section.
<!-- 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. --After adding to , I get the ICE. The resulting : The full project: <!-- 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. . --
Looks like another label: +T-types +WG-trait-system-refactor +regression-from-stable-to-nightly
Stable passes, beta passes. Nightly passes with either or Discovered with It does sporadically succeed, thus needing to clean and rerun the build to make sure. Either something is up with or it only barely exercises these conditions in the parallel frontend, even after cleaning and running the build 100 times. Meanwhile, fails something like ~50% of the time on my machine.
stable passes obviously, as -Zthreads this is a unstable nightly-only flag?
Hm, not actually obvious given that works, though I suppose that does mean it isn't a regression per se. :^)
oh I thought you knew by now that this is the forbidden env flag that should only ever be used for bootstrapping and nothing else and we should not even tell users about it. If you set the flag, your "stable" will also eat nightly-only features, but why would that make a "to-stable" regression if you explicitly tell the compiler "please act like you are NOT a stable release"? I don't think it make sense to backport fixes for untable nightly features into stable lol
who mentioned backports?
The label is used to gather regressions between release channels, which are then discussed whether they are backport-worthy or not. Is that not how the label is used?
I don't really think regression-from-stable-to-nightly nor regression-from-stable-to-stable are used for that at all? Probably regression-from-stable-to-beta is?
Pretty much what the title says, I've narrowed it down to and today's nightly with the following: I've attached some backtraces.
probably duplicate of but made more prevalent by next solver
Is it possible to provide a link to or a snippet of a reproducer? I know it probably happens to various crates, but it still would be nice to have something that reproduces.
See for an attached repro.
The repro case is basically the same as , but with other crates mentioned in the ICE logs from the issue comment.
Compile with latest Nightly got ICE like below: when compiling in code OS: x86_64-apple-darwin
cc
Wyvern, could you provide some sort of reproducer? A link to some commit in some repository or better yet a smaller stripped down version of it?
Can you provide an example which triggers this behavior?
I'm not sure which commit/PR of lead to this crash, sometimes it compiled successfully, sometimes it not. Add this info to original post, hope to help investigation.
are you running with greater than 1? The cache is broken when used with more than 1 thread (which we should fix)
Sorry, I wasn't clear. I meant a link to your project (the project you are trying to compile) if publicly accessible / not proprietary.
I can hit plenty of these while fuzzing with -Zthreads so yeah its probably that.
Yeah, I think was the culprit. Comment out this option crashes disappears.
the easiest fix to rustc is to just disable this assert when we're using more than 1 thread. I've only it for debugging purposes to detect cases where we unnecessarily recompute cache entries
just hit this while trying to bootstrap with Zthreads :sweat_smile:
cc as this also showed up in your ci test run ^^
When I just disable this assert, all relevant UI tests passed with no other bugs or ICE
samle code that triggers this in around 5 of 6 cases with -Zthreads=16
When a shared reference is assign, the gluedrop function is called with the old value before the gluetake function is called with the newvalue. With an assignment like "self.o = self.o;" the generated program will core. Of course, it's a silly example. All other examples I tried make a gluetake before calling the assignment (for example if you call a function with the argument "self.o" which will be then assigned) so you should never have this case in a real program. Maybe it doesn't need to be fixed as it shouldn't happen with a real program.
A simpler example: That segfaults for me. This should definitely be fixed!
Hm. At some point we had a test for this because I was quite careful to make this work correctly. Wonder when it broke.
Still segfaults as of
Not 0.6
Still segfaults as of . Nominating for milestone 5, production-ready
accepted for production-ready milestone
Still crashing
Still crashing with
accepted for P-high
Working on this
This no longer reproduces (with NIko's test case). I also tried with a managed pointer because apparently glue take/drop is only used for ref counting now and could not repro that way either. I tried to create a testcase as described in the first comment, but TBH I'm not really sure what was required. I tried a few things nothing crashed. I also examined the llvm ir and the 'problem' is that we never create these drop before take patterns. Anyone got an idea for how else this bug could be repro'ed (I really don't understand the glue stuff, so I might be missing something obvious)? Otherwise I suggest the bug should be closed.
I'm not sure if we have a test for this already. Perhaps there's one that was marked as ignored.
With a test case checked in, it looks like this can be closed (unless there's another subtler bug going on here).
I made a big effort to get this right as part of -- and totally forgot to write tests!
has to but the PR made it only into Rust 1.42.0. Thus the version number should be adjusted. cc
We would be happy to accept a PR for this. I suppose it's a trivial enough fix that I would even be willing to backport it (so we avoid 1.42 indicating incorrectly), but only if we get it in quickly enough. cc re:backport, since you're doing release
I won't do it but it should be easy enough.
I just made a PR for updating this; this is my first contribution to the project (please let me know if I did the process right). Hope that helps!
I just noticed this and saw a PR already existed, amazing! to a backport.
Currently, the compiler is allowed to inline naked functions if it wants to. For a normal function, inlining is fine because the compiler can remove the function prologue/epilogue and the remaining will behave as expected. However for naked functions, the developer provides the prologue/epilogue and those aren't removed by the compiler. This almost surely will result in incorrect behavior. Accordingly I think it would make sense for the compiler to not inline naked functions unless the developer explicitly opted-in.
In the other thread, alistair23 found that
Yes, functions should imply .
https://crater- modify labels: +regression-from-stable-to-beta I-ICE
searched nightlies: from nightly-2020-09-24 to nightly-2020-12-11 regressed nightly: nightly-2020-10-07 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: aarch64-unknown-linux-gnu Reproduce with: </details
cc -- seems like this one might be an actual bug
Small case that I think shows this issue, it incorrectly fails to compile on beta/nightly.
N.B. I haven't gotten it to ICE, so I can't add it to the
I tried this code: I expected to see this happen: Print the content of the $123 environment variable Instead, this happened: It literally prints $123 : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It is the shell that resolves environment variables. You're not using a shell here, just directly executing a command. This is behaving as expected.
Indeed, this is the expected behavior. This can be circumvented by actually using a shell, e.g. on POSIX:
I did a quick check on the doc for Note that the argument is not passed through a shell, but given literally to the program. This means that shell syntax like quotes, escaped characters, word splitting, glob patterns, substitution, etc. have no effect. I guess we can expand "substitution" into "variable substitution" to make it more clear.
so is this just a documentation change? claim
Feature gate: This is a tracking issue for . This feature adds methods to / to gain access to the contained value, by unwrapping if there is exactly one reference, or cloning otherwise. It is equivalent to cloning the inner value, but saves the clone operation if the caller has the only reference to the rc'd value. [x] Implementation: [ ] Final comment period (FCP) [ ] Stabilization PRThere seems to be consensus that the current name is good.
Apologies if this is the wrong place for this comment, feel free to delete. Is there a technical reason why is an associated function and not a method? If I have , I cannot call , but have to resort to which feels unwieldy.
it's because / are 'wrapper types' that implement . A lot of the methods are implemented as associated functions so they don't clash with method names on the . This makes it easier to change between different wrapper types like / etc without suddenly getting a name clash. Apologies if I'm using the wrong terminology but that's the gist of it.
That makes sense. Thanks for the explanation :)
sounds like a bad name to me: has a connotation of potentially panicking code in Rust. The other suggested names in all sound better to me. (Couldn't comment on the thread in IRLO as it has been closed.)
There is precedence for this pattern: for example.
True, I overlooked it.
I think this name is good, and it's easy for me to understand what it means. I'm really looking forward for this to be fcped and stabilized.
At $work we've been using the exact same implementation as the one used in nightly (), it works perfectly well
While I like the proposal very much (for it's convenience), I feel like I want to point out something that might be interesting as well in the future and is related: It's not possible to use where . In this case we have an , which is . However this is a conversion that is also very useful. It would be intersting to go from to . The other way is already possible, but this way is currently not possible, however there are sometimes cases where the count is known and converting back to a Box would be very useful. Consider wanting to remove an element from an for example.
The current way to do this is to clone the vec, remove an element and make a new Rc, even when an Rc is empty. I understand that there would need to be something like a first, but I just wanted to bring it up, so it's clear that there's potentially more things that could "unwrap" from an Rc.
Try this: The code above will copy vector if needed. (I didn't test the code)
Yes, good point, thanks for bringing it up. However a Vec is unfortunately another layer of indirection. Typically I have something like .
Is there something that still needs to be done before this can go to FCP? I just came across the need for this and noticed that the comments seem positive with confirmation that it works at $work for at least one commenter above, so am wondering what if anything is preventing it moving forward?
Pinging here for input. There seems to be consensus on stabilizing this. Can anyone start an FCP? I'd be happy to work on a stabilization PR (with some guidance)
fcp merge Both of these are already expressible on stable using the following incantation, which is exactly the standard library's implementation too: . The rationale for a dedicated method is that "I need a " is a common enough use case that it's worthwhile to have one easy function prominently available in the type's API doing the thing you most likely want to do in that scenario.
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [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.
and others: is related
: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.
I believe that can check off the stabilization?
And update the documentation as this seems to have been stabilized.
I am getting this:
Arc<strstores the string inline on the heap together with the strongcount and weak_count of the Arc. This means it has a different in-memory representation than Box<strand thus can't be converted into a Box<strwithout copying the contents. A Box<strto Arc<strconversion also copies the string contents into the Arc allocation.
I understand that. But moving elements from an Rc to a Vec is different from cloning. The opposite direction is already possible. This means that you can write , but not . I understand that moving is different from . This would probably need to be named something like Vec::frommovedrcorclone`.
GitHub deleted all my angle brackets. I was specifically talking about converting between string types because there's no difference between moving and cloning characters.