jiebi/CodeConvo huggingface dataset:
It is probably possible for us to loosen this in the future, even after 1.0, though strictly speaking it would not be backwards compatible. (I guess a more limited fix would just be to change the variance of and specifically.) (The reason it is not 100% backwards compat is because impls that are not overlapping for an invariant trait can overlap for a contravariant trait; but this is unlikely to occur except for with object types.)
I plan to work around this problem for now by changing the definition of . The underlying issue has been splintered off into .
<!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc for ClashingExternDeclarations in backtrace.
claim
Thank you for fixing it! There is nothing better than software with only a few open issues.
Not a problem! Thank you for the report, and especially for taking the time to make a minimal example :)
Currently in , Rust is hooking into the glibc extension for retrieving / even in case Rust does not manage and is e.g. just loaded into a process as a . While this is great and convenient, it's unfortunately not implemented in a safe way. Various C commandline argument parsers are modifying while parsing, so the information that gets passed into might not be correct anymore. Examples of such parsers are glibc's own  parser, noting " The default is to permute the contents of argv while scanning it so that eventually all the non-options are at the end. This allows options to be given in any order, even with programs that were not written to expect this. " GLib's  parser, which removes all already handled arguments from and only leaves others (removed ones are set to and moved to the end). Qt does the same thing in in . It shuffles around arguments in and removes (by setting to ) arguments it handled already. This means that at least can easily be too big, and Rust would read beyond the (new) end of . This caused crashes in because of calling on when creating an around such an "removed" argument. Now the question is how this should be handled in Rust. I see three options here Remove the extension usage and handle glibc like all other libcs Copy all arguments in . This means everybody has to pay for that even if they don't use arguments, and this is theoretically still not safe if the shared library is loaded at the same time the array is modified and a partially written pointer value is read Handle pointers in by skipping over them. This means we would lose the exact length information of the iterator, and this is still theoretically not safe for the same reason as 2. See This code was in 2019 by (CC I've created as a proposed fix for this, which implements option 3. : <details<summaryBacktrace</summary<pAlso </p</details
Arguably swapping two entries of is still a lot less dangerous than setting one to NULL -- it seems totally legitimate to assume that there are no NULL pointers in , and does not insert any NULL there either. So what GLib does here is certainly questionable, more so than what does. That would be a data race.
However, just like multi-threaded programs cannot mutate the process environment or write to the global pointer ( is inherently unsafe if there are other threads; also see the discussion in ), I would argue that multi-threaded programs cannot mutate . Global state such as or is inherently read-only in a concurrent program; there is just no way to make mutation safe. So, I think for concurrent programs we can already assume that there are no concurrent mutations, and if there are then that is a bug in the code that performs the mutation. What remains is the question whether we should adjust the args handling to be able to deal with NULL pointers in .
The problem here is that this behaviour of GLib exists since literally decades, and I'm sure we'll find other commandline parsers that are doing similar things if we search a bit. My first reaction also was that this feels like something to fix in GLib, but that doesn't seem to be a practical resolution because of the above. Skipping over s seems to be a relatively cheap mitigation if we decide that concurrent modifications of are simply wrong (who even does that! also seems less likely than ).
I can't judge how common it is to add NULLs there, and don't have an opinion on whether we should support that -- let's see what says. If you know of another library doing this that could be useful, though GLib doing it for decades on its own already means this is quite wide-spread. I hope GLib does this before any threads are spawned, because otherwise I'm afraid that is just inherently doomed.
I'll search a bit later. An application could surely do that, but that's just asking for problems and I wouldn't really worry about that. The following would work around this FWIW. Maybe should be conditional on glibc.
nit: s/Same/Some
Qt does the same thing in in . It shuffles around arguments in and removes (by setting to ) arguments it handled already.
's library is not affected because it always copies each string directly into a vector and then operates on that.
Another approach would be parsing . Doesn't work if proc isn't available, but so do things like .
is created by the kernel reading from the original location of argv (as specified by the auxiliary vector). If you edit argv, so will the commandline reported by the kernel.
Skipping over NULL seems less safe; would it make sense to just stop at the first NULL?
To the best of my knowledge, it's completely valid to parse argv by stopping at the first NULL; if an argument parser is replacing an argument with NULL, it should not expect that arguments after that point will be seen. I've seen plenty of C programs that just do or equivalent.
For the commandline parsers from GLib and Qt that would be sufficient, yes. Considering the below, it seems OK to do that and there shouldn't really be any risk of missing useful arguments. TIL that is -terminated. Thanks for pointing that out :)
Steps to reproduce: Alternative steps to reproduce that will provides a suitable compiler: On OS X, with LLVM assertions disabled (like in rustc builds in , which are the default in Servo’s ), rustc 1.20.0-nightly ( 2017-06-28) fails with: This problem does not occur with from rustup, which has LLVM assertions enabled. (But perhaps that’s not the only difference between the two kinds of builds?)
What’s ?
It’s also enabled in the "non-alt" build, so probably not relevant.
Have you tried building the project in the same disk partition where you've installed rustc, i.e. inside ?
Yes. With the second set of steps (and ), the error message looks like this:
Does show anything special?
not as far I can tell.
Okay... There are for dyld but I doubt if they are useful. The problem is that is not found, meaning is not expanded properly. I've checked does not* have an load command, meaning the is only supplied through . I don't think the alt-build's and normal build's Cargo has any difference though. Verify if is correct?
with and without in : Both contain:
Both contains directly inside ? (not )
Almost, the one has a different hash:
Huh, that's even stranger. The should be resolved correctly. But the alt- rustc linked using the libstd from the non-alt-build??
Well it sounds unlikely to me that “from the other build” is really what’s going on, I’d bet on incorrect hashing. How is the hexadecimal part of determined? What base values are being hashed?
IIRC rustc will just search for all , it doesn't recompute the hash. Would it work if you move out of , and then do a + ?
I first hit the issue before the "non-alt" build was downloaded.
I've tried to reproduce it myself and it seems plays a role in finding which is linked. I can make it link to the correctly hashed by: "Install" it sure does not contain , and includes it. It should work. Overriding without installing causes rustc not able to find .
What is "it" and what does "installing" mean?
Run after extracting the tarball (sorry was on mobile so did not check the exact instruction).
What does this do besides copying the files?
Regardless, this is a regression, it only happens on OS X, and only with "alternate" builds…
It looks like the problem is presumably that and don't have the same hash. One fairly clear problem is that Servo for some reason doesn't download rust-std from alt by-default AFAICT; having some quick prints to the util script. That would lead to incompatibilities; this should be fixed.
I've filed which should fix this.
Good catch! This fixes the problem, thank you.
has an unusual format: it takes as it's first parameter where everything else in the trait takes . It should take as it's first parameter for consistency with everything else. It is located in 
+1. There are a few different things to consider here, though: does not operate on any FP number per se like most other operations do, but rather constructs a new FP number from two arguments one of which happens to be FP number. This function’s signature is consistent with most other methods that construct some kind of FP number (e.g. ). We might want to consider whether methods such as shouldn’t just go ahead and take instead. can’t currently be chained, but I see literally 0 cases where anybody would chain this function. cc
Okay, but from a consistency standpoint, it's like 1/80 for vs . It it keeps the same format, it and it's similar functions would probably be better to go at the end or beginning of the function list where they won't be so unusual.
Nominating for 1.0-beta P-backcompat-libs
One should be able to call this thing as a method, one way or another. We need to make sure that is resolved.
0 beta, P-backcompat-libs
I started to fix this.
<!-- 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. --Hey! I was trying to make it work somehow with , when the function depends on the other generic parameters. I came to this approach and encountered an ICE. <!-- 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. --: <details<summary<strongOutput</strong</summary<p</p</details
label requires-nightly F-typealiasimpl_trait
Regression in nightly-2023-02-22 Regression in cc
still crashing, rustc 1.77.0-nightly ( 2024-01-08)
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: node HirId(DefId(0:32 ~ 787F2C645D84C34B503984769364221101FF5A50720AF027A7CACDC71EA4474E[c98a]::insideconstgenericarguments::{constant}::checktrybindstighter).22) (pat ) cannot be placed in TypeckResults with hirowner DefId(0:22 ~ 787F2C645D84C34B503984769364221101FF5A50720AF027A7CACDC71EA4474E[c98a]::insideconstgenericarguments)', 'error: internal compiler error: node HirId(DefId(0:32 ~ 787F2C645D84C34B503984769364221101FF5A50720AF027A7CACDC71EA4474E[c98a]::insideconstgenericarguments::{constant}::checktrybindstighter).22) (pat ) cannot be placed in TypeckResults with hirowner DefId(0:22 ~ 787F2C645D84C34B503984769364221101FF5A50720AF027A7CACDC71EA4474E[c98a]::insideconstgenericarguments)' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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: [typeck] type-checking [analysis] running analysis passes on this crate --
This bisects to cc
<!-- 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. --: <details<summary<strongError output</strong</summary<p</p</details<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Regression in nightly-2022-09-05 commit[0] 2022-09-03: Auto merge of - cjgillot:old-no-lt, r=estebank commit[1] 2022-09-04: Auto merge of - matthiaskrgr:rollup-9n0257m, r=matthiaskrgr commit[2] 2022-09-04: Auto merge of - nikic:update-llvm-7, r=cuviper commit[3] 2022-09-04: Auto merge of - jswrenn:transmute, r=oli-obk commit[4] 2022-09-04: Auto merge of - klensy:bump-deps-08-22, r=Dylan-DPC commit[5] 2022-09-04: Auto merge of - compiler-errors:head-span-for-enclosing-scope, r=oli-obk commit[6] 2022-09-04: Auto merge of - matthiaskrgr:rollup-uj24yb5, r=matthiaskrgr commit[7] 2022-09-04: Auto merge of - asquared31415:vec-zero-opts, r=thomcc
Minimal: This has nothing to do with the transmutability feature. Also, it's fixed by , since the above desugars to:
WG-prioritization assigning priority (). label -I-prioritize +P-medium -needs-triage
This is but needs a test. To whoever does it, please commit the example I minimized and not the other one, since we don't need to make the test depend on the transmutability feature.
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!
That PR was a rollup. Without having looked at any logs, Edit: Oh uh, nope, sorry, had a different change in mind. Will take a closer look. :)
Ah, the problem is The call to was changed from to try first. Returning null there would work fine, as it still falls back to . Edit: And the same for .
Miri is in "test pass" state in https://rust-lang- since rust-lang/rust and rust-lang/rust has been closed. Also I didn't found , so I assume Miri should build from the branch of it. However, Miri in the latest nightly (, rust-lang/rust from . rust-lang/rust already contains rust-lang/rust. Actually Miri is missing since , and is still missing even rust-lang/rust has been merged. I can't find any additional information about Miri in the latest nightly. What's going on with it? Edit: I mentioned the wrong PR. It should be instead of .
Oh, I had not even noticed this, thanks! This looks like a rustc issue, so I'll move the issue there.
Cc any idea why Miri is missing from ?
The log at looks good in terms of tests, but one thing is strange: Notice the "test-fail" for "cargo-miri". However, I don't think anything actually cares about that test state, so I am not sure if this is actually a problem. I guess something is going wrong when doing the nightly release (Miri has special logic there to avoid shipping when tests fail), but I do not know how to access the logs for that.
Thanks for the report! This is a bug in our release process: Release process logs are not available publicly unfortunately :(
rust-lang/promote-release has been closed, but Miri is still not available due to . Maybe Miri will be available tomorrow and this can be closed then.
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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regression in nightly-2021-04-12 finding bors merge commits found 9 bors merge commits in the specified range commit[0] 2021-04-10: Auto merge of - Aaron1011:new-preexp-tests, r=petrochenkov commit[1] 2021-04-10: Auto merge of - Aaron1011:derive-invoc-order, r=petrochenkov commit[2] 2021-04-11: Auto merge of - RalfJung:liballoc-miri, r=Manishearth commit[3] 2021-04-11: Auto merge of - nagisa:nixos-patching-fix, r=Mark-Simulacrum commit[4] 2021-04-11: Auto merge of - JohnTitor:issue-, r=estebank commit[5] 2021-04-11: Auto merge of - Aaron1011:feature/final-preexp-tts, r=petrochenkov commit[6] 2021-04-11: Auto merge of - LingMan:patch-1, r=nagisa commit[7] 2021-04-11: Auto merge of - tweksteen:androidsetmessage, r=m-ou-se commit[8] 2021-04-11: Auto merge of - hyd-dev:uwtable, r=nagisa
claim
Reduced reproduction:
claim
I've tried reducing this but wasn't really able to so far. I might try again some other time. The code below currently ICEs on Nightly (). When trying to reproduce locally for the backtrace, I had an older Nightly first () where this actually didn't crash the compiler, so it's apparently a regression. <details<summary<strongBacktrace</strong</summary<p</p</details
This is my first time using cargo-bisect-rustc and it's fantastic. It identified the regression as... searched nightlies: from nightly-2020-02-13 to nightly-2020-05-14 regressed nightly: nightly-2020-03-20 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
is a rollup commit. The only PR which was part of that and (to me) looks like it could have caused this issue is .
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.
produces: <details</detailsIt should not be possible to access the type parameter in the type of the const parameter. cc Thanks to for .
Hi, I am new to rust compiler development and have decided to try to fix this issue to get started. If I understand the const-generics RFC correctly, type parameters can not be used in a const generic parameter because it cannot be ensured that the actual types have the "structural match" property. However, checking reveals that fn pointers (as well as raw pointers and empty arrays) always support structural matching, regardless of the types used within. My question is: is there another reason why const generic parameters are not allowed to use type parameters? If so, I think an additional check has to be to .
Actually, I think I may have interpreted. It looks like this example is intended to work to me. cc just to clarify.
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.
<!-- 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
Probably related to
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.
<!-- 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
Depends on const generics in type dependent paths afaict. See for more info. EDIT: Also depends on const generics with generic types. Merging does not close this issue
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.
Adding the following as a test might still be useful, even if it only errors with "using function pointers as const parameters is forbidden":
Here's a minimized version of the code I'm working with: Compiling this on stable or nightly gives a warning on the indicated line, despite the attribute on . A similar issue was reported before in , and addressed in a follow-up PR , but it seems to be cropping up again here, maybe because a non-ASCII field name is involved. It was agreed in that punning of non-snake-case fields in patterns should not produce an additional warning, so I think this is a bona fide bug. (Incidentally, on stable the same warning appears twice in the compiler output, but this duplication seems to be fixed on nightly.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It's actually unrelated to the non-ASCII field names; reduced: claim
Thanks
A code attached below used to compile with rustc 1.48 (stable) and stopped to work with 1.49 (stable). Two thing help to make the code compile: 1) comment out 2) explicitly deref . To compile code below one need to add to dependencies. Maybe this is due to some conflict between ArcSwap instance method and Access load method? I tried this code: I expected to see this happen: It should compile properly (it worked with rustc version 1.48 and earlier versions as well). Instead, this happened: I got compilation error It most recently worked on: Rust 1.48 :
searched nightlies: from nightly-2020-10-01 to nightly-2020-11-14 regressed nightly: nightly-2020-10-07 searched commits: from to regressed commit: () <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Assigning as discussed as part of the and removing .
:
The examples now print actionable feedback for the user, in the form of errors complaining about multiple applicable impl's. For example, the now prints: So I think this might just need a regression test. label: E-needs-test
Godbolt: Basically the issue is that you compute , check that it doesn't overflow, and then you verify that is greater than , which it of course always is, since you checked for an overflow! This is probably an LLVM optimization bug, but I'm starting here :-) Command line arguments: Source: ASM:
Slightly reduced testcase: LLVM does not realize that and are the same here.
Ok, looks like the thing to do is file an LLVM bug -- do you know off hand if they're ok with Rust reproducers, or do they prefer C ones?
Ok, ended up converting to C because that seemed easy:
Submitted additionally for the IR pattern above (which is an issue separate from the missing combining). Just verified that fixing this does indeed eliminate the check in this example.
am I correct in reading that this has been waiting on a review of the LLVM patch?
Needs a rebase. More generally though, I think this is fighting a losing battle. and are not considered canonical IR for a reason: They optimize badly in the middle end. I think we'd be better off with generating the canonical variants instead (which are and ). LLVM will still form during CGP, but this should optimize better in the middle end (including avoiding the issue here). As we already have a good benchmark for the overhead of overflow checks in , I think it might be worth trying to rerun that without using the unsigned overflow intrinsics.
From the :
once this makes it's way into Rust's LLVM (is there a good way to track this?) I'll verify that the assembly in this bug was improved, and if so I'll rebase the rustc patch and we can get some new numbers!
Ok, confirmed that the recent LLVM10 update removes this branch: Shall this be closed?
Actually, that was probably premature. We should add a codegen test.
is there a good example of what a test looks like? I can spin one up pretty easily if someone can point me at how to add one.
Codegen tests are located in . One test that is thematically related: . They use . Codegen tests can be run with:
Thanks much, that's exactly what I needed! PR is up now.