jiebi/CodeConvo huggingface dataset:
mentioned a leak coming from but not , I think I tracked this down to the use of in when given a comma-separated list. I've made that demonstrates it with , if it gets much simpler than this then the leak doesn't occur when built with --release. I'm testing on rustc 1.37.0-nightly ( 2019-06-30) nightly-x8664-pc-windows-msvc, targeting x8664-pc-windows-msvc.
Valgrind Memcheck also reports heap in use at exit on a Linux VM with the test linked above.
Thanks a lot for creating a reduced test case and creating this issue here. I stumbled over the original issue when carg-fuzz reported a memory leak in this code This PR appears to fix the issue This was also with rustc 1.37.0-nightly on Linux. I can check if I can repro with the fuzz test case on other platforms.
Looks like the early return doesn't interact well with box syntax's preallocation. MIR generation issue? cc
should be here: Now that can only schedule drops for locals, we should get the type from to avoid this sort of problem in the future.
Confirmed with my fuzzing test case that the problem is fixed in the latest rust nightly. Thanks for fixing it so quickly.
See the case in .
Not critical for 0.6; de-milestoning
-- does it make sense for the AST fold to visit macros? Or is the current code correct?
From my perspective: yes, definitely. In particular, I'm going to want ident-folds to hit the idents inside of macro invocations. Could it break code to add this traversal? Well, the only place you're going to see unexpanded macro invocations is prior to expansion, and the only thing inside of macro invocations is tokens, so it seems very unlikely. To summarize: yes, this fold should visit macro invocations.
In that case, nominating for milestone 5, production-ready
accepted for production-ready milestone
I've implemented this in a local branch, I expect to push it soon (next two days)
done, now. FIXME removed downstream.
See I propose to change the license of Non trivial contributors: OK OK OK Contributors appearing in git blame that are trivial (trivial update due to language changes): OK OK OK OK Contributors with removed and trivial contributions are not considered. For the persons that are not in "OK" state, please respond to this issue saying: Then, I'll propose the corresponding PR. Thanks.
I agree to relicense any previous contributions to according to the term of the Computer Language Benchmarks Game license ()
I agree to relicense any previous contributions to according to the term of the Computer Language Benchmarks Game license ()
I'm trying to build the compiler for the first time, following the instructions at https://rustc-dev- One of: documentation at https://rustc-dev- explaining how to install , or documentation at https://rustc-dev- saying to set in the section of , or to be installed automatically by , or to be set automatically by default by ; and a solution for the error.
Here's the backtrace:
Adding an section with to in the root does not appear to make any difference:
The next thing I tried was to uninstall and install , which resulted in this error instead:
You can set if you don't want to play with llvm.
I do want to potentially play with (especially, instrument) llvm. Removing the section, doing and running again fixed it. ( gave me a hint that this might be useful thing to try, since was under the directory.) I also installed the Debian package; I don't know whether that was necessary/relevant.
Yes, this is what fixed it - I don't know what the cargo package you installed is, but the Debian package is the one rustbuild expects. Hmm, I would rather have bootstrap tell you that directly when it gives an error that ninja isn't found, that seems more helpful (and easier to keep up to date). Are you interested in making a PR for that? :)
The error checking for this lives in
Yes I can make a PR for that.
describes how to install ninja packages on a variety of platforms, so I'll have the error message link to that.
One thing I'm confused about is that adding to was not sufficient to fix the problem originally. I would have expected that to work regardless of whether ninja was installed.
I tried reproducing it. Without ninja installed there's a proper warning message. Editing then makes things build with gnu make . Imo the main thing that could use improvement is to autodetect whether ninja is available or not and set that flag automatically. Unless we want to encourage the use of ninja by default for fast builds.
Yes, it's intentionally semi-required to encourage it's use, as it gives a much better experience (though these days most people are not building LLVM, I hope).
<!-- 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 on AVR (arduino Uno = atmega328p) with opt-level="z": I expected to see this happen: Instead, this happened: An alternate code that emits the correct output is This compiler error is corrupting the pixel stream transmitted via SPI to an ST7789 display from an Arduino Uno. What appears to be happening is that instead of the bytes being swapped, the LSB is being copied to the MSB. I do not have the expertise to decompile and examine the assembly code. : The malfunction also occurs with . The full code can be cloned from <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Since I looked it up, here's the expected/actual in hex, which makes the bug more clear: input: expected: actual:
Hi, Could you please check with ? It feels like a bug nonetheless, but I'm curious about the result
Also: claim
I'm analyzing the codegen bug - simplest reproduction so far:
Got it! The simplest reproduction: This prints ( in hex) instead of ( in hex), because the generated binary accidentally overwrites the high-order byte with the low-order one: ! After calling ( on the screenshot), the returned number - ( in hex) - gets stored into r23:r24 (you can see that r23=0x39, r24=0x30, and AVR being little-endian means the number is reconstructed from r24 first, r23 second). expects its parameter to be stored in , so right before calling , the codegen has a simple job: move into ; and that's where the bug comes into play. What the code generator says is: ... which always sets and to the same value () - what it should generate instead is: Overall, that's an omission on the LLVM's side (when moving register pairs, it should consider whether the registers are overlapping or not) - I'll try to prepare a patch Edit:
I just updated to nightly-2022-07-08 and some weirdness I was seeing with seems to have been fixed.
Running Servo’s unit tests started failing on CI a couple nightlies ago. A customized CI task to add shows: The error message appears to come from here: Reading through the call sites of this function I quickly reach in , so I don’t understand how this message could be emitted while is not actually present in the command-line arguments given to rustc by Cargo. I have also not managed to reproduce this outside of the CI environment. I don’t have an exact regression range, but this started happening a couple days ago which is close to when landed. This PR updated Cargo, including whose description mentions using rustc’s JSON output more. I suspect this is what caused the issue to be uncovered, but it looks like the root cause is in rustc’s argument parsing.
Sorry for the noise! I managed to reproduce in a local docker container (in order to copy CI’s config exactly), the problem turned out to be using an old version of sccache:
<!-- [31mICE[0m: Rustc '--crate-type=lib -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error[E0107]: trait takes 1 generic argument but 0 generic arguments were supplied', 'error: internal compiler error[E0107]: trait takes 1 generic argument but 0 generic arguments were supplied' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc :thinking:
claim
<!-- 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 (): Somehow in the second case we think that is unconstrained even though it doesn't seem to contain more or less type information than the first case. Note also that this does not error if I use RPIT instead.
I think in the second example mir building doesn't generate code for the trailing expression because it's statically known as dead code. But I thought we were keeping around the typeck types nowadays, and typeck should be the same for both functions
I don't think that's it, same error if I put the match in a branch ():
In fact this doesn't need an empty type at all:
I think we're generating bogus MIR or THIR because of that empty match -- Are you sure the bug doesn't exist on the THIR/MIR building side, (hacked to dump the instead of )
Oh I'm sure of nothing I just assumed an unreachable in a branch would not affect anything else
So: If there's a match error, we end up constructing a failure MIR body. This will prevent us from inferring the opaque later on. edit: that last sentence was a lie Let me see if I can cook up a quick fix.
We've run into an issue where we have a type that implements both and . Passing an index value of causes rustc to choose instead of , even if a mutable reference is required. If we first call and use that as the index, is chosen, as expected. Example repro by (see ): I expected to see this happen: should invoke on since expects a mutable reference. Instead, this happened: invoked and complained that isn't implemented even though it is: <!-- 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. --This is reproducible on stable Rust 1.41.0 and 1.43.0 and . cc:
I have a hacky solution to this in . Looking this code up in godbolt I can reproduce it all the way to 1.0, earlier versions giving a type error ( vs ), then an ICE in the 1.2x (that I was causing during my experiments to fix this: ) and finally the current error. The problem is caused (somehow) in slightly differing from , but haven't figured how to fix that underlying difference.
In case this helps to find the root problem, gives a similar error: " is not implemented" even though it really is.
It seems closely related but sadly doesn't change the behavior on that ticket. I'll take a look at it though.
I tried this code: I expected to see this happen: An error saying that is invalid and should be instead. Instead, this happened: <!-- 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. --HEAD is branched from <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
can return an error after a partial write if flushing the inner fails (). It should instead return , ignoring the error. I originally thought this problem was systematic so I audited stdlib. Apparently it isn't... See below. The write trait guarantees: However, this is violated all over stdlib. For example, if is written to a , the could write , try to flush, and then return an error due to a failed flush. However, has been written violating the spec. IMO, the solution is to return for partial writes and drop the error (if any). This should be safe because of write's write-xor-error guarantee. If the error was transient, the caller never needs to know. Otherwise, they will will learn of it on the next write. Here's everything in the stdlib that implements write (and should be audited): [x] in [x] in [x] in [x] in [x] in [x] in [x] in [x] in [x] in [x] in [x] in [x] in [x] in [x] in [x] in [x] in [x] in [ ] in (buggy) [x] in (buggy but unfixable and deprecated). [x] in [x] in [x] in [ ] in (panics on partial write) [x] in [x] in [x] in
Note: this could, e.g., theoretically cause to write on interrupt.
Ok. Actually, it turns out that only and are really problematic. on windows is bad but at least it's acknowledged in the code with a ...
So, is actually correct (I misread some of the code). This is just a bug in , nothing more.
Nice effort to audit it all!
<!-- 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 one
I just tried out the new parallelization feature of the compiler and it randomly panicked because a deadlock was detected. I tried a couple of times and could not reproduce it unfortunately. : <details<summary<strongBacktrace</strong</summary<p</p</details
Could you provide the minimal example causes the ICE?
The project I compiled was huge and I was not able to consistently reproduce it so reducing my case to a minimal example might take forever. Buy I noticed the issue you linked already contains a fairly small example code so it's probably alright to close my ticket since it seems to be a duplicate of that other ticket anyway.
Can you reproduce this bug using the latest nightly version to get the new error output?
Yes. It appears to be the same issue (albeit while compiling a different dependency but that probably doesn't matter):
BTW with the latest nightly the compiler always and immediately panics and produces multiple back traces. version: nightly-aarch64-apple-darwin unchanged - rustc 1.76.0-nightly ( 2023-12-05) <details<summarycompiler error</summary</details
It would be fixed by
<!-- 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. --I have tried to measure on a 32 core machine and got this ice after several tries. Steps to reproduce: I have got it 2 times in a row, so it should be reproducible. <!-- 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. --:
searched nightlies: from nightly-2023-11-03 to nightly-2023-11-09 regressed nightly: nightly-2023-11-07 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
modify labels: +A-parallel-queries
modify labels: +WG-compiler-parallel
Can you reproduce this bug using the latest nightly version to get the new error output?
I can build rustc from the sources if you need to check something.
That's all right. It's a same error with other issues
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'unexpected inference var std::option::Option<&'?16 [i32; ?0c: usize]'', 'thread 'rustc' panicked at 'unexpected inference var std::option::Option<&'?16 [i32; ?0c: usize]'' File: --snippet, probably from Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<perror[E0261]: use of undeclared lifetime name -- | 2 | fn constchunksexact<const N: usize(&self) -ConstChunksExact<'a, T, { N }; | ^^ undeclared lifetime | help: consider introducing lifetime here | 2 | fn constchunksexact<'a, const N: usize(&self) -ConstChunksExact<'a, T, { N }; | +++ help: consider introducing lifetime here | 1 | trait ConstChunksExactTrait<'a, T{ | +++ error[E0261]: use of undeclared lifetime name -- | 7 | struct ConstChunksExact<'rem, T: 'a, const N: usize{} | - ^^ undeclared lifetime | help: consider introducing lifetime here: error[E0046]: not all trait items implemented, missing: -- | 2 | fn constchunks_exact<const N: usize(&self) -ConstChunksExact<'a, T, { N }; |
from trait . 5 | impl<TConstChunksExactTrait<Tfor [T] {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ missing in implementation error[E0392]: lifetime parameter is never used -- | 7 | struct ConstChunksExact<'rem, T: 'a, const N: usize{} | ^^^^ unused lifetime parameter | = help: consider removing , referring to it in a field, or using a marker such as error[E0392]: type parameter is never used -- | 7 | struct ConstChunksExact<'rem, T: 'a, const N: usize{} | ^ unused type parameter | = help: consider removing , referring to it in a field, or using a marker such as error[E0207]: the const parameter is not constrained by the impl trait, self type, or predicates -- | 9 | impl<'a, T,
const N: usizeIterator for ConstChunksExact<'a, T, {}{ | ^^^^^^^^^^^^^^ unconstrained const parameter | = note: expressions using a const parameter must map each value to a distinct output value = note: proving the result of expressions other than the parameter are unique is not supported error[E0308]: mismatched types -- | 9 | impl<'a, T, const N: usizeIterator for ConstChunksExact<'a, T, {}{ | ^^ expected , found thread 'rustc' panicked at unexpected inference var std::option::Option<&'?16 [i32;
?0c: usize]stack backtrace: 0: 0x7ff8073a4912 - std::backtracers::backtrace::libunwind::trace::h2da6c6ec1776ed1b at 1: 0x7ff8073a4912 - std::backtracers::backtrace::traceunsynchronized::h0cb696e9cf0107ba at 2: 0x7ff8073a4912 - std::syscommon::backtrace::printfmt::hfb11ed7a7d38a028 at 3: 0x7ff8073a4912 - <std::syscommon::backtrace::print::DisplayBacktrace as core::fmt::Display::fmt::h1048d052a888b26c at 4: 0x7ff8073f5c8c - core::fmt::rt::Argument::fmt::hcf8265a03a389e34 at 5: 0x7ff8073f5c8c - core::fmt::write::hd12c3a84e62e1cec at 6: 0x7ff80739980f - std::io::Write::writefmt::h236993be0d5d91de at 7: 0x7ff8073a46e4 - std::syscommon::backtrace::print::he44e9b7b149d34c3 at 8: 0x7ff8073a46e4 - std::syscommon::backtrace::print::h6f8e8e3b9f052551 at 9: 0x7ff8073a73eb - std::panicking::defaulthook::{{closure}}::h321d04c9179dccca 10: 0x7ff8073a7143 - std::panicking::defaulthook::hd949d1362c2e5565 at 11: 0x7ff803fa68ef - std[]::panicking::updatehook::<alloc[]::boxed::Box<rustcdriverimpl[]::installicehook::{closure}::{closure} 12: 0x7ff8073a7b50 - <alloc::boxed::Box<F,
Aas core::ops::function::Fn<Args::call::h4f6c988be7bdee68 at 13: 0x7ff8073a7b50 - std::panicking::rustpanicwithhook::hb71de646be3b3469 at 14: 0x7ff8073a7892 - std::panicking::beginpanichandler::{{closure}}::hbca15a8a0a3dee72 at 15: 0x7ff8073a4de6 - std::syscommon::backtrace::rustendshortbacktrace::h885125d06f4d13f0 at 16: 0x7ff8073a75c4 - rustbeginunwind at 17: 0x7ff8073f21a5 - core::panicking::panicfmt::ha3facef8c988a935 at 18: 0x7ff80529d0a8 - <rustcborrowck[]::typecheck::relatetys::NllTypeRelating as rustcmiddle[]::ty::relate::TypeRelation::tys 19: 0x7ff80608d936 - <rustcborrowck[]::typecheck::TypeChecker::typeckmir 20: 0x7ff802afa5fa - rustcborrowck[]::typecheck::typecheck 21: 0x7ff802b34257 - rustcborrowck[]::nll::computeregions 22: 0x7ff80601edc1 - rustcborrowck[]::domirborrowck 23: 0x7ff806011128 - rustcborrowck[]::mirborrowck 24: 0x7ff806010c17 - rustcqueryimpl[]::plumbing::rustbeginshortbacktrace::<rustcqueryimpl[]::queryimpl::mirborrowck::dynamicquery::{closure}::{closure}, rustcmiddle[]::query::erase::Erased<[u8; 8usize]25: 0x7ff80540ff2e - rustcquerysystem[]::query::plumbing::tryexecutequery::<rustcqueryimpl[]::DynamicConfig<rustcquerysystem[]::query::caches::VecCache<rustcspan[]::defid::LocalDefId,
rustcmiddle[]::query::erase::Erased<[u8; 8usize], false, false, false, rustcqueryimpl[]::plumbing::QueryCtxt, false26: 0x7ff80540fa4c - rustcqueryimpl[]::queryimpl::mirborrowck::getquerynonincr::rustendshortbacktrace 27: 0x7ff80599919e - rustcinterface[]::passes::analysis 28: 0x7ff805998425 - rustcqueryimpl[]::plumbing::rustbeginshortbacktrace::<rustcqueryimpl[]::queryimpl::analysis::dynamicquery::{closure}::{closure}, rustcmiddle[]::query::erase::Erased<[u8; 1usize]29: 0x7ff806006165 - rustcquerysystem[]::query::plumbing::tryexecutequery::<rustcqueryimpl[]::DynamicConfig<rustcquerysystem[]::query::caches::SingleCache<rustcmiddle[]::query::erase::Erased<[u8; 1usize], false, false, false, rustcqueryimpl[]::plumbing::QueryCtxt, false30: 0x7ff806005ec9 - rustcqueryimpl[]::queryimpl::analysis::getquerynonincr::rustendshortbacktrace 31: 0x7ff805d5e284 - rustcinterface[]::interface::runcompiler::<core[]::result::Result<(), rustcspan[]::ErrorGuaranteed, rustcdriverimpl[]::runcompiler::{closure}::{closure} 32: 0x7ff806223805 - std[]::syscommon::backtrace::rustbeginshortbacktrace::<rustcinterface[]::util::runinthreadwithglobals<rustcinterface[]::util::runinthreadpoolwithglobals<rustcinterface[]::interface::runcompiler<core[]::result::Result<(), rustcspan[]::ErrorGuaranteed, rustcdriverimpl[]::runcompiler::{closure}::{closure}, core[]::result::Result<(), rustcspan[]::ErrorGuaranteed::{closure}, core[]::result::Result<(), rustcspan[]::ErrorGuaranteed::{closure}::{closure}, core[]::result::Result<(),
rustcspan[]::ErrorGuaranteed33: 0x7ff806223632 - <<std[]::thread::Builder::spawnunchecked<rustcinterface[]::util::runinthreadwithglobals<rustcinterface[]::util::runinthreadpoolwithglobals<rustcinterface[]::interface::runcompiler<core[]::result::Result<(), rustcspan[]::ErrorGuaranteed, rustcdriverimpl[]::runcompiler::{closure}::{closure}, core[]::result::Result<(), rustcspan[]::ErrorGuaranteed::{closure}, core[]::result::Result<(), rustcspan[]::ErrorGuaranteed::{closure}::{closure}, core[]::result::Result<(), rustcspan[]::ErrorGuaranteed::{closure} as core[]::ops::function::FnOnce<()::callonce::{shim:vtable} 34: 0x7ff8073b11e5 - <alloc::boxed::Box<F,Aas core::ops::function::FnOnce<Args::callonce::hab5d072bb143d8fe at 35: 0x7ff8073b11e5 - <alloc::boxed::Box<F,Aas core::ops::function::FnOnce<Args::callonce::he1f566ad483a8fda at 36: 0x7ff8073b11e5 - std::sys::pal::unix::thread::Thread::new::threadstart::h23d47a8da771b95c at 37: 0x7ff800ea955a - <unknown38: 0x7ff800f26a3c - <unknown39: 0x0 - <unknownerror: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: rustc 1.78.0-nightly ( 2024-03-15) running on x8664-unknown-linux-gnu query stack during panic: [mirborrowck] borrow-checking [analysis] running analysis passes on this crate end of query stack error: aborting due to 7 previous errors Some errors have detailed explanations: E0046, E0207, E0261, E0308, E0392. For more information about an error, try .
While logged in as on Linux:: the Rust repo The suggestion to run isn't helpful if you don't already have a Rust toolchain installed. That leaves: "Alternatively, use the pre-vendored dist component." It's completely unclear to me what this means or how to do it. Perhaps providing a link to documentation would be useful. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Oh this is very funny, is what rustup calls it, which is of course completely unhelpful in this scenario where you don't have rustup and are building from source. Mentoring instructions: should link to
Hmm, I guess for this particular scenario you might be building from a commit other than latest master as well. We do technically package it for individual commits: but AFAIK that isn't documented anywhere. Maybe we should add it to forge?
claim
hello, i'm taking the liberty of claiming this pull request, but I'd like some information. Should I propose a solution (like the curl command with the right url?) or just propose the documentation page?
claim
claim