jiebi/CodeConvo huggingface dataset:
Command was with the following <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
And yes, was enough to get the build to finish, in case there were any questions as to whether that was the difference.
This is the first PR that fails with the error described in I do not know if the fault is here or in the symbol mangling but it as I understand it that function that is called is only used for the the size of an array and it feels strange that it shall be a bool -- it seems pretty clear the bug is in the symbol mangling rather than with , because it's not adding anything out of the "ordinary" Rust code. That said, it's likely that the const generic could be replaced to avoid the error perhaps.
Yeah, isn't this "just" an instance of new symbol mangling not being compatible with const generics?
was to tired that night when I hade bisected the rust build and this hade nothing to do with arrays that I was writing. was possible to avoid the bisect all together if I only hade looked trough all of the log. it is saying that it is eg. that fails so it is the bool in the path that is triggering the fault in symbol mangling. according to only unsigned integers is handled and the rest is left for "future const-generics work" shall this be marked with some const-generic label? right now it is only bool that also needs to be handled for rustc to compile but do not know how to go forward
seems like there is a issue for adding mangling support here so this will probably be fixed when that issue is fixed.
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: expected type of closure to be a closure', 'error: internal compiler error: expected type of closure to be a closure' File: --auto-reduced (treereduce-rust): original: Version information Command: &lt;!-- Include a backtrace in the code block by setting in your environment. E.g. . --&lt;details&lt;summary&lt;strongProgram output&lt;/strong&lt;/summary&lt;p&lt;/p&lt;/details&lt;!-- query stack: [mirbuilt] building MIR for [unsafetycheckresult] unsafety-checking [mirconst] preparing for borrow checking [mirpromoted] promoting constants in MIR for [mirborrowck] borrow-checking [typeofopaque] computing type of opaque [typeof] computing type of [checkmoditemtypes] checking item types in top-level module [analysis] running analysis passes on this crate --
regression in ping
nice, that's one of the ICE messages I just too
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'no entry found for key'', 'thread 'rustc' panicked at 'no entry found for key'' 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
Regression in nightly-2023-11-08 / ping
I think is fixing an issue that may have the same root cause.
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at ', 'thread 'rustc' panicked at ' 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
Regression in nightly-2023-11-08 / ping
This should be fixed by
I'm intrigued as to why you believe could rectify this problem. The issue can be distilled as follows: It results in a panic at due to the closure utilizing the type from its outermost function, eventually returning . This issue appears to be unrelated to .
You're provably correct, and I am likely wrong about the root cause of the issue. I will look tomorrow. Feel free to claim this issue if you've already found a solution in the process of investigation.
If I run the following code : I get the following error : I don't see any reason for the trait Debug not to be implemented for BinaryHeap. If seeing the nodes of it is a problem, at least a could be enough.
Should be fine to display the elements -- probably an oversight?
Probably an oversight. Implementing the solution shouldn't take more than a line (few at most) and it is annoying that you can't easily implement debug for struct owning one BinaryHeap.
About to submit a PR for exposing intrinsics::needs_drop under mem. Needs a tracking issue. Here it is!
The PR is
fcp merge Seems like this may be good to stabilize!
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, 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.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.
I tried this code: I expected to see this happen: Instead, this happened: The problem doesn't occur with optimization enabled. It most recently worked on: Also fails on: modify labels: +regression-from-stable-to-stable -regression-untriaged <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Thanks for reporting this! This is an issue with a debug build so it's unlikely to be prioritized high but I'm interested in helping out because this is very goofy. The slow code here is the Iterator impl on slices. I think in the last stable release we switched the implementation of BufReader to eventually use ReadBuf, and the slow code is ReadBuf initializing the remaining uninitialized capacity. It does this by iterating over a slice, and that iteration is the slow bit. What I don't get here is why we need to initialize at all. That doesn't seem right.
WG-prioritization assigning highest priority since this looks a pretty visible runtime perf. regression (). If the assessment should be revised, please feel free to comment. label -I-prioritize +P-critical i-slow
I've tried bisecting with and feeding this command: . Regression seems to be in and confirm <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
:joy: I was so sure this wasn't my fault. More fool me for not bisecting it myself.
(This probably shows an opportunity to add a benchmark to the newly-established "runtime benchmarks" (rather than the compilation-time benchmarks that has classically focused on...)
After sleeping on this, I realized that there's no real reason to expect the worlds-worst-memset code which is the source of the slowdown to be totally optimized out with . And of course it isn't. This is also a substantial regression with optimizations.
Minimized from : This issue was introduced in the build, and so it is likely to be a result of the upgrade to LLVM 17 ().
I have bisected the LLVM pass to the pass on main. I'm trying to get a diff of before/after so I can start tracking down the exact location of the incorrect optimization.
The optimization transforms this switch lookup which appears to correspond to the : with only the calculation of and changing from: to: with the rest of the IR remaining unchanged. The transform of appears to be okay ( by 64 -by 6). The transform of introduces the issue because although the instruction is marked as , is equal to which is negative in the signed representation and so subtracting 128 does cause signed underflow.
The IR output from rustc without any optimization passes outputs is: Which appears correct to me. This suggests that the is being introduced in a later optimization pass. I'll continue bisecting when I get a chance.
Looks like this instruction is being generated by a pass that's run before the pass. Before : Which is correct. So the real errant pass is , it just doesn't cause incorrect x86 to be emitted until a later pass.
Looks like this issue is known and a fix is in progress upstream at
: Local docs: ! But has the same issue: Probably caused by: ()
It seems like this css rule: applies to this element: !. Before () this rule wouldn't have applied because it would've been contrained by instead of .
This also had some other side-effects here: ! The search results have top/bottom margins compared to the previous styling.
The second issue was fixed in I'm checking for the first one, unless you want to send a PR?
Hmm, sorry I didn't/don't have much time to dig into this more. I couldn't think of an immediate fix for this because it kinda looked non-trivial (to me) :/
Don't worry, I'll send a fix in the next hours then.
This compiles successfully with . It's possible that this regressed when the two features were separated. It's also possible that stabilizing never_type first will make this issue moot.
I'm very surprised that this is still open. can you add the I-nomiated flag please, if you think it's appropriate here? modify labels: T-compiler C-Bug
This only seems to occur with nightly features enabled, so I'm not sure it's supposed to be nominated. I'll mention it in the tracking issue though.
For clarity, the second call to ends up using the impl on . cc I had concerns about this kind of thing when these impls were being introduced but I thought I convinced myself that this kind of thing couldn't happen. Did something change in the way we designed these impls since then?
Possible solutions are to either remove the impl for or update to prevent it from invoking . Seems to me like the second is the better approach.
I believe the reason for the was because it was considered a good thing to require callers to explicitly pass references. I think we've actually gone back and forth on that a few times. Are we committed now to allowing callers to just say ?
Rust's runtime installs a signal handler to distinguish stack overflows from other faults. This requires using an alternate signal stack (), which we create with the default size . That's usually quite small, 8KB or so depending on the target, but it's still plenty for what the handler is doing. There's currently no guard page like we have on normal stacks. That alternate stack is shared by all signals for a thread, so if a user installs any other signal handler, and they opt in with the flag , they'll be limited to the same tiny stack. If their handler happens to be more involved and overflows that stack, it may silently clobber other memory. If we had a guard page on the signal stack, that would cause a process abort instead. This was reported to the Security Response WG with a reproducer in . However, after discussion we decided to treat this as a normal issue for a few reasons: Setting a custom signal handler requires code. Signal handlers already run in a quite constrained environment, e.g. . It's unusual to use for signals other than , and if you choose so, you also bear responsibility to make sure that stack suffices. Nevertheless, as a defensive measure, it's still a reasonable idea to map a guard page when Rust is creating its signal stack, so an unexpected overflow will abort rather than silently corrupting memory. For full protection, that would also depend on the guard page not being skipped, but not all targets have stack probes yet (). Thanks to for reporting this in accordance with our , even though we have decided not to treat this as a security issue at this time. cc
cc This is another reason we perhaps shouldn't be registering the signal handler... cc
hey everyone, I get this message from when is executed: It seems there are some backports still missing for beta, since I can fix this by reverting locally, and there are some subsequent fixes in nightly who seemed to have fixed the issue for good. So, is there somewhere a list of the nightly backports needed to fix this problem? Thanks.
can I ping you on this? Beta is not compiling on gentoo, I assume at least one patch from nightly still needs to be backported to beta.
There is that should have fixed that and it's .
Hi, I'm on latest beta from last week. If I apply locally and compile, I get access denied error:
Logs says you don't have permission to put files into path from your build configuration. Without you would still get permission error.
I believe this is a sandbox error, so x.py install tries to write to / instead of it's prefix, and this is caused either by or it was already introduced by the older If I revert them both locally, I get a working x.py install
Interesting :thinking: Can you share your build configuration?
it basically does this: which translates to: and the patch seems to make x.py ignore the DESTDIR="" command In the rust context, the build config you asked me to share is the Have it attached for you, please feel free to ask for any additional information. also I can provide you with the full build log:
Did you wait for whole process(x.py install) to be finished? I don't understand how mkdir gets you into access denied error for path while you can actually create dirs/files in it..
Maybe there is some confusion about relative and absolute path? The access denied error is valid, as x.py never should mess with /usr/lib/ in install, but use /var/tmp/portage/dev-lang/rust-1.74.0_beta/image/ as it's prefix, if you want to name it like that.
True, there is a confusion between prefix and DESTDIR right now. I will fix it today.
Thank you, I'm happy to test any patch before you commit it to master.
You can test
yes this works for me, please also beta nominate
has this been beta-nominated? I'm new to this process, it's just I can't see a rollup pullrequest anywhere and the release of 1.74.0 is coming closer every day.
<!-- 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: note the duplicate <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
feature, not a bug: we want people to be very strongly discouraged, so we say it twice.
the more repetions, the more discouraged. lang_items should go up to 10.
Maybe we should print it in an infinite loop, just to be on the save side?
This is happening on as well.
claim The source of the problem is the decorator for which is adding two to the Diagnostic instead of one. I'm trying to dig further and decipher the marco-generated decorator code here: I also noticed that the behaviour seems to differ across gates. E.g. building this: emits one note for and two notes for : Not sure what's different about these gates. I'm new to this area, so if you can provide any pointers based on the above, please do.
This program tests all the internal gates: It produces the following output: Of the 21 internal gates, only the last 6 result in duplicate notes.
These should be more, there's a file somewhere that defines all the features but I can't check it right now on mobile
I think that should be all of them. This is super weird indeed, no idea
Thanks & I found what's different about gates with duplicate notes: they all have an associated issue. Here's the full list grepped from : Notice that the second last field in the last 6 lines is unlike the rest where it is . Apparently having an associated issue causes this problem.
The root cause is the being passed on this line: Its value is for gates that have an associated issue and for others. Since already has a attribute: this results in duplicates. The solution is to always pass for internal gates.
is useless () so skip it.
Neither of the macro chapters have sections for "common macros". Should we add one? Presumably there would be quite a few of them.
There is for the macros in std, plus some of the built-in syntax extensions. It's not that easy to find; there used to be a module in the rustdoc output but no longer :( I'm not sure exactly what should be documented where. The built-in syntax extensions like might deserve special mention, as they give you capabilities within that you otherwise would not have. cc
I think , , and also deserve mentions.
I would like to take on the task of documenting all the common macros. I've started them and appreciate some input on how big the final list should be, and if every macro needs an example (or three). What about the most common one, prinln! ? Should that be in there too?
It's not clear to me what doing this issue actually means. Moving some docs between some places?
The original issue was to add several common macro definitions with examples in TRPL, which I agreed with. I'm not sure what's up with the edits.
Trying to search for anything on results in a Javascript error: on line 313 of I'm on Chrome 30.0.1599.101 if that matters.
Weirdly, search results still appear if I search for most things, but not for anything starting with "sle" like "sleep".
This appears to be dying because of the method defined in . This shouldn't be showing up in the search because the entire module should be pruned as a result of it being private. This warrants more investigation...
Update: seems like it's not for "any" keyword as the OP states; for example or don't trigger any error for me. does for instance.
doesn't work either.
Happens to me too.
, , , , , , , and (and all shortened forms e.g. , ) don't work for me, but does work (i.e. shows results). The error I'm getting (on Firefox Nightly 29.0a1) is .
The error happens when a trait is implemented on a type that is pruned by one of the passes ( or ). The type was pruned but the implementation was not, so the search index included a method that referenced a missing type. fixes this.
See: This code: produces on latest stable (1.61.0).
Maybe we could form a heuristic around tokens that we know should eventually be followed by -- , , , etc. If we see one of those, (then some random other tokens), then we see , then that would be a suspicious rbrace which we could point out later.. e.g. if we see that triggers the heuristic, but not
The problem is that the error happens in the lexer, not the parser. Ideally we'd rework the lexer to have a token stream mode of operation instead of a token tree mode of operation, only for code that is being passed to the parser (i.e., not coming from a macro).
This is particularly confusing when the points to a macro: gives on 1.65.0-nightly (2022-08-31 )
the output now changed to: Do you think the should be removed?
This is changed to: it seems more helpful now.
Let's close this ticket after adding these two cases to the test suite then. I'm sure there are outstanding issues in this area, but we can hope that we'll get tickets for those more specific cases, while the tests keep us from regressing silently (hopefully, lets make sure the tests are fully annotated so its harder to do that by accident).
The example currently uses , but now that the macro has been stabilized in , it should probably use that instead. This should be an easy contribution for someone who wants to land a first contribution. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
hey can u help me from where i can fix this
Can u tell me how u solve this?
I have already solved this one and it is in the process of being reviewed for merging. If you wish to solve an issue, you need to pick one that has not been assigned yet. Try looking at this:
hey im new to open source, i want to grow in this field . Can i contact with u ?
I am pretty new to this project myself, but please reach out if you have any starter-questions and then I might be able to help you out. There is a chat on https://rust- - I am just "Mads Ravn" in there.
Thanks
The docs for  state: And include an example which uses to copy the value from an unaligned pointer into an aligned one. However, the docs for  state: Either the docs for are wrong, and does not need to be aligned, or the example for invokes UB and should be updated to use
cc (It's also notable that the example in is wrong when it uses as is seen if you move the statement out of the block; we should fix that ASAP)
Good catch! What we'd really want is , I think... we don't want an intermediate value on the stack. Feel free to suggest code that we can use instead. We have several doctests that need They have been there since 1.0 and longer, probably. But nobody listens to me when I say that there is existing code that we need to support ASAP.
The example given is just using to put it on the stack anyway. If you're having to copy the value at all, there's really no reason to use at that point, since the only reason to use it instead of is to avoid the copy (which is optimized out in release mode anyway). I think we can probably just remove the unaligned example entirely and change the documentation to read: I think we should probably mention the caveat WRT the optimizer eliminating the copy (or can it even do that in this case? The docs mention that the drop glue generated for packed structs does this copy automatically, I'm curious if it's doing so in a way that is UB or if the copy is just the price you have to pay here. It's also worth noting that there's no way to an unsized value through an unaligned pointer, but I'm not sure that's worth bringing up at all in the docs, since there's no reasonable way to actually get that pointer in the first place.
Oh, good point. Yeah then you can basically just make it , right? I wonder why / ever got used here? Well but wouldn't it make sense for that text to come with an example? It cannot, because then it would be introducing alignment errors. Uh... yeah. With it could work. Doesn't seem like a reasonable thing to have either way?
Presumably because they wanted the example to continue to use Sure, we could -- it just wouldn't ever call the function being documented.
Yes, it's just unrelated to dropping unaligned pointers since the only place you can reasonably copy them to is the stack. Unless you happen to already have an valid pointer of the proper size and alignment sitting around
I'm not actually sure unalgined DSTs are so unreasonable. For example, is only stopped by this rule: Which could be solved if we had e.g. a way to express "does not have drop glue" as a bound ( doesn't work for obvious reasons). In any case, I think "copy unaligned" functions make sense but we might want to consider multiple variants for src only / dest only / both unaligned. This can be expressed in LLVM IR though in a brief test I couldn't demonstrate that it currently makes a codegen difference (but I could only try on x86_64, where alignment rarely matters for codegen).
:rofl: fair. I guess all of this is basically saying an in-place drop of unaligned data is just not possible. Do an "out-of-place" drop instead.
Actually looks like the use of an unaligned pointer in the doctest just caused to fail to land. ;)
Proposed fix at
I tried this code: I expected to see this happen: “error[E0658]: the type is experimental” Instead, this happened: Successful compilation, as long as I'm using a nightly compiler, but the error when on stable 1.75. This is incorrect because nightly features should always require attributes on nightly (until they're stabilized, which hasn't happened yet for ). <!-- 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. --: label +F-never_type +requires-nightly
searched nightlies: from nightly-2023-11-11 to nightly-2024-02-01 regressed nightly: nightly-2024-01-27 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsThen, bisecting Manually verified that reverting (as ) restored the error. cc
Not sure to understand why fixing the visitor implementation introduced this bug. Maybe it highlighted a limitation? Gonna check.
Ok I think I know why: implementation of the not calling the equivalent function. Checking where it is used.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Fix was already approved in . Waiting for CI to be unlocked.