jiebi/CodeConvo huggingface dataset:
The function itself is considered FFI-safe and does not trigger the warning (). Its function pointer should also be allowed, to be consistent. Discovered on CI The original code has several more levels of indirection, but is also considered FFI-safe before. <details<summaryExtracted original code</summary</detailsAccording to CI logs, the warning occurs since rust 1.72.0-nightly ( 2023-07-03). Probably caused by . cc
Okay, so, I had a fix for this that just got rid of the regression, but I'm not sure that's the correct solution here - I think this is correct to be linting in the fn-ptr case and should be linting for the function case. is FFI-unsafe, but we allow a function to return because that's the default, but that doesn't mean that a within a type is okay (with the exception of a wrapper around the - because that's just returning , which we've already decided is okay). In the function case that works right now, that's being allowed because of this code.. ..which is there to support the case. However, it's not quite the right check. It doesn't actually check for ! It checks that the type - however nested - which was deemed FFI-unsafe is and that type is part of a return type. So any FFI-unsafe in a return type makes the entire return type FFI-safe - which is clearly incorrect. That's making the example below compile, which absolutely shouldn't. I've submitted , which makes this even more of a regression by making the function case fail too. We already had a simple "is it a unit" check, so I extended that to check for transparent newtype wrappers too, and removed the incorrect check.
This is unfortunate since I'm trying to return a where is likely to be . What should I do instead if I want to be FFI-safe with layout ?
I'm not so sure anymore after reading comment (). It's clear that some changes are required regardless - our current implementation wrong as demonstrated in the final example from my previous comment, but it's also inconsistent, in that this example... lint for the argument use of , but not the return use of , when really it should be both or neither. After my pull request, it's both.
With and without my pull request, when you change this to , it doesn't lint.
I'll nominate this issue so that it sees some discussion - see also and .
I posted some more info on zulip but it may also worth mentioning here. ZST is still zero-sized under repr(C), rather than FFI-unsafe.
The issue now also exists in beta. I also found uitests which seems to expect ZST to be FFI-safe, but ends in to suppress the warning and tests nothing.
We discussed this in today's meeting. We didn't have consensus that this should warn; at least some people thought the code in the top comment should continue to compile without warnings. We did have consensus that changing that (to warn) would need an FCP. So, we felt that we'd like to see a fix removing the warning applied to beta and nightly, and then separately if someone wants to propose that we change this to warn, we could evaluate that and do an FCP on it. But at the moment the temperature of the team seems to be that we don't have consensus for such an FCP.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
labels -I-lang-nominated We rendered our opinion
I came across this while working on . Sadly I wasn't really able to minimize this. this branch: and go to (but other commits will likely work too). to and paste in the following:
See also
Slightly minimized: place in Then run: will produce the ICE.
Caused by , cc That PR renames a lot of diagnostic items, but didn't use to gate the name change, so causes breakage when compiling stage 0 std or stage 1 compiler.
Oops, sorry!
<!-- [31mICE[0m: Rustc '-Znext-solver=coherence -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'internal error: entered unreachable code: Weak and Inherent aliases should have been normalized away already'', 'thread 'rustc' panicked at 'internal error: entered unreachable code: Weak and Inherent aliases should have been normalized away already'' 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: [specializationgraphof] building specialization graph of trait [coherent_trait] coherence checking all impls of trait [analysis] running analysis passes on this crate --
cc
Actually what happens here is the following: The tuple you create in is moved, because it is not . When you perform the you move out of , into , leaving uninitialized. Your assignment to is basically to uninitialized memory, and doesn't have an effect. When you perform the assertion you see the old value of , because your assignment to had no effect. The whole thing is confusing because Rust does not warn when you perform useless assignments to moved variables, and it probably should. The whole thing becomes obviously when you add a statement that uses in the match arm: Edit: the labels you have assigned to this issue are incorrect.
Don't we see the new value , even though we're accessing , when performing the assertion, which causes it to fail? Doing this without a match statement passes the same assertion sucessfully:
Oops, you are correct, I am mistaken :( , mitaa wrote:
heh, I made the same mistake. Typed out most of a response and then realised that I'd mis-read the code.
<!-- 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
Regression in
I think it's enough to change to be without .
<!-- 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. --: In case it helps, when using the stable toolchain, the compiler does not panic but instead emits this error: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Bisected to . CC searched nightlies: from nightly-2021-10-01 to nightly-2021-11-25 regressed nightly: nightly-2021-11-23 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: aarch64-apple-darwin Reproduce with: </details label regression-from-stable-to-nightly
I can fix this quickly -- seems like just changing an to a since the can be out of bounds. claim
(only tangentially related) I also noticed a regression in error spans between stable and beta... stable: beta:
That was an intentional change, meant to highlight the fact that the attempted mutable borrow is occurring because of the method call. However, it seems to be confusing for a lot of people, so I'll look into improving it.
Ah thanks for letting me know. Maybe we can split the span up into the receiver and the method, and add a note on the latter like "due to this method which takes &mut self". Not sure if that much info bubbles down into borrowck. I'd be interested in making that change if you've got a lot on your plate and it's (relatively) easy to do.
See for discussion about this exact idea. It'd be nice, but likely hard to implement.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
It have something to do with incremental build :( seems to point to random function sometimes even in file that was not edited for weeks. Issue started today. Deleting folder help for few compilations. I do not use latest compiler because some problems with crate upgrades and incompatibilities with async/await! so the issue is not caused by the compiler version, because I use same version for a while, but it is triggered by something in my code. Is there anything I can look for in my code that could cause these issues?
Remember what you've done between cleaning and ICEing. (maybe auto git commit every save or similar ^^). In my case it was just renaming a variable from to which causes an ICE.
when I think backward it first appeared when I add crate slotmap, and with that crate I was able to reproduce it even with 2 lines edit to their simplest example, so at that point I think it is caused by the crate and removed it and it was fine for a while, I chose to use CHashMap that solve some problems for me. I can not say after which change it reappear.
I want to know if I could use as key because I already have unique so I try to implement trait for struct containing only get error, so I tried to replace their key and still get the error, and when I commented out it compile, I tried few other combinations, but compiler panicked a lot, so I decided it is not the crate I want and removed it prom my project.
triage: I'm going to mark this as P-high, but it might be more of a "medium" bug. It's a bit hard to say. I think there are few bits of info that would be useful: First and foremost, a more concrete recipe for reproducing the problem, ideally with a standalone example Second, some idea if this is a regression -- did the problem only start recently?
For the first question: I am on windows 10 Pro 1809, CPU 1950X, 64 GB RAM and steps to reproduce are simple for me: start IntelliJ IDEA new rust project to add replace withbuild add as mentioned above build ~50% chance it fail if the build worked just rename build failed 5 of 6 times I get that far without deleting folder For the second question yes it started recently when I tried this crate, but more importantly the issue persisted after I removed it, it is just much less common than every second build.
Sadly I cannot reproduce it. Let me try to summarize it: as dependency in (hope it crashes) not, use Am I correct? Please be as precice as possible and clarify "just rename ". Do you want me to change lower/upper case? Remove one character? Add one? Your nightly seems kind of outdated. Is it still possible for you if you use the latest nightly? (I tried both, no luck)
It seems that it has been fixed on latest nightly, but I'm now able to reproduce it 100% with nightly-2019-04-05 (). new project as dependency in build in front of build in front of again
I would suggest to remove the P-High and I-nomiated tag, because it is fixed on nightly. I'll add the E-needstest tag. I just have to reduce the above example without external dependencies. Lets see what I can do. modify labels: E-needstest
Thanks a lot for looking into this, can you confirm that the crash doesn't occur anymore with the latest nightly compiler?
After a lot of effort I switched toolchain to and it seems to work here (over 20 rebuilds without error)
please do not close this issue. I created a PR which will automatically close this when it has been merged. Please reopen it
This is likely caused by and fixed by
Can confirm that the bug has been fixed in (bisecting ftw)
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'called on an value: failed while formatting fluent string : '', 'thread 'rustc' panicked at 'called on an value: failed while formatting fluent string : '' 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: --
Slightly smaller:
cc
Somehow this subdiag enum being to a diagnostic causes but the looks okay to me...?
Also suspicious:
Seems like for the subdiag whose fluent messages contain a variable, they need to be eagerly translated via instead of using . However I'm not very familiar with this distinction.
fails this test on native : (This is not a new failure, but I am cleaning up issues from downstream Red Hat bugzilla.)
We started discussing this in , and looking at the clang implementation here: I tried that minimal step with , but it still gives the same "Cannot select" error. I don't see any lowering of in like other targets, only stuff implementing the calling convention. So I guess we do need custom support, or perhaps the clang bits could be moved down into the LLVM lowering?
Hi , I ran into the same problem and noticed you had already opened an issue. I've now submitted a PR to implement valist and vaarg for s390x to fix this.
In RustCrypto crates we use which changes style depending on preferred theme using CSS rules. You can see the for an example which uses it. But the problem is how the logo gets rendered on dark themes: ! ! The reason for such horrible result is the white shadow filter applied to the logo. I understand why it was , but I think it's a wrong approach, especially for projects which aim to properly support dark themes in their media files.
There was a mention back when this was implemented about how it is not possible for a media query approach to work, when I look at the sha2 docs it looks like ! because I use a light theme generally in my browser, but have rustdoc explicitly set to a dark theme. I'm confused why the outline is being applied to these docs though, was meant to only apply it to the default rust logo, and I don't see any relevant newer PRs when searching for .
I believe I broke this in In we are supposed to apply the class only when the logo is the default one. In I missed that distinction and now the always gets the rust-logo class, even when it's a custom logo. I'll fix.
By the way, to confirm what said: the media query embedded in the SVG isn't really right. That gets the browser's preferred light/dark mode, but the user may have overridden that in rustdoc settings. As a concrete example, I'm using Chrome on Linux, which doesn't have a light/dark mode setting. I can select a dark theme in rustdoc settings, which will get me this for the Rust Crypto logo (with applied): ! That's still an improvement over the status quo, and overall I think it's fine. But if we really wanted to support theme-sensitive logos perfectly, I think we'd need to offer separate configuration options for a light logo and a dark logo.
I believe that the media query approach is a correct one in principle. But I agree that, unfortunately, the current state of browsers is far from ideal, e.g. it would be nice to have a way to switch preferred mode for a page using CSS or JS. I'm using Chrome on Linux, which doesn't have a light/dark mode setting Well, it kind of has. Try launching it with (I don't have Chrome installed, but I think it should work similarly).
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: could not unify with revealed type:', 'error: internal compiler error: could not unify with revealed type:' 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: [checkwellformed] checking that is well-formed [checkmodtype_wf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
crashes since cc
Note: ICEs aren't crashes, we have a separate label for crashes (they mean segfaults and similar)
ungraceful exit of the compiler has been observed since :upsidedownface:
This has nothing to do with non-lifetime binders. I somewhat expect that when a "minimized" repro is tagged with a feature tag, there has been an attempt to check that the ICE is actually dependent on the feature, since that affects the prioritization of the issue.
mdbook v4.6+ has a feature that pressing ESC removes query components from URLs (for example ). The feature was implemented in rust-lang/mdBook. It would be nice if rustdoc offers the same kind of that feature. This is, for example, an URL that contains query components in rustdoc: When users share URLs to an API, they don't have to remove the query manually.
could you share some thoughts about this feature request? If possible, could you mentor contributors how to implement this ?
I think it's a good idea. Gonna take a look at how to do it.
Can we reopen this issue ? I think only removes the query component when we remove keywords in search bar. This issue is about adding a keyboard shortcut.
Oh I see, my bad. Reopening!
<!-- 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. --Nightly 2022-08-11 worked fine, trying to upgrade from it. : <details<summary<strongBacktrace</strong</summary<p</p</details
, same rustc version
label E-needs-mcve -T-compiler +T-rustdoc
Error: Label needs-mcve 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.
I don't have a MCVE but the same problem on the same nightly version happens with a dependency of . Sounds awfully similar to also involving deps, but that one's definitely fixed.
Pinging since they're the last one who worked on this. Maybe you have an idea?
Somewhat minimal example: Removing the impl avoids the bug.
This happens with beta too:
Fixed in
Enable "Directly go to item in search if there is only one result" option on Settings ! Search an unique item in search box generated by rustdoc, it will lead you to the doc of that item. Click the go back button in browser, the page will change to previous search result and go forward to the doc of the searched item. How to reproduce the issue: Go to std doc: Search for "PhantomData" Click the go back button in browser. : 1.47.0-nightly ( 2020-08-20) cc
Well, you can but since there is only one result, it puts you back haha. (Ok, we can consider it as bug, but it's a funny one)
The single search result page can be elided using the to disappear it, leaving the back button to take you to before the search. I believe this would be the desired behavior?
What about detecting the key release to check if there's a single item and redirect, instead of redirecting after calculating the results?
Since , has been distributed in the component in two locations: (presumably as a runtime dependency of ) (not sure, maybe for linking custom drivers?) likely belongs in the component, if the duplication can't be avoided <hr/The difference can be seen in these consecutive nightlies' components: has just the second maybe it's used via relative by ? separate codegen backends are gone, maybe we should just try removing it? first nightly to include has both copies All 3 of those files are identical (even across nightlies, yay for deterministic builds): One fascinating aspect is that the size only increases from to , despite alone being uncompressed, so compression is really helping. Even the only goes from to . (I'm using archive sizes from the and directory listings in , FWIW) <hr/This part of the build system seems relevant, but I'm not sure which of the two this creates: cc
cc -- you've touched code related to this a bunch recently I think, so maybe would have some time to investigate fixing this. I suspect we want to only ship one LLVM per tarball, at least, though ideally we would only have just the one LLVM library total as well.
Half-way through writing up this issue I realized the connection. I'd suggest we try to get rid of the copy and see what breaks, it's possible it's been dead weight for a while now. And only if we have to keep both for some odd reason, we'd move it to .
The purposely orders the tarred files so that similar filenames are adjacent in the compression stream, especially in hope of helping with such duplicate files. I think we may still want the copy for the odd cross-compiled tool using , but that definitely belongs in .
Is that... even possible? Is a per-target component in the same way is?
Yes it is -- try -- but I don't know if anyone really needs that...
Actually, can you try something like cross-compiling a copy of to , after deleting the per-target ? I suspect that it would actually run just fine on a host, because 's s should only really contain the information and maybe some object code that is missing (which we could get rid of if we kept MIR for everything but idk how feasible that is). That is, the result of linking against should still use at runtime, so in is unnecessary. But maybe I'm missing something.
Like running the cross-compiled on a host without anything more than the component?
Hmm, I can't actually get cross-builds to work with . I this to : ... so it would pick that up from the sysroot. Trying to cross-compile i686, I get: I do have both i686 and x8664 builds of in the sysroot. I suspect the error is because the i686 build has different metadata than my host build, so it can't find the one it wants for the host. That may mean that is really tied to being used on the same host. It works if I just compile native x86_64 though. Then I tried removing the , and it gets essentially the same error as : AFAICS, building normal crates still works fine with that extra removed though. In short: Cross-compiling with seems broken -- maybe it should be shipped native-only. The only difference would be in the manifest created for rustup. Linking to crates will inherit , so that needs to be in the library path.
Ah, fascinating. What happens if you build such an executable and then remove the component entirely? Can it pick up the dylibs outside or does it hardcode the paths inside?
The final executable still isn't actually linked to LLVM, since it didn't need any of those symbols: I can run this with , which set , or even if I set that path myself. But doesn't work if we've removed that library, since needs itself.
Okay, it being dependent on makes sense. Overall, probably the safe thing to do would be to move the duplicate to , oh well.
Oh, also needs LLVM, and those binaries are installed in with RUNPATH . I guess they might be able to find the LLVM in anyway?
<!-- 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: You need edition 2015 or 2018 to reproduce this. `
Looks to me like the problem is that doesn't realize that a makes the place not dead.
The bug is . is a nonuse, but should get the same treatment as a . I feel obligated to mention that I have repeatedly warned that these bugs are going to happen. We should really stop using in optimizations. It was written for borrowck. (To be clear: I am as much at fault for this as anyone, I originally wrote this code).
I was wondering why always has strangely unhelpful information for optimizations...
Why is this not just a bug in PlaceContext assignment?
See my comment in the PR - in general, my understanding is that the definition of placecontext is what it is because that's what makes sense in some other part of the compiler. If we start changing placecontext now to have the information that's useful to optimizations, I worry we'll just end up making those parts of the compiler buggy