jiebi/CodeConvo huggingface dataset:
See also
The proper way to fix this is to wipe the build cache whenever the stage1 compiler changes. That will make builds a lot slower, but it's better than ICEs and having to wipe the cache anyway. I guess we could add a --keep-stage1-cache flag if you're sure you haven't touched metadata - not sure how useful it would be in practice. said on Zulip:
Wait, I'm confused again. Why does the metadata matter other than the incremental cache? Cargo already invalidates the cache when is modified, which is why libstd gets rebuilt when you modify the compiler. Is there anyone not using that's been hitting this issue?
I found while working on that this is not true: if you use --keep-stage-std 1, cargo will blithely keep the cache for all crates in build/stage1-rustc, without rebuilding. Copying over my comment from
Another possible fix is to make rebuilding after a commit cheap enough that we can include the hash unconditionally. Right now it's used in rustcsession; if we move it to rustcdriver, that would only need to relink the .so and recompile the final rustdoc/clippy/miri crates, not their dependencies. I guess it means we'd have to suggest using keep-stage-std more often :/ but people are doing that pretty frequently already.
Oh, and it has the downside that if you're testing the project on external crates cargo will recompile them after every commit. Maybe that's a good thing?
The only time it won't fully fix the issue is when you're modifying rustc_metadata or similar and don't make a commit between builds. I'm ok with not fixing that case, because anyone working on metadata is much more likely to understand what went happened and how to work around it than random contributors stumbling into this for the first time.
hit this issue this morning with incremental disabled, so it's relevant to all metadata loading, not just incremental.
Thanks for pointing me to the right issue. Following Tried some commits from the past few days Would it be useful to keep going with this approach? Oh, and this is with .
That's helpful, thanks! No need to find more commits, having a reproducer at all is already very useful.
This fundamental issue doesn't just apply to bootstrap, right?
If one uses a locally built toolchain to build some crates, and then updates the toolchain, the same ICEs can arise (because the dependency rlibs will now be in the wrong format). Bootstrap is just where people run into it most often. But a solution inside bootstrap won't fix the fundamental issue. (E.g., it won't fix the Miri version of this problem, which got reported at )
Yes, that's right, any two toolchains that were built from different sources but have the same version string will have this problem (this is why we set a custom description by default in the source tarballs, so they won't reuse metadata from the official toolchain). Removing or defaulting it to would work for miri though, or at least make it so that you have to try a lot harder to run into the bug (e.g. twice with different local changes that haven't been committed).
A more "principled" fix would be to have something like a metadata version number embedded in the files that contributors are responsible for updating when the format changes. But I worry people will forget to update it, the same way people often forget to bump and that causes caching issues:
oh right, and suggested adding incremental to dep-info: but given that this bug is also showing up for metadata, not just incremental, I suspect that's not a complete fix:
Yeah, if we could somehow ensure that such a version number is always correct it would be a proper fix but manual bumping probably won't work. Unless we find a way to at least have CI fail when one forgets to bump...
reported seeing these crashes for , not just for tools and stage 1 rustc. I think he's running into this line being buggy: that shouldn't filter only to build, nearly all the commands read metadata and need the same treatment. Not making a PR because I don't have a test case yet, but if anyone comes up with an MCVE that makes crash, I'd be interested to see if this diff fixes it: also, I wonder if we could fix the original problem with metadata/incremental in stage 1 by applying clearifdirty to rustc too:
reproducer unfortunately gives me a different ICE than the one in the linked issue; it's for stage0, not stage1. So I can't use it to test my diff.
It looks like if you go and grab this commit of timely-dataflow from github, you get a nicely reproducible ICE. TravisCI gets it too! In case anything changes in the meantime, the commit you want is Related issues: . The times I've seen this before I haven't be able to reproduce it, but since it seems to happen from a clean pull, I thought I would show you. To repro, just follow the commands here. git clone, cargo build, cargo test. Boom!
It seems like I can make the ICE go away by replacing a member variable with one that uses an equivalent trait which doesn't use associated types: Swapping that in removes the ICE, swapping it out brings the ICE back. So, maybe something isn't working great for boxed traits with associated types. The commit that fixes things is
Doing some testing, and the repro in (not mine) is way simpler. It also explodes on 1.1 stable, with a similar complaint. Just boxing a trait with two associated types.
I run into this problem, too (with stable ).
Hi, I ran into an interesting ICE while working on a personal project. This seems like it could be related to issues or , but I'm not sure. I set up a . The README includes a description of the bug and the compiler backtrace.
Getting the same ICE occasionally in (At more specifically, not minimized because I don't think I can produce a smaller example than the package above).
This is a somewhat flaky ICE I used to see a bunch back in April, but it seemed like it sorted itself out with the 1.0. I've found it again! It is on stable 1.1, so I thought I would bump this post 1.0 issue rather than my open pre-1.0 issues. I'm really not sure what causes this, but the common features tend to be doing a bunch of builds with light changes to a local crate (path="...") on which the project depends (in this case, local edits to the timely crate). It feels a lot like it is Cargo getting just a bit confused about what has changed and what hasn't, as will sometimes fix the problem. Previously, toggling LTO would tickle/untickle the bug, as would insisting on some inlining. Just now, fixed it up, after would not... Maybe someone should just put a on the bounds list... =/
While bootstrapping on Fedora 25 armv7l, I'm hitting a SIGILL when some beta-compiled programs are actually executed. This is with a purely default , no external LLVM or anything. On beta (exactly ), I get a little ways into stage1, and then build scripts SIGILL, apparently from double-panics. I reckon that the stable stage0 builds a stage1 compiler that's fine, then that stage1 starts building things that don't even need to execute until we get to a build script. Then: So I also tried the master branch (exactly ), and that fails as soon as it executes at the start of stage1. Here it seems that the downloaded beta stage0 compiler builds all of its stuff fine, which presumably includes executing some builds scripts like above. But the stage1 it creates seems to be bad: I traced through with gdb, and it's not actually crashing, rather the that it execs into. Here's the backtrace: That looks like a triple panic! The actual SIGILL is delivered for a instruction:
(side note: on the beta branch I have also applied , or else you have to configure with an explicit to get armv7.)
I tried to build a debug nightly, but it can't link to in stage0's librustcconstmath:
Looking at , it seems SIGILL is expected because of the . The questions are then, why did it panic in the first place and why did the default hook panic?
is where the default hook is panicking.
Yes, I agree the SIGILL is just a symptom of the nested panics, not something to fix in itself. While I couldn't get a debug build, I got a release build with debuginfo. Here's a better backtrace from running : So the first panic comes from the failed at frame called from . The line right before got a shared -- maybe something isn't marking this released properly? Then the nested panics come from trying to read this same broken , with frames and also trying to .
Looks like you are using an LLVM without the fix in . That will blatantly miscompile rustc and lead to severe problems.
While it does sound the same, unfortunately no, this is with the rust-bundled LLVM, including your fix.
:/
That said, there must be something local going wrong, as the official (cross-build) armv7 compiler seems to work fine, at least with the same simple reproducer, e.g. . I'm going to try a fresh build on a fresh system with absolutely no local LLVM present...
So -- that worked, both beta and nightly. I'll make sure to update our distro LLVM patches. What tripped me up on nightly was that stage0 is still 1.17.0-beta.2, which doesn't have the LLVM fix. I bumped that to beta.3, and then it worked. This doesn't affect the official nightly builds because only the host compiler goes through stages, and AIUI the cross-compiled targets only use the host stage2. But doing a native arm compile, the bugged stage0 gave me an unusable stage1. On beta, I don't know what happened before. I think perhaps somewhere when I was jumping between local and rust-llvm and testing different branches, I must have gotten a build of the still-broken rust-llvm, with a timestamp such that rustbuild didn't think it needed rebuilding on the fixed sources. I still have that build directory tarballed here, so I may poke at it when I get a free moment.
So we should update 1.18's stage0?
OK, see to bump stage0.
These are all legal, and somewhat strange, since they're not really following the file-system analogy that modules are typically explained with. I expect this behaviour is just whatever happens to fall out of the current implementation strategy, so let's make a more explicit decision one way or another. As one might expect, each of these is a distinct instance of (which can be verified by placing in : the compiler will greet you 3 times). Noticed in .
This seems weird to me. I think the intention is that the out-of-line syntax () should only work at the top-level.
I'd vote for allowing non-inline modules only at the top-level, to retain a clear mapping to the file system.
(Or nested inside modules.)
triage: P-medium Backwards incompatible, but ... kind of a curiousity.
Found one more mod aliasing scenario. It involves several files, and is semi officially allowed by the reference. The layout The files The copy module will be aliased. The problem is that although and are not directory owners, their inner modules are.
Upon reflecting more about this, I think that there are two questions here. should non inline modules be allowed (syntactically) inside items? should module aliasing (the same file representing two modules in the crate) be allowed? The questions are independent because you can use attribute to create module aliasing manually. I would prefer if the answer to the second question is not. I'm contributing to the Rust plugin for IntelliJ IDEA, and one of the tasks there is mapping files to modules (for example, to go to the parent module). I would much prefer just to highlight module aliasing as an error, rather then to deal with non one-to-one mapping between files and modules. As a side note, if a user does want aliasing for some reason, she can always use symbolic link for the same effect.
I tend to believe it is fine to have aliasing if you write the yourself (you asked for it...), and that it would be ok to put a non-inline module inside an non-module, if you specify the path yourself, but that we should error out otherwise. However, there has definitely been confusion in the past about the role of as a declaration and not a , and disallowing aliasing would prevent that confusion from leading to incorrect trees.
however is disconcerting, and suggests that perhaps the code has a slightly different model in mind than I do in my head. :) That is, I strongly expect to (by default) be found at . What happens if you don't have the , but just place in ?
It is forbidden because is not a directory owner.
Just in case here is a repository with the example: I don't see a reason to allow user to shoot himself in the leg. What if you accidentelly have identical attributes (copy paste problem)? My main concern though is that non injective file to module mapping may complicate the implementation of some rust tools. Here is another hypothetical example of this. Suppose you implement incremental compilation for rustc. You will need a mapping from files to modules. If mod aliasing is alowed, then you will need a multimapping. So you end up with more complex code which is used only in a tiny fraction of projects and because of this probably contains some bugs.
Ah, I see. So it seems to me that the problem is that should not be allowed in contexts where would be illegal. In other words, an inline module should only be considered a "directory owner" if it is located within a directory owner. A compromise might be Yet Another Lint Warning. ;) I agree with you about preventing people from shooting themselves in the leg, but I guess I think people don't use lightly or frequently, so this seems unlikely to be a major source of confusion.
I totally agree that this curiosity is insignificant for users. But I still worry more about the implementation side of the issue, and a lint warning does not help here.
This erroneous code: Produces this error message It would be better if instead it produced an error message like this: Tried the code in these Rust versions and they all produced the same error message: 1.37.0 stable1.45.0 stable1.46.0-beta.1 (2020-07-15 )1.47.0-nightly (2020-07-22 ) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This shouldn't be too hard. This comes from the parser, specifically the code that parses a pattern, which is one of functions. Somewhere there is the code to parse a struct pattern. I assume the error above happens when it successfully parses a struct field and then expects a comma or closing brace. To fix it you'd have to check for and report a better error message.
claim
The test in leaks memory, which makes a Miri run of the test suite fail: Running Miri on the test suite is helpful to find bugs, so we should avoid deliberate leaks to still be able to detect accidental ones. Can the test be changed to use some other means of ensuring that is not called, e.g. with a type? Cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim I made the test I should fix it
thanks. :-) Let me know if you need any help.
Fuzzer generated MIR, reduced, and UB-free under Miri (for real this time :sweatsmile:) Segfaults with enabled: , which is a valid pointer, somehow got propagated as 0: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
That seems undesirable. Is there a surface Rust program that can produce this MIR? Asking primarily for prioritization purposes.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Minimized test case:
Here's an example using stable surface syntax (). Seems to have been introduced in 1.70, with in particular.
Nevermind seems like I was wrong. <details</details
It's not an LLVM miscompilation, the code is already by the time it goes to LLVM. With So it's defiantly happening in MIR ConstProp
The problem seems to be that when running on the statement , the frames arn't updated, so when it runs on , it thinks is their for local . , on to add logging and test. ()
claim
Cc
Specifically at , and recommend for Windows too, right? We've , but in the meantime, the old book should recommend the new recommended toolchain :) If it's too soon to do this because isn't stable enough yet, consider this a reminder issue to make this change once it is :)
wants to wait a bit, and we'd need to then make sure to update the website in sync (see )
Maybe the big red warning "this is beta software" should be removed from the website?
This will be fixed by
I was attempting to assign directly to the result of a vector's , which caused this error to fire. That is when I discovered that the help section was telling me to do add an extra let to my while statement, which is not syntactically correct. I tried this code: I expected to see this happen: The code would fail to compile and the help message would tell me to dereference the left side, or at the least give me code that was syntactically correct. Instead, this happened: The could failed to compile, and the help message gave syntactically incorrect code as seen in the backtrace section. <!-- 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<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
This minifies to which reports and are related I think, since this example produces the ICE mentioned there on stable
label +A-diagnostics +D-invalid-suggestion +T-compiler
claim
Basically just change this macro to recognize and discard the trailing comma.
That macro declaration is formatted in a weird way. But anyway it should be enough to add to the rule (unless accepting multiple trailing commas is undesired). I could mentor.
How about this:
Out of curiosity, why doesn't rust allow trailing commas after automatically? Does it make it hard to write some macros? Alternately, why isn't there a (optional) repetition specification (e.g. would be 0 or 1 times)?
The extra rule is fine too. It's just more annoying (extra repetition). And there's no technical reason not to support one-or-none patterns as far as I'm aware.
Made a PR :)
<!-- 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 was likely introduced in (CC rustc 1.65 nightly 2022-08-12 emits the following:
The error happens on latest stable and nightly. Steps to reproduce: ; : : returns error: The error only happens if the module is named (for instance, and work without error). The error is not produced if doesn't use in any way. If doesn't contain imports but uses the library directly (e.g. ), the error is produced. always succeeds. I don't know if this is supposed to be forbidden but the error message seems to be misleading.
The second instance is injected implicitly. The error could be better, yes.
Where exactly is injected - in the library or in the test? Why does the library work on its own? Why does conflict with in the test?
Ok, it turns out this is a legitimate bug, I misinterpreted it as a more commonly reported diagnostic issue. is injected into both the library and the test, but only the first one causes the error. If you set in , then you'll see the error immediately while compiling - conflicts with . On 2018 edition, however, is injected in more subtle way, as where is some unique symbol that still has the string representation , but doesn't clash with anything in the same crate. Unfortunately, turns into "just " after encoding into metadata in the compiled library (this is the bug). So, when we load that library from the test it looks like the library defines two conflicting items.
The solution is to either encode gensyms/hygiene into metadata properly (this is a large task and a long standing issue), or come up with some hack preventing the injected specifically from being encoded (it doesn't really need to be encoded).
Fixed in
was closed when stabilized the corresponding language feature, but we didn’t realize that it was also the tracking issue for this standard library feature: History: [x] Original tracking issue: [x] Discussion of payload vs message [x] Making .message() infallible: [x] Split core/std PanicInfo into two types: This made core::panic::PanicInfo::message() infallible. [x] Use opaque return type: [x] FCP [x] Stablization PR: Unresolved questions: [x] Should it be infallible? Yes, by making std::panic::PanicHookInfo a different type. [x] What should the return type be? or an opaque ? The first is simpler, but the latter allows a bit more flexibility for future changes.
Instead of making a PR go through the queue to fix the tracking issue, should we stabilize this method? fcp merge The doc-comment is slightly wrong or out of date. Its second line shoudl be removed. always creates a where is , regardless of the number of arguments given. In the single-argument case, that argument is required to have type . At first returning seemed unusual to me and I considered that we could make the method return instead, on the basis that calling its impl is almost the only useful thing to do with a . But has been stable and documented as the return type of since 1.0.0, so maybe it’s fine.
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [ ] [x] [x] [ ] [ ] [ ] Concerns: single-arg core::panic () Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
The module also links to that closed tracking issue. Let’s consider the pFCP above to also include stabilizing it. ( is stable.)
concern single-arg core::panic Should we change libcore’s macro so that its single-argument form creates a with a instead of one with a ?