jiebi/CodeConvo huggingface dataset:
I have an issue with rust (now version 1.22.1) on Solaris sparc (64bit). On intel I don't see it. I originally see it as part of Firefox build () I now believe it's rustc issue (though it could be still issue with clang-sys). Any help would be greatly appreciated. Run output looks like: Stack: With tracing: Note that clanggetTranslationUnitCursor isn't called with 'tu' set to 0. I have find out that the issue seems to be with the size of CXCursor structure which is returned: CXCursor is 32 bytes long. But if I tell clang-sys it's 16 bytes everything is perfect (when it's 17 bytes or more it causes the trouble): Following is disassembly when CXCursor is pretended to be just 16 bytes: And now with 17 bytes:
I wrote more minimalistic version of test case which rules out use of clang-sys. On intel it works as expected: But on sparc it looks weird: But with this "hack" it looks better:
Ok. I'm new to both Rust and LLVM. I tried to create for above example llvm-ir data on intel and used llc to build it on sparc. The same result could be seen. Does it mean that that issue is rather in LLVM?! On intel I did: On Sparc I did: The output is bad. See comment above (). [1]
and are wrong; structs up to 32 bytes in size, i.e. 256 bits, are returned in registers. I was also suspicious of this code in general when it was first merged as it doesn't seem very long, and handling mixed float and int structs is a little fiddly. EDIT: Well, actually, should vary based on whether it's an argument (which can be up to 16 bytes) or return value (up to 32 bytes).
Can you please suggest how to implement this? I can confirm that when modifying to contain 256 my above test examples passes as expected (though Firefox still wouldn't build).
As mentioned above. With partial fix Firefox build dies later when it calls . Which takes three arguments and the problematic first one is again 32 bytes long structure ().
Maybe you can suggest a preliminary patch to at least improve the code generation?
Are you sure?
Hello, with rustc 1.17.0-nightly ( 2017-03-22), the following code gives this error message: An improved error message could add a hint :
Current output: 1) How would you want to improve upon this? Adding a suggestion? 2) To do so, we could use the same strategy as in : in , try to continue building the expression as if the keyword had been found. If we find further errors, we revert the state of the compiler to right after trying to continue and return the error from . Otherwise we cancel that one and create a new custom diagnostic: 3) or just modify the existing error with the proposed (so it looks like the 2 above). []:
Looks like current output already is an improvement over the reported one, but eithwr 2 or 3 would make it even more obvious i guess. No strong opinions here
Seems to me that the third error is the most clear ("error: missing in loop"); I suspect people using fancy pattern features will figure out what's going on.
This line looks like a typo to me, should it be ? Originally posted by in Currently, it affects line 1684. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Yeah, this could be fixed.
Ideally a test should also be crafted that shows that this missing affects an error message or something.
claim
At some point their should also be a for , and probably a way to tell what position each of the non stripped items are, as currently each of these 3 variants are documented with the same inner. but HTML gets a good representation:  The solution is probably to do what we do for structs, and store the , and a , such that each field of a varient gets an to hold the . We also should have a numfields, as even in that schema, you can't tell the difference between This also effects struct AFAIKT. I don't think this needs to be done now. I'll file an issue for it. Originally posted by in modify labels: +A-rustdoc-json +T-rustdoc
Related:
<!-- 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
This isn't really a bug, it's just that it has bad diagnostics because it uses , which is a perma-unstable attribute. I would recommend against reporting bugs that need attributes unless they cause unsoundness.
MCVE:
Should I exclude all test programs that have a line starting with ? Thanks.
I don't personally feel comfortable setting a policy that we'll never fix ICEs with attributes, but they are definitely less likely to be bugs than other ICEs. Note that this isn't sufficient to catch programs that have an attribute, you can have arbitrary macros that play with conditional compilation, like . Catching and will probably hit the common cases, though (you may want to also include inner attributes).
I was going through some refactoring and the compiler exploded. No unsafe. The last bits of code I was playing with can be found , before I tried to refactor the example, the tests were building and passing. The macro that might be to blame is . I parked a branch with the code that made it blew up, you can find it here works, blows up. a happy compiler, worst case an unhappy one a dead compiler : Backtrace:
Minimal example:
Thanks that was a quick fix. Do you have a workaround until the fix makes it to master?
The ICE occurs when you have an item referenced in an impl signature is imported from an statement occurs within an impl. To work around the ICE, you can move the call to to a different free function.
Got it, it works , thanks!
I'm looking into the performance of / on mostly ascii strings, using a small microbenchmark to . Using linux perf tooling I see that the hot part of the code is the following large loop, which despite heavy use of sse2 instructions only seems to process 32 bytes per iteration. I don't see an easy way to improve the autovectorization of this code, but it should be relatively easy to explicitly vectorize it using , and I would like to prepare such a PR if there are no objections. As far as I know, is already in use inside , for example by .
The way the loop ors the bits for the is-ascii check into a single usize doesn't seem ideal for vectorization. keeping the lanes independent should yield better autovectorization results.
Thanks for the suggestion. I already started with a simd implementation, but now checked again if the autovectorization could be improved. With the following main loop The assembly and performance is indeed better, but there is still some weird shuffling and shifting going on: The explicit simd version looks a bit better, mostly because the ascii check directly translates to a : Do you have a preference here between autovectorization and explicit simd?
If the SIMD impl results in reasonable code across architectures, including some without SIMD then that should be fine. I think it would be the first time where we use portable simd unconditionally, so it could use some additional scrutiny. If it's only meant to target x86 with SSE2 then that'd mean having multiple paths and in that case we'd still have to tweak the generic path anyway. At that point we might as well just optimize the latter further. You can probably get rid of those too by keeping multiple bools in a small array. That way the optimizer will more easily see that it can shove them into independent simd lanes. Increasing the unroll count might help too to fit better into simd registers. We do get pretty decent autovectorization in other places in the standard library by massaging things into a state that basically looks like arrays-instead-of-SIMD-types. E.g.
It seems llvm is too "smart" for this trick, on its own that generates the exact same code. The trick does work, although it seems a bit fragile.
The following creates a instruction just like the simd version, but a slightly different alternative with a array and comparing against 0 does not. It only needs to be better than the autovectorized version on those platforms ;) My initial idea was to gate the simd code on either SSE2 or Neon (possibly also Altivec and RiscV). I'd also add a scalar loop for the non-multiple-of-N remainder, so all-ascii strings are fully handled by specialized code. Currently this remainder goes through the generic and code path. On other platforms, only the scalar loop would be used, since I assume the autovectorization would also generate suboptimal code. But I agree that if similar code quality can be achieved with autovectorization, that would be preferable. I'll open a PR after a little bit more polishing the code.
Here is called for potential side effects until , ignoring however that it could have already been called in with those indexes. that demonstrates how this can be exploited to get two mutable references to the same data and cause an use-after-free bug.
Assigning as part of the .
The gift that keeps on giving Maybe it is time to get rid of as it exists today and replace it with a ? One that imposes the additional requirement on the caller that it must bring the iterator back into a safe state after it is done iterating. The upside would be eliminating a lot of code in and enabling the same optimization for and similar sources. While the downside would be that external iteration (i.e. loops and manual calls to ) would cease to benefit from optimizations and only internal iteration methods (including ) would continue to do so.
I don't know, I feel like that would just make more complex to upheld the invariants. IMO a good improvement over the current would be separating forward and backward iteration, this way it becomes easier to keep track of the state and I think would also make it possible to implement them for
I don't see how separating the forward and backward state would help with a drop implementation. The issue is that the source () currently does not have access to that state, instead the consumer drives the iteration by direct access through and never informs the source about it.
It would help because it allows the source iterator to keep track of its state by updating it when the method is called. Anyway, looks like someone already and it resulted in worse optimizations, but maybe LLVM got better in the meantime, or maybe that implementation could have been better. Anyway I don't think this is the right place to discuss this, a topic on zulip would probably be better.
https://rust-
Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --is not a valid argument; it needs to be either or . For some reason this problem only happens when the function is async.
This is the same diagnostic you get when mutably dereferencing let-bindings that are : So it seems like this has to do with the fact that ast_lowering emits a binding when desugaring. I wonder if we can get the name of the variable when emitting this diagnostic, and special-case when it .
Another (possibly related?) bug: doesn't have the suggestion if it's in an async block:
Same with closures. I would probably classify that as a separate bug, since the original bug has to do specifically with desugaring, and the latter has to do with closure/generator captures.
Thanks for the report and getting a PR up so quickly! label +AsyncAwait-Triaged +AsyncAwait-Polish
Another similar error, not related to async this time: isn't valid Rust.
does not emit color output when running under a tmux session with set correctly to (supported by the latest versions of ncurses) even with when is set to . On the machine in question (macOS) the term file for is installed and returns the following: Per cargo should be invoking rustc with the flag, and indeed, returns 'Option color given more than once. Executing also does not produce color output, but does.
I have a similar bug on Archlinux. I used to get colored output on this system, but that recently stopped working for rustc. (Cargo is still fine for me.) If I add in and run in , I get Result::unwrap()Err/lib/terminfo/x/xterm-256colorncursesNEWS file does mention a new (incompatible) file format with a different magic number: Could rustc switch to whatever Cargo uses for colored terminal output?
A work-around for my machine was temporarily downgrading the packages, and copying the old file to .
Yes rustc should be able to switch at any time
Thanks for the workaround!
Changing from to also seems to work as a temporary workaround. (note: this may affect other terminal applications)
Another work-around if you're using sh: This sets to a possibly incorrect value, but limits its impact to only the output of a command.
That worked for me as well. I had no colour with . I downgraded to , which was what I had in , and now I have colour again.
I have a similar issue: In my regular terminal emulator (not tmux), there are no colors from rustc (as executed with ), colors from cargo itself are working fine. The default setting for there is: . The problem is fixed by setting to . Inside tmux however, colors work just fine, there seems to be by default.
Colors are fixed in the latest nightly (thanks to o/)
This is fixed for me in today’s nigthly, presumably by
With the current nightly I still have no colors with and have to use as a work around. What might still be broken?
Terminal colors are still broken with . however, does use colors, so there's clearly still a discrepancy between how and use termcolor
It works fine for me with ncurses 6.1, even rustup has colors again since the last version .
I’d like to note though that things like destroy this for some reason (even if is set). It took me some time to figure that out
I'm using ncurses 6.1 on Fedora 28 and everything appears to be working fine except for test colors. In mentioned that a bit tricky due to how the build works, but we can always tackle that later. What is the barrier to migrating libtest from to ? For now, it's leaving my test output looking like this. !
I have an in-progress patch for libtest but I ran into I'm guessing that's the build issue that is referring to. I don't know how linking libtest works, but I'm happy to try to fix the build if someone can point me in the right direction.
cc I suspect (but have not verified) that this would be fixed by a backport of
was merged in October, I don't think it's related
Does this need an mcve?
Yeah, but I think at this point a bisection might be more helpful since we're not yet sure what caused this.
Here's a somewhat small-ish MCVE: Haven't managed to remove mio yet, but that's just a matter of time ;) Note, that this doesn't depend on the feature. You can use as well.
Here's a "M"CVE without any dependencies: regression in nightly-2020-01-11 <details<summaryBacktrace</summary</details modify labels: -E-needs-bisection -E-needs-mcve
searched nightlies: from nightly-2019-11-01 to nightly-2020-02-16 regressed nightly: nightly-2020-01-11 searched commits: from to regressed commit: source code: Reproduce bisection with: <details<summaryCOLLAPSIBLE ERROR STACKTRACE</summary<p</p</details<details<summaryERROR BEFORE ICE REGRESSION</summary<p</p</details
It would be good to continue the bisection into the rollup PR, among the following PRs: (Point at opaque and closure type definitions in type errors) (Reduce special treatment for zsts) (Parse the syntax described in RFC 2632) (rustcastlowering: misc cleanup & rustc dep reductions) (Extend support of in type parameters) (expect after / )
triage: P-high, removing nomination, assigning to self.
Given the backtrace, I think it's probably (Reduce special treatment for zsts)
I can indeed reproduce the ICE at , seems to be the culprit. cc <details<summaryBacktrace</summary</details
Here is a more minimal MCVE: /me needs to invest some time in tools like rust-reduce or creduce...
Okay so now we have two different PR's to fix this. PR is almost certainly the right call for nightly itself. My only Question is whether we should also land PR and also then backport that to beta. My argument for why is that it is "obviously" less risky, which is important because the beta is going to be imminently promoted to stable.
If the wrapped iterator implements then blindly delegates to it. The underlying iterator may know its exact size but return spurious results anyway, on which will stop iterating even though the source knows that there are elements left to iterate, meaning will indicate that there are elements left but never return them. The behavior was introduced in but didn't see any discussion.
Implementations of have soundness implications, thus marking as . That being said, the documentation for is fairly exact in its wording that the first means "end of iteration".
Hm, seeing as is not an unsafe trait, I would not expect code to be able to rely on it for soundness? Maybe we do so internally for std types though...
Unsafe code can't rely on correctness (there's for that). The length of an iterator is defined as the number of items yielded before it returns None, so Fuse's implementation is correct.
Oh my bad, I was confusing it with TrustedLen.
Ok, makes sense. But I will be pedantic here since I prefer documentation to have slightly more formal flavor. docs: The module documentation: Now resume can be interpreted as continuing the the previous iteration instead of starting a new iteration (conceptually a new iteration would require a new iterator then). Under this interpretation should report the complete length of all iteration including possible resumptions which must be known when claiming exact sizing knowledge. The documentation could use a more precise definition of what an iteration is and that resumption is really considered a new iteration.
I've come across quite a few broken links just while browsing the online documentation generated by rustdoc (particularly when clicking on links from search results). There are already issues relating to specific cases, but perhaps there should be a catch-all test on the output of rustdoc to check that all generated hyperlinks are valid?
The problem with things like this is that services that go down then break your build. We did this for Rust By Example, but then a bad deploy caused the whole site to 404, and we couldn't bring it back up because the site was 404'ing :wink: Specific cases should be looked into, and bugs should get filed, for sure, but running checks like this takes about an hour and a half, I've done it with linkchecker.
I was thinking more of something which ran on the files offline - it can ignore external urls, but just check that internal urls point to a file that was actually generated. That wouldn't be affected by anything outside the current build.
Also, rather than using , which – as is saying – usually is not an expedient process, we could have record all the URLs produced when generating the HTML and then validate them against the directory structure.
One example: From Link is broken.
That's due to a Rustdoc... Mis-feature, for which we already have a bug open.
Another instance of a broken link is found in It says where 'this paper' is a dead link to
So, I'm going to give this bug a close. If there are specific things that are causing to generate invalid links, they should be filed as bugs, and if there are specific, manually linked links that are wrong, they should have a bug, but I don't see under what conditions this bug will ever get closed.
https://crater- https://crater- cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
label F-derivesmartpointer
Thread on zulip: https://rust-
claim
WG-prioritization assigning priority (). label -I-prioritize +P-high
The following code causes compiler panics due to the first line without which the issue isn't reproducible. Calling the function outside of a constant context emits the right compiler errors. <!-- 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<strongBacktrace</strong</summary<p</p</details
FWIW, replacing the function body with still gives an ICE:
Minimized slightly further, without const generics: <details<summarybacktrace</summary</detailsThe ICE occurs back to . In , it errors with By making small changes such as making the closure no longer take paramters or removing the reference at It errors, instead of an ICE, on stable and nightly with
searched nightlies: from nightly-2020-08-16 to nightly-2021-02-03 regressed nightly: nightly-2020-12-28 searched commits: from to regressed commit: edit: for this code sample <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with:
cc
Just to clarify, AFAICT, this issue is not due to , the stabilization just allowed code with const generics to run into this. MCVE ICEs before and shows that this is a borrowck bug not related to const generics
Assigning as discussed as part of the and removing .
I'm not sure if this is identical problem or not. The error message is: and my code is: I need both parts or the COPY tuple for the error to trigger and I'm unsure why. And also, if I put in its own const the bug is not triggered.
Triage: No longer ICE with the latest nightly, I guess fixed it? Marking as .
When using the feature, attempting to match on a tuple creates a compiler panic. The following code causes the panic. (Also available at the ) This occurs both on the playground and on my local machine on a previous version (details below). Rust version from the playground: Local version: Playground backtrace: Local backtrace: EDIT: Added local machine backtrace too
It looks like the problem is here in . The call to seems to rely on the invariant that the match pairs have been fully simplified at this point, but are a special case and can still show up here.
Reproducible with recent nightlies too: : Triggered by more than 3 pattern condition with this compiler version.
I would have assumed that the implementation merely desugars into a bunch of top-level or-patterns. Is that not the case? Why are tuples special cased? If it isn't too involved, I could take a crack at this with some guidance... very much want to see this over the finish line.