jiebi/CodeConvo huggingface dataset:
Btw, also exists. does not have array/slice projection functions though and they would be wrong due to the counts, so overlapping probably truly are not a thing.
At the very least, an argument that aren't allowed to overlap is easier to defend than that aren't allowed to overlap. Plus also, doesn't have guaranteed layout in the first place, so any example using tuples is (currently) implementation-detail-tied even before hitting . You could still construct an example using only types, of course; just replace the tuple with an actual type. You could even make it . As I understand it, there's three main cases here. ping two nonoverlapping is fine. ping two partially overlapping without any bound on has a sound, if surprising, definition, where the nonoverlapping part of the arrays are swapped. ping two partially overlapping unknown is unsound in any definition, unless both has no safety invariants and the overlapping portion is . The third case is obviously the most restricting one, and is defined on . To expound on first of the two subissues: Consider a type with the extra safety invariant that the second must be double the first . could even be . It would be valid to create two from , as you'd have and . There is no possible definition of (other than a no-op) which preserves the safety invariant. And of course the impl doesn't even know about the safety invariant. I could probably create an even worse example using underaligned types and relying on a specific endianness, perhaps even accidentally breaking validity invariants (think around partially overlapping ). The only two resolutions I'm confident in are making always panic for overlapping cells (because there could be safety invariants being broken) or forbidding overlapping s to -compatible types (optionally: that would be broken by ). And I don't like the subtle implications of the latter (e.g. being unsound for unbound ).
I don't think would be immediately unsound, you would still need a way to create overlapping s.
In particular, they certainly can only overlap in restricted ways -- if they overlap such that one's sits on the other's , I can already cause UB without just by storing into that and then reading it as a . Oh I see... to only swap the non-overlapping parts we have to make an argument that these parts have the same type (safety+validity invariant).
Which... seems utterly bogus now that I think about it. Worse, the invariant could correlate the overlapping with the non-overlapping part, as in your example. (Removed a whole bunch of nonsense where I try to find some special cases that work.) Yeah we should make it panic.^^ It is unsound to create an to these though, even without I can already violate the safety invariant here by setting the second reference to . Ergo this is not a problem for , we can already assume such references do not exist. I am confused, is there a negation missing somewhere in this sentence?
Fair. I'm fairly confident that it'd be possible to come up with some safety invariant that a partial swap would break, though, with more data-dependent qualities. The parenthetical is an optional relaxation of the potential requirement (but at the cost of a lot of complexity).
But shouldn't it be forbidding overlapping s to -incompatible types? Not that I know what either of these things mean, but forbidding incompatible seems to make more sense than forbidding compatible.^^
Yeah, poor verbage. I meant roughly "forbidding overlapping s of types that can be used in (i.e. sized types)", with the optional extension of "only for those actually broken by " (however that would be defined).
that partially overlapping s through an enum is problematic even without :
Enums isn't really the same thing. That enum projections are unsound , but as also discussed in that article, struct projections are typically ok, and the array projection discussed here is essentially a struct projection, not an enum projection.
I would like to bring up my crate  which allows projecting through using a macro. example usage: Note: doesn't allow projecting through enums for exactly the reasons that explained. I'm not sure how could interact with to produce bad behavior, because you can only project to fields, which can't be swapped with their parent, but just in case someone else finds something interesting. i.e. This isn't possible, so it's not possible to project through to a field that's the same type as the parent. Alongside the fact that all fields are disjoint means that cell-project should only produce overlapping if they are also .
I agree with here. Sum types and product types are different, and really should commute around product types, i.e., ought to be sound.
You can use , which led me to this issue (it'd be good if we could support field projection inside of and ).
While you could use to check that the tuple layout conforms to the C-like layout needed to do such projection, I don't see how your specific use of would lead to two partially overlapping though. Note that the problem is not with projecting to a single field, but to a group/subset containing multiple fields (or like in the array/slice example, to a subarray/subslice with length ).
Oh I see, you're right. False alarm.
While reviewing I noticed for the first time that the improperctypes lint normalizes with the "revealall" mode. I don't have a nuanced understanding of what that means exactly but based on the general description in the rustc docs and experimentation (see below) I think that's probably the wrong choice for this lint, because it exposes details to the user that are normally hidden during type checking. For example, using existential types, the lint pierces through otherwise-opaque existentials to look at the underlying (hidden) type, thus it both accepts code that is only FFI-safe because of the particular type underlying the existential, which users of that type shouldn't know or rely on leaks the underlying type to the user in error messages when (correctly) rejecting uses of an existential type as FFI-unsafe I can't quickly find an equivalent using only stable , because we don't have , but if there's a way to write "Option of the return type of this function" in stable Rust, then that would presumably have the same issue. cc for fact-checking my understanding that this is because of reveal_all
User-facing diagnostics should avoid the mode, yeah. In fact, the other variant of is literally - also the doc comments are pretty explicit about this: cc
I've been using 's over in recent PRs that modify the lint (see , , and ). In each recent PR, I've ensured that opaque types are prohibited (in the spirit of "FFI-safety of a type not relying on particular type behind an opaque type being FFI-safe") - with the exception of when a opaque type is used in a projection (). Unless there are specific examples of behavior that still need to be changed as a result of this issue - should this issue be closed?
My litmus test for closing this would be "all the normalizing done in improper_ctypes uses ", which is hard to audit for while there's multiple PRs in flight that address parts of the problem. After those PRs are all merged, we can see if there's any remaining and if so, their location should tell us how to exercise any remaining questionable behavior.
I've opened to fix the remaining two places that is used now that the other PRs have landed.
<!-- 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
Another regression of cc
Before I create a fix: is an expected/reasonable value in this ? I.e. is the right fix here just to allow ?
I don't think so. Actually just looked, think it's because we're not erasing properly. Let me put up a quick fix.
It would be more helpful to suggest the method for the typo rather than a nightly-only symbol which isn't actually available. the suggestion doesn't work. method is actually available on a . method has been stable since 1.0.0. had trouble noticing the difference between and and could have used the compiler's help. No response Reproduced with 1.68.0 stable and 1.70 nightly. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim
The title already says it, but as an illustrating example you can have a look at Since &mut T can be implicitly converted to *mut T, I wondered whether there's a reason that it doesn't work for &mut &mut T (besides "no one has implemented it" :smile: ). pointed out that this might be (in IRC). The example code also illustrates a somewhat unexpected failure of type inference, which might be worth filing as a separate issue.
Hmm... take the following: Rust will currently complain about mismatched types for the second coercion. It's not clear such a coercion should exist: it's like converting a to a .
Note that first coercing to instead of seems to work ().
Your testcase is constructing a , not a .
Ah, thanks for pointing that out.
In don't know if I understand your point, but if you argue that such a coercion should not exist because it might be unsafe, the line in my original example shows that this conversion is already possible in safe code.
Heh, C++ has special rules for multi-level pointer conversions exactly to prevent these kinds of type unsafeties: "More qualified" relations can be translated to Rust's // relations.
isn't doing the same thing: the outer is actually constructing a temporary, so you end up with an (as opposed to a ). Also, safety isn't really relevant; we allow arbitrary explicit pointer casts anyway.
Oh, wait, I see, you expect the original to interpreted as , and then converted from there to . That makes sense.
I think this would work if borrow expressions would take into account that they might get coerced later and pass down the from (where here), instead of only working for .
Triage: this still reproduces.
Closing this as the bug is fixed and playground link above works for all editions.
The playground link had the problematic line commented out: It still gives a compile error:
oops my bad then
This idea has been suggested. A T-compiler member has pointed out that other languages apply rules to restrain pointer coercion, specifically because multi-level pointer coercion is prone to being a bit of a footgun. Not quite "this is a bad idea", but despite the simplicity of the proposal, it deserves being treated with caution. There is no strong argument that this is a bug because it is consistent, if annoying.
In 1.12, figures out which libraries it needs for external LLVM using which breaks if you have LLVM with and (which is needed for clang 3.9 these days), since then there is a dynamic and lots of , but the code sees the and decides it has to link statically, which fails. The code should decide whether to link static or dynamic first, and then call resp , to get the correct library name.
Thanks for the report! Sounds like it should be a relatively easy bug to tackle as well!
In Void, we work around it by just adding , I guess for a general fix you need some policy how to link it.
Oh we basically always want to link LLVM statically, so we can probably just always pass it.
We emphatically don't want that in distro builds. Would you accept a patch to make this conditional?
certainly!
When there was a change in a or other non-rust file, bootstrap tries to format it, which makes rustfmt very sad. cc and who broke this in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think we just need to filter .rs files before passing them to rustfmt.
This will probably be hit a lot by contributors so I'll pin it for better visibility.
claim
Normally, the walker already filters for files, per Maybe the crate docs are not fully up to date, or I didn't understand them correctly.
The workaround is to run (notice the dot at the end of the command).
I think if we add it like this: will always not ignore it anymore.
Maybe try to put the part I before the ignore part, maybe this makes the ignore list work again? The thing that intrigues me the most is the fact that the files are not ignored later by the file type filter.
For any Rust files we changed locally, our current solution will try to format it, in some scenarios we may not want to format it, such as some files in UI?
Seems right, my current fix is not completed.
I think since you explicitly add the files to , that overrides the types filter.
from my local experiment, seems is still expected, I changed some files which ignored in , they are actually not sent to formatter:
WG-prioritization assigning priority (). label -I-prioritize +P-high
The following code works in 1.56.0 but crashes 1.57.0 as well as the most recent nightly &mdash; . <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
According to cargo-bisect-rustc the regression is from &mdash; FYI regressed nightly: nightly-2021-09-06 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Seems that this is duplicate of and ; only triggers with incremental compilation enabled. Unfortunately although I authored the original PR, I don't know a lot about incr-comp or the query system to diagnostic the issue. label: +A-incr-comp
Found the bug, I'll put up a PR in a sec. claim
reopening as this is a stable-to-stable regression, and (I think) we keep those open until a fix lands on stable or we explicitly decline to fix.
was this backported / can we close the issue? :)
The fix was backported and released in 1.58.0
Perfect, thanks for checking !
The Unicode Windows API internally works with (potentially ill-formed) UTF-16 paths that must be converted to from Rust's UTF-8 strings. The conversion happens here: does the translation from WTF-8 to UTF-16, leaving a with . The following calling to will then allocate to reserve additional memory for the null-terminating character. This could be resolved in two ways: 1) Call beforehand and then call on EncodeWide. 2) Make a wrapper around that increases by one. Incorporating the final null byte into would add a performance penalty, therefore it would probably be desirable to just adjust the sizehint by one and adding the null-terminator manually. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
In the interest of enumerating possibilities, there's also using (hopefully this will optimize): Or we could test the for nulls before converting.
That's a good idea! Chain actually gives an example for windows paths: Although I'm not sure what's more efficient here, std::iter::once or [0]? Allocations are quite expensive so I believe the additional check (if it's not optimized away) would be worth it. However I also discovered a deeper issue. The sizehint that originates from the WTF-8 iterator is in UTF-32 code points. The lower bound will be (assuming that all code points are U+ or higher), the upper bound is (everything is "ASCII"). When collecting into a vector, the lower bound is chosen as an initial capacity. Since you almost never encounter paths that consists of U+ characters only, the estimated lower bound will always be too low and 4 allocations are required if the path is ASCII only, 2 allocations are required if the path is UTF-16 only, and 1 allocation is required if the path is UTF-32 only. It might be worth a consideration whether to call , as that would be a sane default (on the assumption that the majority of paths are UTF-8). However, this might waste some memory, do we have any idea on whether paths created from this function are primarily used ephemerally?
I believe all uses of are currently ephemeral.
We tend to use it only for as long as necessary to call a Windows API. There are a few places we keep wide strings around longer but those don't use as far as I can tell.
In light of that, I believe that the first solution would be the best. Solution number two would make naming very awkward (EncodeWideWithNul?). And while your solution is very elegant and correct, it would still mostly under-allocate given the interaction between size_hint's lower bound and collect. However, I find both solution 1 and solution 3 acceptable. It would be good to know how much reallocation actually costs and if it even matters at all in the context of interacting with expensive IO.
I do agree implementing solution 1 would be a good idea. Having some good performance numbers would be great but I do suspect reducing allocations would be a win here. I would also like us to use stack buffers more, similar to . and only use new allocations when necessary. But that's perhaps another issue.
Reducing via stack buffers is a good idea, but I think it's out of scope for this issue. For now let's just reduce regular allocations, that should already give us some improvement! I'll try to see if I can implement this one. claim
Fixed by
When I tested 1.40.0-beta.5 on , never completed on . When I run that test on arm directly, I get: The same happens when I use official builds of Rust 1.40-beta and 1.41-nightly, so it's not just a problem with Fedora's build of rustc or LLVM. This test didn't exist before , but running 1.39 on the current test just fails even earlier, as expected, "entered unreachable code: catch_unwind should not have caught foreign exception." I tried compiling the C++ part with GCC 9.2.1 and Clang 9.0.0, both with the same result. That's using libstdc++ either way though, because we don't have LLVM's libc++ available. cc
cc
PS: while I initially saw this on Fedora rawhide, my followup testing has been on stable Fedora 31.
That is very strange. And this behavior only occurs on ARM? I'm tempted to say that this is a bug in GCC's unwinder (in libgcc). Can you try this C++-only code to see if it has the same issue? a.cpp b.cpp This should print the message once and then fail with an uncaught exception.
Yes, the other arches completed and passed that test. Needs for , but then it works:
I tried stable 1.39 again commenting out the call to , then gets stuck in the same "caught foreign exception in catch" loop on the C++ side. In fact, this happens on every compiler I tried back to 1.13, which is the earliest I could get working at all! So at least it's not a new problem. Maybe we're generating bad unwind data, or maybe my libgcc has a bug in handling foreign exceptions, I don't know...
I think this might be a bug in the way the personality routine in libstdc++ (libsupc++ actually) handles foreign exceptions on ARM. Can you try using libc++ instead of libstdc++? Just change the linker args for rustc from to .
Oh, I found that Fedora does have libc++ packaged, and . But when I tried to use it simply as you indicate, foreign exceptions don't seem to be caught at all, in either direction.
I see the binary still gets linked implicitly though, I think because adds it to std. I'll try to get a full build of rustc with just libc++ instead.
It's fine to link to , since that contains the libunwind implementation. The actual C++ personality functions are in libstd++/libc++abi. Can you post the test output with libc++?
Maybe this is obvious, but I have to compile the C++ part with clang++, not g++, or it gets "undefined reference to ". I wasn't sure whether to also use , but either way the C++ exception is not caught by Rust: So I commented out again to just try :
you may need to explicitly link libcxxabi depending on how libcxx was built. That should fix undefined reference error.
I did use -- do you mean more than that? If anyone else is interested in arm-linux, it would be great to get more hands on this, because that target is not a high priority for me. I will probably disable this test for arm in Fedora in the meantime.
I managed to reproduce this on Arch Linux with , so it's definitely not a Fedora-only issue.
no, that should be fine. Guess passing to the Clang (supported since 9.0.0) doesn't help either?
The link error was only when using g++ to compile That much was ok with clang++. I just tried adding to the clang command too, but got "argument unused during compilation".
I'm hitting this on Debian too. Running by itself does result in infinite-loop printing however the rust test suite is actually running . Directly running this however exits immediately, so I don't know why the test is hanging. I'll see if I can grab the environment from next time.
Ah nvmd, I just had to wrap the thing in single-quotes to reproduce the loop, the output of "pstree" is misleading.
Since this test is new in 1.40 I'll just for the time being in Debian.
Should be fixed by
<!-- 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: ! Instead, this happened: ! This is issue from First screenshot is of and second is of
Probably , it shouldn't have affected glob re-exports but maybe did (cc
Taking a look.
Same issue with a simple reexport:
That's what was meant to do, it wasn't meant to affect globs though.
I think there is another issue with how it's handled because nothing is listed on the item itself too: !
Ok so it's the expected output for a non-glob reexport. I wrote the fix for glob reexports, just need to add tests.
Latest nightly fixed the issue for but it didn't fix the issue for . In latest nightly below example doesn't work its last working version was also .
Noted. Sending a fix for it as well. :)
Fixed in
When I do , it says: Strangely, when I do , it uses the correct name: No idea how it is even possible for this tool to have two different names inside bootstrap...
I think this is just because cargo-miri's tool check step is generated through a macro this macro generates the check message via there's a in there too. The build step has a different name because that macro explicitly asks for a display name
If I make the macro use a display name,
Ah, I didn't realize those two steps were defined entirely independently.
Anyway, should make this more consistent.
should always return . But it doesn't if you enable the lvi-cfi feature. The miscompilation only happens with opt-level=0. Compare: Here's a slightly reduced LLVM IR: Difference in output when adjusting the lvi-cfi feature attribute on : . I can't really see any obvious culprits. I want to file an LLVM bug as well but I don't have an account. cc
I think the Rust calling convention may be using whereas LVI-CFI assumes it's unused?
Actually you can see the issue in the assembly diff I posted, lines 45-51.
I've filed an LLVM bug now based on this reduced example:
Do you have a testcase that reproduces this problem? Also, what version of rustc are you using?
I'm sorry late for your comment. $ rustc this is bad my code. : : rustc 0.6 ( 2013-01-20 20:35:24 -0800)
From my cursory glance, multibyte characters (Hangul in this case) seem to cause this bug.
Not critical for 0.6; removing milestone
Seems to be fixed. Checking in a test case.
Done pending
Test case in , closing