jiebi/CodeConvo huggingface dataset:
Repro steps: create a new cargo binary with . Replace with the following code. Then run . Hope this is helpful! I've tried to minimize the code as much as possible. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
The same issue happens in the latest nightly as well.
This bisects to nightly-2021-06-25. Commit range: It only reproduces with , not , which means bisecting to the old nightly needs in In that range, looks the most relevant because it is the only thing introducing edition-specific behavior, and it's dealing with closure capture and the presence of a closure appears necessary in the minimal repro. would you be interested in taking a look?
For comparison, the same code with doesn't emit a compiler error and has a bit more info:
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
In both and , function returns value every time but somehow in value unwraps into error, even though it's This is the returned value:
Triage: This is no longer ICE with the latest nightly, since (presumably ). Marked as .
Currently there are no landing pads generated for resource destructors so they are leaky when they fail. We don't have the same tricky situation that C++ has with throwing destructors but I haven't thought through how it should work yet. Edit: This issue has changed into what to do after a dtor fails during unwinding. The previous issue of dtor failure not working at all has been resolved.
There's a failing test in run-fail/unwind-resource-
And another in run-fail/unwind-resource-
The language reference is actually quite explicit about this: "A task may transition to the failing state at any time, due to an un-trapped signal or the evaluation of a fail expression. Once failing, a task unwinds its stack and transitions to the dead state. Unwinding the stack of a task is done by the task itself, on its own control stack. If a value with a destructor is freed during unwinding, the code for the destructor is run, also on the task's control stack. Running the destructor code causes a temporary transition to a running state, and allows the destructor code to cause any subsequent state transitions. The original task of unwinding and failing thereby may suspend temporarily, and may involve (recursive) unwinding of the stack of a failed destructor. Nonetheless, the outermost unwinding activity will continue until the stack is unwound and the task transitions to the dead state. There is no way to “recover” from task failure. Once a task has temporarily suspended its unwinding in the failing state, failure occurring from within this destructor results in hard failure. The unwinding procedure of hard failure frees resources but does not execute destructors. The original (soft) failure is still resumed at the point where it was temporarily suspended. "
Yeah. The hard/soft thing has never been implemented, as far as I know, but I think it's the best we can do: retain correctness of our memory model and try to retain correctness of user code, but not at the cost of infinite-recursion. If their dtor itself fails, just unwind that sub-failure w/o the opportunity for sub-sub-failures.
It would be good to revise the title of this bug to reflect what the task is.
(From the comments thus far, it sounds like the task is to implement the hard/sort failure unwindin protocol; but it might also be useful to clean up the docs here.)
Not critical for 0.6; de-milestoning
confirmed again; current code that can crash is as follows: If my idea for an effect system goes through, we might make this sound again by simply requiring no failure in destructors, e.g. .
nominating for well-defined milestone
there is language about this in the manual already in the task section, so I think it's well defined already. just not implemented. feature completeness issue.
accepted for feature-complete milestone
Triage: the updated version of example still crashes:
0 backcompat
This not only applies to destructors failing while failing, but this appears to also apply to linked failure as well. A program may only contain one statement, but it may still leak due to linked failure. An example of this would be: The destructor for never runs in this program because the call to invokes scheduler business which will realize that it needs to fail due to linked failure. It seems odd to me that if a task only contains one source of failure then we can still leak. This specific use case may not entirely fall under this issue, but it seems fairly serious.
The scheduler does have logic for not failing from linked failure when a task is already failing. So if, for example, the sleeping destructor here were to happen during unwinding, I think it should be fine. But if it happens normally you could still get failure.
I've updated the title to reflect what we're currently talking about. My understanding is that it is just impossible to throw from a landing pad because it will potentially corrupt the unwinder and our three options are: abort - this is what C++ does resume unwinding without completing the landing pad - this is what Ada does and we haven't discussed this option abort the task without completing unwinding - this is "hard" failure we've talked about The "hard" failure is made more difficult by tasks that are not simply green threads. For example, we have use cases where we want to run in a 'task context', on the current thread, and then be told whether the task succeeded or failed, all on the same thread. There's no way in that scenario to just terminate the task cleanly.
My current opinion is that, for 1.0 we should take the most conservative approach and abort. For future versions we should consider trying to do what Ada does and skip a single landing pad, but still proceed to catch the exception.
I agree with double-abort for 1.0. Thinking about the other two schemes in terms of how RWARCs (or whatever they're called these days) behave, aborting just a single task strikes me as risky in terms of unexpected behaviour befalling the user. If a double-failure occurs inside an access to a RWARC, it won't be automatically unlocked during unwinding, and other contending tasks will block forever. I think that resuming the unwinding and skipping the one landing pad still makes sense, though. If double-failure occurs in a user-provided destructor (or in the destructor of some buggy library), skipping the rest of the destructor can only "surprise" other code directly associated with the faulty destructor.
I agree too.
This is the correct output. Notice that one of the errors has a column of whitespace between the line number and the pipes, the next does not. Commit range:
Mentioning who made changes in librustc_errors. Could this be from ?
It looks like this can cause the wrong line number to be printed. :( If you bump the problematic line down to line 100, it prints as 10:
It seems like it might be.
Indeed. Upon closer inspection I've found out that actually changes the semantics of method: after applying this commit, if is not empty, then of them is not compared with , although could actually be greater. The correct code should rather look like this: Although it might be not the bug responsible for this issue, it definetely should be fixed. I'll make a PR with fix ASAP. EDIT:
Subtle. That seems about right.
Perhaps there's a minimum amount of debug info we can output by default without breaking things. This is alarming to newcomers.
I am 99% confident this comes straight from dsymutil.
Possibly related to
non-critical for 0.6, de-milestoning
+1 to fix this or provide temporary "fix"
As a new user curious about the language, this definitely made me think I'd done something wrong while building. This issue is also not a top result in Google if you search for the full error message and I haven't seen anywhere else that the issue is detailed. While this is totally understandable in a pre 1.0 release, it would be really nice to have a note that it's expected in the README and/or printed to the console at the end of the build output.
+1 30 seconds into playing with rust, initial impression: 0.6 is still not ready for anything more than casual experimentation. If that's the message you intend to send, well done!
+1 Occurs when building rust, and when compiling .rs files. I was almost certain my build had failed since the last ~6 lines were these warnings (while everything was fine). I also get this warning every time I compile any .rs file.
Nominating, production ready.
accepted for production-ready milestone
Thanks! I know it's a small thing, but I certainly appreciate it :)
I'd be curious what happens if we stop running dsymutil for non-debug builds. In particular, does the gdb experience suffer at all when debugging the resulting binary?
I am writing a rustpkg script for to fix cadencemarseille/rust-pcre and this is tripping me up because part of the script looks at output, which includes this warning in the data. For now I think I'll just use the last line of output, but it would be great to have this issue fixed.
I'm still getting this in Homebrew Rust on Mavericks. Trace: System: When Homebrew gets Rust 0.9 for Mavericks, will this be fixed?
I get this all the time still.
That's probably because we build servo with debug symbols, hence we run dsymutil. I would expect will have a better experience.
The job failed! Check out the build log: <details<summary<iClick to see the possible cause of the failure (guessed by this bot)</i</summary</details
This page isn’t working is currently unable to handle this request. HTTP ERROR 503
The bot got moved at some point; try Are there some docs that need to be updated?
Or how about made 302 redirect to the new target url?
Are there some docs that need to be updated? There are few references to the old address in the rust repo, including (all can be found by searching "buildbot").
Fixed the broken link in so I'm going to remove the issue tag here. It would be nice if there was a or something that was a GitHub Pages site that had an for and whatever else relevant resources for maintaining the queue. It'd be easy to change if the homu link changes again in the future.
I on IRC how to do this awhile ago, and I believe they're still basically applicable today. If anyone would like to help implement this and still has questions please just let me know!
The full repo is here: : </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
For what it's worth, I can reproduce this issue with version 1.63.0, but it doesn't happen with 1.64.0 nor with the latest stable version 1.66.0.
The ICE disappeared in nightly-2022-07-01, which contains the following merges: [x] : ICEs [x] : ICEs [x] : ICEs [x] : ICEs [ ] [x] : ICEs
Here is it minified, and standalone-ed:
Triage: This has been fixed on the latest nightly, as reported, and needs a test to close.
claim
This test program should exit quietly, but with , it instead fails the assertion: I also tested a really old 32-bit compiler, and it also failed: This test case is reduced from .
Probably a dup of (and )
Perhaps it's a dup. The other two issues are broken with and without optimizations, though. This issue only fails with optimizations.
Also: the expression in this issue doesn't actually require any overlap of the match patterns. (I'll update the test case.)
The bug also happens without a expression:
Good point. Also, this only happens with opt-level=2 (not 0 or 3).
cc Further refinement of the test case: Changing from to a large enough value avoids the bug. Apparently, the value needs to be large enough that, when rounded to the next highest power-of-two-minus-one, it is at least as large as . I think this is an LLVM bug. It involves the metadata. It's as if the compiler is reusing the range information from the check to elide the check (which is missing from the x64 assembly). Relevant unoptimized LLVM IR: isn't used in the test program. When I change its value, the only difference I notice in the unoptimized LLVM IR is in the range metadata (i.e. ).
Thanks Ryan! Indeed LLVM replaces the load with another disregarding the range information.
Patch is at
Patch landed upstream.
Using yesterday's nightly, fails on at this single test. The problem seems to be local llvm 3.6 is still allowed by the build system.
According to my CI this started 2020-04-16 (https://travis-) - : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
reports a regression in (PR ), cc
Assigning as and removing .
assign
Oh dear, I was hoping crater will find all such issues (this is ). I guess nobody in the wild is pattern-matching tuples with non-literal-length arrays. I can repro by adding this line () to the test (and the PR fixing this should IMO add the line to ): The fix is likely trivial: add another normalization, like in Presumably, for field accesses, this time (weird that doesn't trigger the bug). <hr/I've brought it up before w/ (but I don't know if I've seen a response), that the lack of normalization for array lengths in typeck is pushing complexity to the rest of the compiler and maybe we should do it in typeck. But then again, Lazy Normalization Is Coming, so maybe there's no point.
I believe I responded in the PR where you already asked me about that. I'm fine reintroducing a normalization phase
I am learning rust and reading the book for the first time The section mentions a "Next Project" at the very end We can add a link to that project ?
It's referring to the next project showed in the book (so next section if I remember well). If confirms, this issue can be closed.
Actually, this sentence is vestigial from when we had the Dining Philosophers chapter. I would actually prefer to remove this sentence. Want to submit another PR? :D
absolutely :-) on it
was interested in looking at the old . pasted here for future people was removed in
sent PR
There is no such thing as boxsyntax anymore :D <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
does the same.
It probably makes sense to search across the repository (including submodules) any references to this removed feature and remove them
claim
<!-- 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 tried this code: This currently fails, even though no symlinks are involved. This is because on Unix are currently compared on the totality of their contained unix , which are bitflags of the form (in octal) where is a Unix permission mode and the actual file type. As of now, depending on how the is built, may be either (from ) or set to the actual file permission mode (if built from ). (This bug was co-investigated with <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
label: +T-libs-api + Libs-Small
Error: Parsing relabel command in failed: ...'libs-api +' ' Libs-Smal'... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
label: +T-libs-api +Libs-Small
Error: Label Libs-Small can only be set by Rust team members Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
label: +T-libs-api
() Errors: Backtrace: modify labels: +I-hang +T-compiler +C-bug +A-lifetimes
somewhat minimized: To replicate this I needed: async two other arguments by ref at least one arg must not be bound to , compiles quickly the problematic argument must be contain an indirection: compiles fine. and also freeze. and a trait object containing at least one non marker trait explicitly bound to . and are both ok
repro is a regression in 1.43. It compiles immediately with 1.39 through 1.42.
I am currently bisecting this using
regression in modify labels: -E-needs-bisection
FYI who had context on .
rustc 1.12.0-nightly ( 2016-07-10) Changing the order of bounds in the associated type declaration changes which causes a spurious "mismatched types" error. Using UFCS works around the issue: The same issue exists with bounds like to compare with itself as well as another type. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cf.
Looks like this is caused by on the set of bounds from the trait, but that is just find the first one (in the order they are internally stored), this needs to filter and produce a vector of bounds or something similar. cc
Update: using filter and then calling on all matching bounds does not fix this issue.
I believe your problem is . Right now it works fine because the above would trigger for vs or vs . However, it's incorrect with your changes as is dropped in favor of even if and are not equal. The correct form would be more like this:
I guess that you didn't just call , but are also packaging up the specific bound that was matched? Anyway, not having seen the full diff, the general direction of these changes make sense to me.
Related:
triage: P-medium
Triage: :
This is fixed on current master. Should be closed.
I would like to work on this issue if its still relevant?
As mentioned the original code now compiles: Closing as there doesn’t seem to be anything left to do here.
do we have any regression test? I couldn't see any.
Oh good point. Sorry I missed the label. Yes, feel free to work on adding a regression test!
claim
This is clearly ridiculous, but rustc is perfectly happy with it. Regression from 1.9.
prints . Using the constant in any other way, e.g. errors out:
cc is that fallout from your new const eval?
I haven't removed anything, not that I can think of, to cause this.
Then it's very likely fallout from (skipping double negations)
The remaining error in that testcase feels wrong. should, IMO, be - the literal is in range, but the negation overflows.
Actually I think it should be valid code, but yield , at least that's what the original literal out of range lints do
But overflows when negating, which is an error. Why should it be different than ?
I have no particular opinion on this. But the lint has code handling double negations: (it's treating double negations as if they weren't there at all)
The double negation is not the issue here. The value of evaluates to , as expected. But consider the following code: This will also compile just fine and print . It goes wrong in the cast . Rust doesn't check if cast overflows, so the value becomes .  can be changed to disallow casts that fail. (I'd be happy to implement this myself.) Or we can accept that these casts are can overflow silently.
I believe the issue is that --128 (aka 128) is an intermediate result of the computation that is out of bounds for the i8. EDIT: The issue is about the fact that the compiler doesn't complain.
jup, that was a misunderstanding of some code on my part + the issue that processing HIR works the wrong way around (you start with the outer most expression). Reverting should do the job
I thought that it was intended that would succesfully evaluate to . (That rustc knows that it's overflowing, but is smart to know that double negation will fix it in the end.) Pretend I said nothing.
This file is only and : , but we should add the other float types to this test. The change should wait for since that changes some of these semantics (this PR is almost merged). There are probably a handful of tests that only check and but could use updates with the new types. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Okay will do that
FYI you can comment to assign yourself an issue
claim
Testcase: I was mostly fooling around trying to see if there was any way I could get rustc to believe that it would always know whether Bears<Twas Drop regardless of T; for the test case, I changed it to Clone and got rid of actually setting the constant to true in the default case, as well as some unsafe keywords, to avoid muddying the waters with Drop's semantics. Note that the array trick for turning a constant into a compile time error comes from , so it's not as contrived as it initially appears. Stacktrace:
The test case overflows on ` <details</details
The code doesn't produce ICE anymore (tested on ), instead, the following error is produced: ()
this no longer crashes , marking as needs-test modify labels: E-needs-test
In the 2017-12-14 Nightly I've seen a significant (almost 20%) compilation-time increase when I use on my code. And the successive day (2017-12-15) the compilation got a bit slower still and the run-time of the binary also got about 8% slower. The successive days the situation kept going slightly worse. Extracting parts of my code to show compiler/code performance is not easy, so I've composed this benchmark function (that solves an Euler problem. If this code isn't enough I will write other similar benchmarks): <details<summarySource code</summary</detailsCompiled with: host: x86_64-pc-windows-gnu Runtime: 2017-12-13: 0.30 seconds 2017-12-20: 0.53 seconds Asm from the the 2017-12-13 compiler: Asm from the the 2017-12-20 compiler:
Could someone try to reproduce and bisect this?
cc I think
We shouldn't have such big asm differences between successive nightlies, and I don't see anything suspicious in the middle, so it would be good to try and nail down the commit that made the difference.
I see a regression with this code (note: this is distinct from ). the bad code accesses the stack pointer (%rsp) You have a fast network connection and know how to use . Could you please do so? You should grep for to tell if the code is bad - the bad code includes the following line:
I bisected original example, just testing the speed of the executable created by a stage 1 and came upon (PR ) as the culprit: the runtime on my machine is around 0.3 seconds before that commit and around 0.7 seconds after. latest example also has a clear difference. The code before that commit (just disassembling the ): And after:
That's unfortunate. cc
cc
Thanks We're looking into it
just testing the speed of the executable I am not sure if they share the same cause, first a significant compiler performance decrease using --emit=metadata , then the successive Nightly the decrease of the produced binary performance.
They should not. However, quite a few big commits landed in the Dec 14 nightly.
If you could provide an example that exhibits the slowdown with , that would allow us to fix it (is the Dec 13 nightly faster than the Dec 14 nightly which has the same speed, but worse runtime performance, than the Dec 15 nightly?)
The last nightly (2017-12-21) has fixed all three problems. Despite some attempts I failed finding a small amount of code that shows a significant compilation slowdown from 2017-12-14 to 2017-12-20, perhaps it's a more diffuse problem that emerges from compiling my whole big amount of code. I am sorry. I don't fully understand your question, but I try to answer creating a table with some data for some of the last Nightlies: Rustc version --emit=metadata Opt build Binary size Run-time 1.24.0-nightly 2017-12-11 4.32 49.78 12.93 1.24.0-nightly 2017-12-12 4.31 48.50 12.84 1.24.0-nightly 2017-12-13 5.15 50.69 12.86 1.24.0-nightly 2017-12-15 5.33 52.98 14.04 1.24.0-nightly 2017-12-17 5.44 53.31 14.03 1.24.0-nightly 2017-12-20 5.47 54.49 14.14 1.24.0-nightly 2017-12-21 4.28 48.82 12.96 The --emit=metadata is a check time. The Opt build is the compilation time for a well optimized build. The binary size is stripped and in bytes. The times are all in seconds.
EDIT: told me about , so the range is .... EDIT2: at a quick glance, none of those changes should affect binary size or run time. How many times have you run each of these? How much do they vary?