jiebi/CodeConvo huggingface dataset:
I guess it doesn't make much sense to merge as-is because of that. I'll have a look if I can determine a better heuristic based on the improved performance.
In order to determine the new switchover point, I ran some benchmarks for heaps of different lengths. For a constant total heap length (heap length after the operation), the execution time has an (approximately) linear relationship with the length of the smaller heap. This means the data can be fitted with a least-squares linear fit: ! The blue line is the rebuild strategy, and purple the extend strategy. The green vertical line indicates the intersection of the fitted lines, i.e. where the switchover between strategies should ideally be. The red vertical line indicates the switchover point using the current heuristic. The fits for all the different other lengths can be found in the collapsible section at the end of this comment. I've plotted the location of the ideal switchover point as a function of the total heap length (the current heuristic is not a smooth curve because it uses a fast but inexact log2): ! I think a couple points are noteworthy: The current heuristic is quite close to the ideal point for smaller heaps. The switchover point stays roughly constant (when considered as a percentage as in the graph above) for heap lengths 1000 to . For larger heaps, the ideal switchover point rises again, which is not reflected in the current heuristic. I am not sure how to best model a heuristic for larger heaps, especially because for the power-of-2 heaps show it drops again for the two largest heaps. However, I think it should be fairly straightforward to improve the current heuristic by setting a lower bound on the switchover point: This results in the green curve in the graph above. It is closer to the ideal switchover point in all cases, but for larger heaps it is still suboptimal. I'd love to hear ideas on how to improve the heuristic further for larger heaps. <details<summaryImages of all fits</summaryIn all graphs, blue is the rebuild strategy and purple the extend strategy. The dots indicate raw data points and the line is a least-squares linear fit. The green vertical line indicates the intersection of the fitted lines, i.e. where the switchover between strategies should ideally be.
Here's some code incorrectly defining a macro, because it's missing a fragment specifier. Here's the error message rustc gives me: It's potentially confusing that the error points to the source after the name with the missing fragment specifier. Especially in a complicated macro, it would be better if it pointed to the item which was actually missing the fragment specifier. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Some more context at
<!-- 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. --I am trying to fix it so that Rust's stdlib prevents unwinding, or allocating, in the child, after a fork on Unix (including in ). That is . (Allocation after fork of a multithreaded program is UB in several libcs.) I a new test case, Unfortunately this test fails, but just on Android: I have few good theories as to why. I wrote some speculations: I think this probably needs attention from an Android expert to try to repro and fix this issue. I suspect it's a problem with the library rather than the tests. The worst case is that it might be a general UB bug in Android Rust programs using or . I'm filing this issue here to try to ask for help again, since writing in doesn't seem like a particularly good way of getting the attention of Android folks. If we can't get a resolution, reluctantly, I guess I will disable that test on Android so that my MR can go through. The current situation is quite a hazard (see eg "panic! in Command child forked from non-main thread results in exit status 0") I will try to explain what the test does and what the symptoms seem to mean: The test file has a custom global allocator, whose purpose is to spot allocations in the child after fork. That global allocator has an atomic variable which is supposed to contain either zero (initially, meaning it's not engaged yet) or the process's pid. Whenever an allocator method is called, we read the atomic and, if it is not zero, we check it against . If it doesn't match we <strike</strike. The test enters , and engages the stunt allocator, recording the program's pid. Each call to (which is called from and therefore from ) produces output from . We see only one of these, so this must be the first test, . The test uses to fork. In the child, it calls (my new function to disable panic unwinding). It then panics (using the provided closure). This ought to result in the program dying with (or maybe or ). The parent collects the child's exit status. For the first test case, we run .
This extracts the signal number from it and checks that it is as expected. On other systems this works. In the failing test, this test fails. The assertion on fails. Meaning, the child did die of a signal but the signal number wasn't the one expected. The previous debug print shows that the raw wait status (confusingly described by Rust stdlib as an "exit status") is <strike</strike. Usually, a bare number like that in a wait status is a signal number, and indeed that seems to be the case here since is . On Linux (and most Unices), is and 10 is . Ie, it seems that the child tried to allocate memory, despite my efforts to make sure that panicking does not involve allocation. Weirdly, a more-portable test case which uses and does not insist on specific signal numbers passes. It's definitely my stunt allocator which is tripping here, because when I changed it to use instead of , the failing test case signal number changed too.
modify labels +O-android +T-libs-impl
<strike provided an explanation here I still think there is a bug here but it is not Android-specific. I have a WIP branch to try to address it, so I think it's probably best if I close this issue and submit that as an MR when it's ready.</strike
My first guesses were right. In where I changed the stunt allocator to use , we see this:
I found a memory allocation with a patched Miri: With this code:
Apparently, the thread locals aren't working as expected. I think the child after fork is being treated as a new thread, and then the thread local storage has to be re-created. I think the surviving thread in the fork should inherit all the thread-locals from the forking thread in the parent.
But I just tested the code after , so there's no "new thread" or "parent" here...
Oh! Yes. You are right. Evidently the first use of this thread-local allocates. Presumably that would happen on a new thread as well as on the initial thread. Having panic rely on thread-locals, and thread-locals rely on the allocator, seems unfortunate. Having panic allocate is not good, especially when actually it's just trying to abort precisely to avoid this.
Since is stored in which is not a thread-local, maybe the program could abort before using any thread-local.
It can't do that and also print the payload, because printing the payload might itself panic, and the recursive panic needs to be detected.
Maybe instead there should be a which can return None to mean "this thread-local variable has not been initialised".
I think it might be possible to use a to avoid the allocation.
Do thread-local always avoid the allocation? I think they fall back to regular thread-locals on platforms where avoiding allocations is not (easily) possible.
The version of looks basically same as the non- version when using , which will likely allocate here: Maybe the panic count could be stored directly in rather than on the heap. But is itself safe after ? If it tries to hold a lock or something it's possible to deadlock.
Should this only occur on Android? It happened on QNX as well (not yet upstreamed, work in progress so I don't trust it yet), but I can also reproduce it on with a simple patch (disables thread local storage): Would this be a target spec where we would expect to succeed?
Interesting. To be honest, I'm not sure. I do know that modern libc doctrine is that allocation after fork is UB. The test case is checking that we can safely panic after fork, and abort, without UB. This ought to work due to . I think that every failure of this test case is a real bug. Solving those bugs is not so easy because the machinery inside panic uses thread-local state which apparently is really super hard to make work without allocating or taking locks.
Yes, allocating memory is UB, same as working with mutexes. In case our setups are okay (i.e. having and using fork etc.), I also see this is a bug. Maybe we don't need to fix the issue with the thread-local state (if at all possible): calls to get the number recursive panics and if we . : determines using --works determines number recursive panics using TLS --allocates after --UB first: If it is true, it will always call -- the process will be killed very very soon by the OS In case of a recursion, a hardcoded-string is printed; otherwise additionally Do we really need to correctly determine a recursion, or can we allow "false positives"?
Instead of having UB, I think it would be fine to only check the number of overall current panics calls (as stored in ignoring ). If it is higher than 2, assume we have a recursion (results in false positives in case two or more threads panic at the same time). ==In case we have two panics going on in parallel by two threads there is the chance that we don't output , but it prevents UB. Also, when one thread calls it will often happen that the second thread will be killed soon and outputs nothing at all. In other cases (only one thread panics), there should be no difference. A change could look like that (high probability I've missed something!): This change passes all tests of for targets and QNX on AArch64.
Would you please try to test the fix above to check if it solves the issue on Android as well?
On most Unix it's UB to touch TLS after fork. Even if we have static TLS, accessing it might cause [^1] to be be called, and that function has paths where it allocates memory, takes locks, etc. That is, this is probably not a specific issue with QNX/Android. [^1]: At least on ELF, although I believe this is broadly true for Mach-O as well.
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: errors.isempty()'', 'thread 'rustc' panicked at 'assertion failed: errors.isempty()'' File: --auto-reduced (treereduce-rust): original: 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<!-- query stack: [typeck] type-checking [analysis] running analysis passes on this crate --
cc
I'm seeing an internal compiler error on the following input, found by : The ICE happens after correctly reporting the error "unknown start of token", so low priority. I guess that one part of the code treats as whitespace, while another part of the code treats it as not whitespace, causing a logic error with this input. Affected versions: nightly 2022-02-26 and beta 1.60.0-beta1 are affected, but stable 1.59.0 does not ICE. <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Fixed by , different enough to the test that I'll mark as needs-test. But anybody feel free to close this if we don't generally add fuzzed inputs to tests
Feature gate: This is a tracking issue for marking the and methods in , , , and as "const." [x] Implementation for : [x] Implementation for : [x] Implementation for and : [x] Final comment period (FCP) [x] Stabilization PRNone yet.
fcp merge / have been stable in const since 1.52. / are unblocked now by the stabilization of
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.
Can the methods be included in this? Similarly const stable / since 1.52.
Yes, that sounds like a good idea. I'll try adding another PR later.
:bell: This is now entering its final comment period, as per the . :bell:
stabilises this.
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.
The lint seems to be erroneously complaining about missing documentation examples where local types implement foreign traits (both from 3rd party crates and the standard library). The example below should pass all checks as far as I can tell: However, running results in the following warnings: :
cc
I think the current lint behavior is correct. The issue here is on the core lib side. I opened to fix it.
Maybe the lint shouldn't warn when implementing a foreign trait? By the same rationale as
Hmmm... I have shared feelings here: if a trait doesn't provided documentation "by default", doesn't it make sense to complain about it on the implementors?
I guess if you can add docs on the implementation it makes sense - you have a way to fix it.
That's mainly my position yes. :)
Unfortunately, that drags with itself more issues. First of all, I have to implement said examples on all of the implementations I write. Second, I have to copy (and correctly maintain said copy) the original example-less documentation onto every instance so that it's not lost by the language server and/or . While this isn't entirely impossible, it's a huge chore, especially when you implement multiple traits on tens of types at a time. While could get its issues fixed, that hardly helps us with the rest of the crate ecosystem. As of now, I have about 300 warnings, and actually useful information just drowns in that flood.
You can disable the lint on a specific implementation in the worst case. However, the goal is to enforce more documentation through the ecosystem. If users start to complain about it to the crates' maintainers, I'm pretty sure the situation will improve pretty quickly.
I don't really like this approach - it should be fixable by you, not by bugging upstream maintainers. was saying something like that for I think.
You can fix it on your side by adding the examples yourself in your implementation. So on that on point, even if not the best, it's still possible.
I suppose in the worst case, I could fork the upstream project, add examples, and hope that it either gets merged or the developer doesn't cause too many conflicts so I can keep it up-to-date.
But even then, it takes a lot of back-and-forth, a lot of time and effort on both ends to get from my linter complaining about missing examples to a new crate release that fixes it - even if everything goes quick and smooth. There should at least be a way for me to temporarily ignore warnings coming from (or rather because of) 3rd party and standard library crates, so that - at the minimum - I can fix my own linting issues without having to comb through thousands of lines of all too similar lines of warnings every time I generate documentation for testing purposes.
on the implementation?
Like I said, you can ignore the lint on the implementations, or directly on a module if it only contains such cases. Adding a doesn't seem to be such a burden...
Let it be known that I was today days old when I learned that you can apply to a single block. I suppose that will have to suffice for now.
I strongly feel that we should not warn on foreign trait implementations here. Firstly, as said, a lint should be fixable by you. Yes, you can add examples yourself, but that isn't actually the real fix here in most cases. In most cases trait implementations are lightweight and you rarely document them, so you're not actually giving the user a "fix", you're asking them to do something they don't actually want to shut the lint up. That's not good, that is not the actual fix, the actual fix is asking people to fix it upstream, and we should not lint that downstream. "The lint can be ignored" is not good enough for normal situations -- if it was some weird confluence of situations, then, sure, but a foreign trait impl is an extremely normal thing to do.
Coming back on this after a while and I now agree with this issue: we shouldn't lint on foreign trait implementations. I'll send a fix in the following days.
I just tried locally and it seems like this issue has already been fixed. Closing it then.
we should still test that it behaves properly
I'll send a test if there isn't already one then.
Consider the following code (): This code doesn't compile because that all type parameters are in scope for the concrete type. This get fixed eventually, but for the time being, we can work around it using (rust-lang/rfcs; ): However, this pattern does not compose. This example fails to compile (): with the error I'm not entirely sure why this fails, but it seems like the code should be accepted? /cc
Or a somewhat simpler example with just a single existential ():
Maybe also tag with since it's related to existentials? And possibly (or is this terretority?)
Replacing with compiles fine.
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls 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 prioritization.
I'll make an update pr once the two prs currently in the clippy ci queue are merged
triage: P-medium. Removing nomination tag.
Hi there! With this code (here's a ) The compiler reports this error message with a hint but the hint is incorrect due to missing parantheses in this case. The correct answer would be It works correctly when the second line in main is executed, where the range is provided directly. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Hi, The rust optimiser or some other component is not behaving correctly resulting in wrong results. I have produced a small example here : This was reproduced on Mac yosemite: cargo 0.0.1-pre-nightly ( 2015-01-30 02:47:30 +0000) rustc 1.0.0-nightly ( 2015-02-03 14:56:32 +0000) and centos7 x64, rustc 1.0.0-nightly ( 2015-02-05 23:14:28 +0000) Please let me know if you need any more details.
Reduced test case: This segfaults with = 2 (on Linux x86-64, )
This goes back to at least 0.12 - though it prints garbage values instead of segfaulting. 0.11 seems unaffected.
I've done some hacky . I'm not seeing the original data in the IR. cc Is this another memcpy metadata bug? Or a lifetime intrinsic issue. EDIT: turns out , which is used here, calls on its arguments, as if it was certain they were temporaries that didn't outlive the call (which is wrong, in this case). Not sure if needs to create a temporary for the value it's trying to compare with a constant, or the lifetime intrinsic calls shouldn't be emitted for .
This has two parts. When I extended rustc to emit lifetime intrinsics, I chose to put a call to at the end of functions to mark arguments as dead that are passed by value on the stack. This allows LLVM to remove dead stores at the end of functions that it normally can't remove. This works because normally, the caller makes a copy of the value it passes in. Now, the call that match generates to compare the strings is to , which accepts two slices by-value, and slices are large enough to be passed on the stack. Thus, calls to are emitted. But, the call the match generates does not actually make copies of the slices, but passes in pointers to the original slices. That means that the call marks the original alloca as dead, and then things fall apart. Question: Do we want to drop the call for by-value on-stack arguments, or fix the call to eqslice to make copies? cc
just-a-bug; P-high, not 1.0 milestone.
Macro definitions encoded to the metadata do not preserve the identifier style, thus certain paths break down.
Nice catch. I was afraid something like this would happen... Really a bug in pretty printing, as it doesn't preserve the ident style. This is what we get for hacking contextual lexer information into the token stream...
The original example now compiles fine, but then I'm not sure about tomaka/android-rs-glue. is this issue still relevant?
I didn't test myself, but reported that it's fixed.
Yeah it looks like this has been fixed, yay!
The following code gives "warning: enum is never used: ": This regressed pretty recently. cc
27.0 does not warn, 1.28.0 does.
triage: P-medium; This seems like a papercut that should be easy to work-around (at least if one isn't using ...).
switched to P-high after prompting from
whoops forgot to tag with T-compiler in time for the meeting...
assigning to
I'm grabbing this, I think I broke it and it should be easy to fix
Rustdoc has accumulated a handful of settings that users can toggle as they read docs, but we don't document them anywhere. It would be ideal if we had some documentation about these options in the Rustdoc Book that described their functionality better than the short descriptions shown on the settings page itself. !
I don't mind picking this up, unless you want to do this yourself! I do however have some questions!: The Rustdoc book you mean is right? Do you suggest adding a new section to this book or would you include it in an already existing section? What do you believe is not clear / elaborated enough in the short descriptions? I do not know the specific details of each switch are there any side-effects that are not in the short description?
Triage: no changes. The rustdoc book is that one, ! I am not a rustdoc maintainer these days (cc ) but I would probably make a new section. While the short description is good, I think it would make sense to show the options in slightly more detail, for example, maybe a before/after.
Bit of a late reply :) Do you have something to add to this? Otherwise I will follow what Steve said!
I am attempting to use the () syntax to control how my test binary is compiled. I have created a repro at In , I tell to link 2 static libraries, one with (+whole-archive) and one without (-whole-archive). I add a nonsense link argument so I can inspect the produced link line. I expect to see linked without whole archive. Instead, I see both and libraries linked with --whole-archive: This may be related to the default documented . When I use nightly and specify it works as expected: However, I cannot use the nightly toolchain, so I cannot use , and seems inappropriate for a final binary crate types like cdylib, staticlib, and executables anyway. Tested with 1.62.1 stable and 1.64 nightly. Possibly related issues: ,
This is a bug introduced in The backward compatibility condition should look like and not .
Could you submit a PR with this fix? (We can backport it to beta if it's done in time.)
Sure, I'll create a PR. I'm not sure what tests to include, however. I had been looking at that exact code and almost submitted a PR earlier, but I wasn't sure about the whole context of that code and all the compatibility needs.
You can try adding a test case with to . One with and , and another with and without any (the compatibility case).