jiebi/CodeConvo huggingface dataset:
<!-- 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
minimized
Bisected to :sweatsmile:
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
What is intriguing is that the transmute doesn't fail, as it is a transmute from a 1ZST to a Never-like type, which has no representations. This code is definitely unsound, but I guess this is already a known thing.
Regression in cc
:facepalm: Oops, fix here: Good catch!
I'm tracking a issue with connecttimeout function on rust for vxworks. The function is also accepting connections on a non responsive server port. I get errors on unreachable host, but with host that are reachable any connection to a non existent server port is not resulting in an error. example program: Results: #./exe 127.0.0.1:90 /// No server at this port Successfully connected to server #./exe 192.0.0.1:20 //// Host is unreachable so correct behaviour. Failed to connect to server #./exe 172.16.2.223:8002 //Host is reachable, but there's no server at this port Successfully connected to server This is not observed with the connect function. I don't see a specified folder in library/std/src/sys/pal for vxworks. I found only one file for vxworks files. Does vxworks fall back on unix implementations for these functionalities? Any leads on how to proceed would be really helpful.
I don't mean to quibble much but tracking issues are not for "tracking" bugs, they are for tracking long-term projects that need issues-that-connect-issues.
Yes, see for why: basically our support was previously a trivial copy of the Unix support. The result may be buggy, because we do not really run CI against VxWorks. We are happy to accept patches, and even happier to have maintainers who are interested in repairing the target on a regular basis.
Thank You. I'll be continuously working on vxworks rust. So I'll be able to check this on a regular basis. Since rust 1.6 we've been maintaining a custom patch for rust build for vxworks. I'll update it for nightly and create a PR. I would like to be a code maintainer for this.
All you have to do to be listed as a maintainer is to add a doc using this template in rustc/src/platform-support/
I tried this code: I expected to see this happen: a "no value found" error pointing at the token Instead, this happened: a "no value found" error pointing at the : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This doesn't seem to be an issue on stable, interestingly.
Yep, it works fine on 1.63.0, but has the problem on 1.65.0-beta.1 and the latest nightly.
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: I expected to see this happen: The warning fires on all three lines of , and the suggestions should only suggest removing the parentheses, not the attribute also. Instead, this happened: The fires on the first and last lines of , and the suggestion also removes the . No warning fires on the second line (but this is probably a separate issue, unrelated to attributes; it happens even when the attribute is removed; maybe overrides it or something). <!-- 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. --: Requires use of , otherwise the is not legal in that position (though note that the warning and suggestion is the same on stable, there's just an first). The issue is not specific to closures and , but that was the simplest example of a reasonable attribute-on-expression I thought of. label +A-diagnostics +requires-nightly <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim
The following code causes an ICE: Removing the parameter or changing it to be a value instead of a reference stops the crash with an error saying I need to specify a lifetime, which makes me think this is a problem related to inferred lifetimes.
It isn't, you just have to specify a lifetime: ICE-s as well. Returning an unsized type should be a typeck error.
happens to work because it implies , i.e. would also work.
This example: gives this error: It took me some time to puzzle out what was happening here: expands to the default from the impl however is the impl method is accepted because it is more general than the trait definition but it fails to recursively invoke The error message without NLL, of course, is also not very illuminating.
Assigning myself to bookmark.
This seems to be a persistent ergonomics wart where traits get evaluated to (happens as well with returning and others I can't remember now) where it isn't expected. It is a bit sad, and we can improve the diagnostic errors, but I'm worried we'll be unable to preempt all the cases from being caught by accurate diagnostics, pushing people away from deeply nested structures. Maybe that is for the best, though.
I just want to note that the use of is, I think, a red herring in terms of the complaint about the diagnostic here. That is, I get the exact same diagnostic even if I add an explicit binder to the method, and then one can remove the . This is relevant because it means that if that feature is a red herring, then this bug may be relevant to the 2018 edition.
discussed with . We agreed this is not a blocker for 2018 edition. Tagging with NLL-deferred so it does not clog up our triage process.
I forgot to actual test how migration-mode (enabled for the 2018 edition) compares to . <detailsCurrent (nightly) 2018 edition output (): Current (nightly) output with (): </details
As for this week's triage, tagging this as P-medium priority.
I recently landed some changes ( and ) that are tangentially related to this but a similar strategy to them could be applied to this case.
Since feature has been removed, can this issue be closed as obsolete?
The example without : The error message isn't the same as migrate mode, but is on-par in terms of information (pointing out that the anonymous lifetime doesn't live as long as ). This issue can be closed by adding the above as a test.
When you write a mod with a capital name of a keyword, we suggest changing it to the lowercase version of the keyword, which is, well, a keyword and not going to work. We should suggest converting the identifier to snake case and making it a raw identifier, or maybe suggest switching to an altogether separate name? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Hey you might want to comment here to claim this issue :)
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: I expected to see this happen: build cleanly Instead, this happened: Running the program shows the field is used: <!-- 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. --Rust version 1.77.0 (tested in playground) </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Derived code is intentionally ignored for dead code analysis - if you try just You'll get a note explaining this. The note doesn't seem to be attached for warnings, just
Ah, so it's intentional. Interesting. I assume the solution is to mark it with then.
claim
release-assignment so can claim it
Error: Parsing assign command in failed: ...'assignment' ' so Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
claim
Note that while getting a warning if is just derived but never explicitly used may be understandable (as discussed in other issues), you will get a warning if you do use it explicitly (see ) which, in my opinion, should not be the case.
As mentioned above, the fix for this issue is adding a note about how derived traits are intentionally ignored, not to stop ignoring them.
Output is: The first message here is inaccurate. The macro-use does not expand to that macro-use. shows the input to macros, not the output. So instead of "expands to:", it should say "expanding:". But changing the behavior to match what the message says would be even better. ;) This is a regression because the error messages are new. used to just dump token streams to stdout (lol).
Introduced in .
Closing -- I believe fixed this.
A small demo: . I expected to see this happen The usual error message indicating that patterns and are not covered. Instead, this happened Patterns and are detected as not covered. :
If you add the suggested arms, it will in fact detect the other ones as missing. It is expected that is detected as not covered since the match guard is not taken into account when checking exhaustiveness (and couldn't be, since it's an arbitrary expression).
Closing as expected behavior.
Wouldn't you then expect that it mentions , , , and as not covered? Or is the number of outputs always restricted to two? In that case, I think it would be useful to indicate that some patterns might be missing, e.g.:
Yeah that's true
I do not have minimised code. This was a sudden CI build failure on nightly for aarch64-unknown-linux-musl () Note that this is a cross compile using cross-rs. It fails on rust version 1.82.0-nightly ( 2024-07-29) but works on 1.82.0-nightly ( 2024-07-28). Needless to say it also works perfectly fine on stable. The error is reproducible on rebuild and locally with cross-rs. It is not reproducible with cargo-zigbuild interestingly enough. I also checked that the version of cross-rs didn't change between the successful and failing builds (no new releases of that project since february). The only change between the successful and failing CI runs were a typo fix to an unrelated CI pipeline (the release one, so it didn't even run yet). As such I'm forced to conclude that the blame lies with Rustc. Steps to reproduce: I expected to see this happen: Compilation successful (as it is with stable for same target, or with -gnu and nightly) Instead, this happened () It most recently worked on: 1.82.0-nightly ( 2024-07-28) (or stable 1.80.0 or beta 1.81.0, take your pick for triaging) :
cc (of cross-rs fame) in case he has any insight on this regression
I have hit the same issue in a similar situation. Cross compiling to aarch64-unknown-linux-musl from x86_64 linux in a Github CI pipeline using cross-rs. Link to pipeline failing logs:
Seems rune isn't needed based on the comment by Updated the title.
This is probably
WG-prioritization assigning priority (). label -I-prioritize +P-high
Yeah that's probably it. We used to build the C version of those symbols but switched to Rust versions with the compiler builtins update. Unfortunately we can't enable them on all platforms because LLVM has crashes, and the logic that would allow optional configuration is apparently not working.
After that part is fixed, we will need to enable the symbols on all platforms where is f128 (which includes aarch64), since these errors probably come from here I think anyone who needs a quick workaround can add to their dependencies to get the symbols directly, as described near the top of Note that this requires nightly.
Is it possible to add a dependency conditionally based on if it is nightly? (In a specific range of dates even?) I cannot and will not depend on nightly, but I do test my code on nightly in CI (in order to find breakages like this early). For now I just disabled that nightly build on aarch64 musl.
Same for me. Not using cross-rs though. Logs are here:
Same for me, both using as host toolchain and cross compiling.
Looks like it is happening now too for x86_64.
Not for my projects, so you should probably provide a reproducer on x86-64 GNU if possible, since that is a tier 1 platform (unlike Aarch64 on Musl). Or is this about some other x8664 variation that is also tier 2?
Woops, sorry, the x86_64 build failed too, but then i looked at the aarch64 build logs :) which still fail.
use std; import std::vec; fn main() { let vec[int] a = [0]; auto i = 20; while (i 0) { a += a; i -= 1; } } I suspect, but haven't confirmed, the following: If a vector that is in the process of self-appending (v += v) grows, we can realloc the existing vector pointer and invalidate the memory that is being copied.
I'm the last person who touched the vec append glue. I'll look into it.
Yeah, you were exactly right. Fixed by .
On Solaris 11 x86_64, from scratch builds of 1.66.0 from git fails with: A build of the same tag completes successfully, as do and builds of 1.65.0.
Was there an earlier (nonfatal) error? If miri failed to build there should hopefully be a reason mentioned. We turned miri on unconditionally, so builds require it to build successfully. Maybe we should disable that requirement for stable builds,but even so, stable builds should work just like nightly builds for miri
It doesn't even try to build , instead panics soon after its start: Dunno about Solaris build but MSYS2 hack quite a lot patches that theoretically could cause problems.
Found the culprit: Should be easy enough to fix by making install not unwrap anymore. Looks like I was too eager
Glad to see that this is indeed a real issue. Was tearing my hair out for hours wondering WHY x.py install kept failing with missing miri when is set with channel = "stable"
We are still seeing this with 1.66.1. […] Compiling thiserror v1.0.33 Finished release [optimized] target(s) in 38.48s warning: x.py has made several changes recently you may want to look at help: consider looking at the changes in note: to silence this warning, add at the top of note: this message was printed twice to make it more likely to be seen Build completed successfully in 0:28:41 python3 install Building rustbuild Finished dev [unoptimized] target(s) in 0.66s warning: x.py has made several changes recently you may want to look at help: consider looking at the changes in note: to silence this warning, add at the top of thread 'main' panicked at 'missing miri', note: run with environment variable to display a backtrace Build completed unsuccessfully in 0:00:01
The fix has been merged for the future 1.68 release.
This compiles: but this doesn't: More generally, a shadowed trait's methods are usable if it is shadowed by an item, but not if it is shadowed by an import. Should methods from shadowed traits be usable?
cc
cc
Nominating for discussion at meeting. Clearly we should be consistent. I'm inclined to think that they should not be available, ever.
I'm of the same thoughts as A new "thing" with the same name as another outer "thing" should not inherit/infer/have/etc. any part of that outer thing. This is the case with , but—according to the presented opinion—it seems like it needs to be made consistent for trait bindings, right?
Is there a reason to shadow traits by name? What happens here is that it must find a method named among the imported traits, and that name has not been shadowed in any way, so it should be callable.
Well, that's the question, isn't it. Imagine then that did have an method -- would you prefer an ambiguity error here, or success?
Ambiguity error if was implemented for in the example (and this error is already implemented). Otherwise it doesn't interfere in any way.
Another more challenging example might be: should the methods from be available, given that it is shadowed by ?
My feeling is that the simplest rule is to say that methods come from "traits that are in scope", and shadowed traits are not in scope. This interpretation is shadowing of items from prelude and globs, which seem like they should clearly not count towards method resolution.
Discussed in meeting and settled on "methods from shadowed traits should be unavailable". triage: P-medium
We also want methods from to be unavailable (from your more challenging example), right?
The uses a heuristic based on the worst-case number of comparisons to determine between two strategies: , equivalent to pushing all elements of the other heap. the vector of the other heap and rebuilding the heap from scratch. I've done some benchmarking, and it turns out that method 1 (based on ) is always faster for two heaps based on randomly shuffled data &ndash; on the computers I've tested it on, anyway. I've included images of below: first the current strategy, then the strategy (method 1). In the benchmarks, two heaps are merged, one containing the number of elements on the x-axis, the other containing 100,000 minus that number (for the rightmost data points both heaps are equal in size). The red line (sometimes hiding behind the green one) is in both images that corresponding to , the other lines are not relevant to this issue (they aren't standard library types). ! ! From the jump in performance in the first graph, you can clearly see when the switch between the two approaches happens. Graphs are similar for smaller heaps, I didn't test larger ones. It's possible method 2 is faster under other circumstances (maybe if one of the heaps contains mostly very small/large elements?), especially if both heaps are (almost) equal in size. However, I think the benchmark is more close to the "average" real-world use case than such a case would be (I'd be happy to be proven wrong about this, though). <details<summarySimplification of the benchmark that only runs the parts relevant for this issue</summary</details
The comment suggests that the rebuild strategy is more efficient if at least one of the following is true: comparisons are very expensive the appended heap is much much larger than self but self must still contain a handful of elements so that the logarithm is 2 You can see how the slope of the append method is lower, so its advantage would show if you extended your benchmark by an order of magnitude. If you used a more expensive comparison function it would probably show earlier too.
The code for swaps the heaps if is larger than , so the appended heap is always smaller than or equal to the self heap. Indeed, the slope of the rebuild method is smaller, but I can't find conditions where that is outweighed by the higher base cost of the method.
To simulate more expensive comparisons I've made a benchmark where each comparison involves some global atomic operations. Below that I've included a benchmark with ten times the number of items in the heaps in total (an order of magnitude more than that makes the benchmark very slow). The trends remain similar. ! ! The original implementation ( and ) seems to base its choice for heuristic mostly on the expectation it is a reasonable heuristic. However, I think reasoning from the worst-case scenario (O(n log(m))) is pessimistic for the method as a large number of es require only one or two comparisons (instead of log(m)) before ending up in the bottom two layers (that contain 75% of all items in the end). Maybe for even larger heaps the method actually is advantageous again, but I'm not sure how to determine a heuristic for that. <details<summaryChanged code for atomic benchmark</summary</details
Ah, I missed that. That indeed limits the opportunities to realize its advantage. The x-axis still says 50k though? First we would need a benchmark demonstrating that advantage anyway.
Only for the first image, that one has the same number of elements as before but a more expansive comparison implementation. The x-axis of the second image goes up to 500k, that one has normal "cheap" integer comparison but a larger number of items in the heaps. Certainly.
Naively, when I look at the graphs in the OP what I see isn't that extend is always going to be better -- the slopes seem to be clearly different, though two graphs with different scales and extra lines makes that comparison harder than it ought to be -- but that the current heuristic is doing a bad job of accounting for constant factors when picking the switchover point. Why isn't the answer here just use a number other than two in the heuristic?
Here's the two lines from a different measurement of the same benchmark in the same graph. It has a weird jump between and (artifact?), that's why included the more messy pictures initially. ! The slopes are indeed very different, and extrapolating them would lead to a crossover point. However, this crossover point can never actually be reached because you can't extrapolate beyond the rightmost data point.
The benchmark is set up such that two heaps are merged, one containing x elements and the other 100,000 - x. The rightmost data point at x = 50,000 corresponds to merging two equally sized heaps. The data point that would be to the right of that (x = 52,500) would give the same result as the data point to the left (x = 47,500) because both involve merging a heap of 47,500 and 52,500 elements and the heaps are swapped in one of them to make sure the smaller heap is append to the larger one. In other words, beyond the rightmost data point the slopes change (become negative) and the data would mirror the data to the left of that point (which is why I didn't include it). The crossover point is thus only reachable (in this benchmark) if you'd remove the swap-optimization (theoretically I mean, practically that would worsen performance, or course). The TLDR is that it appears the number would have to be such that the condition always evaluates to . On another note, I've now also benchmarked merging very large heaps (100 million elements after merge), and is always more favorable there as well. !
Just tried the benchmark with changes from PR and scores significantly better. The heuristic could still be improved though. !
Thanks for the update to remind me about this One thing that I'd missed last time: ing from the contents of a can never hit the worst case (needing to bubble to the root every time), since it's being extended by something that's in roughly-descending order. Do you want to wait on before looking at more?
I think for now it would be better to wait and/or work towards a better heuristic (even though can perform better, it's still up to 25% slower when the second heap is much smaller). PS/Disclaimer: I'm the author of and not a reviewer, so I may be a little biased, however the benchmarks should speak for themself. Would be nice someone else could confirm my claims
Nice performance improvements in , just a pity it makes determining the switchover heuristic more difficult ;). I ran the benchmark again with and on my machine it also improves 's performance enough that it's the faster method when merging larger heaps.