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.


Under nightly-2022-05-10 I would see this in the serial log: Under nightly-2022-07-08 I get It also fixed the problems I was having with the st7789 crate that led me to file this bug.


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:


<!-- ICE: 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.


The conversion traits are implemented for conversion between and , but it is not clear what byte order is used.
It is network order, but that should be documented on the impl.
doc team triage: this would make a great first PR. I am happy to mentor anyone who wants to tackle this issue.
I'd like to, is someone else working on this?
nope, please do! Ping me if you need any help


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!


I encounter an ICE: with rustc 1.41.0-nightly ( 2019-12-06) running on x86_64-pc-windows-msvc when compiling The Stable compiler outputs But Nightly crashed.
Confirmed on Linux too. <details<summaryBacktrace</summary</details
Reduced slightly:
cc
Really reduced: This comes from this unwrap: The used should be


<!-- 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


We need to add all SC constants for for . There's only two at the moment which I only to quickly fix an issue with .


Was just trying to read through std::fmt to understand how format values to a particular decimal point. I came across this set of examples, which don't do a good job of explaining the output of each, so it's difficult to visually pattern match what I type in to what comes out:
Sorry for the mess :sweat_smile: I guess it is clearer now.


<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: : I expected to see this happen: explanation suggestion compiles: Instead, this happened: explanation Suggestion does not compile: ` <!-- 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. --:


current beta is 'rustc 1.1.0-beta' but it should be 'rustc 1.1.0-beta.1'


<!-- ICE: 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 .


</p</details<!-- query stack: 5 | impl<TConstChunksExactTrait<Tfor [T] {} [mirborrowck] borrow-checking [analysis] running analysis passes on this crate --
cc


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


<!-- 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. --Given a public type, I expected all traits implemented by that type to be part of rustdoc JSON output. However, rustdoc JSON output sometimes does not include information about all the traits implemented by a type unless is specified. For example, in this : The following invocation on v3.1.18 generates JSON stating that is implemented for : However, the following invocation has no mention of for at all: Related to: :
cc
modify labels: +E-needs-mcve
Interestingly, rustdoc-json is providing no impls at all: norunn# use clap::{Command, Arg};nlet matches = Command::new("MyApp")n .arg(Arg::new("out")n .long("output")n .required(true)n .takesvalue(true))n .arg(Arg::new("debug")n .short('d')n .multipleoccurrences(true))n .arg(Arg::new("cfg")n .short('c')n .takesvalue(true))n .getmatches(); // builds the instance of ArgMatchesnn// to get information about the "cfg" argument we created, such as the value supplied we usen// various ArgMatches methods, such as ArgMatches::valueofnif let Some(c) = matches.valueof("cfg") {n println!("Value for -c: {}", c);n}nn// The ArgMatches::valueof method returns an Option because the user may not have suppliedn// that argument at runtime. But if we specified that the argument was "required" as we didn// with the "out" argument, we can safely unwrap because verifies that was actuallyn// used at runtime.nprintln!("Value for --output: {}", matches.valueof("out").unwrap());nn// You can check the presence of an argumentnif matches.ispresent("out") {n // Another way to check if an argument was present, or if it occurred multiple times is ton // use occurrencesof() which returns 0 if an argument isn't found at runtime, or then // number of times that it occurred, if it was.


To allow an argument to appear more thann // once, you must use the .multipleoccurrences(true) method, otherwise it will only return 1 or 0.n if matches.occurrences_of("debug") 2 {n println!("Debug mode is REALLY on, don't be crazy");n } else {n println!("Debug mode kind of on");n }n}n
Missing impls is probably a recent regression, see
MCVE produces () and with () modify labels: -E-needs-mcve
This is almost certanly due to searched nightlies: from nightly-2022-07-01 to nightly-2022-08-08 regressed nightly: nightly-2022-07-17 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
More minimal (no_core) Is correct in html ! and wrong in json


running produces this record for the type : I would expect "impls" to not be blank, since the matrix implements many traits and has a non-trait implementation as well. The paths entry also does not contain as well as many other types exported by the crate, is this expected ? I know that these paths included all exported types before : :
Now running with produces: So i think there's been a regression since then
Thank you for reporting labels +A-rustdoc-json +T-rustdoc
Seems like this could be another symptom of the regression reported as
This is the same issue as Items in a non-public module (ie accessed only via imports) have no impls


At some point between Rust 1.34.0 and 1.39.0, the ability to add documentation to reexported items was , but I can't find it mentioned in either or the rust- blog posts. Maybe this should be mentioned in the RELEASE notes for the version that that feature? I have a crate that I use to test stuff, and used to document this: !
This was changed in 1.38 (coincidentally also the release rust-std spiked from a 61.2 MB to 173.3 MB download). are you interested in making a PR?
Sure, what are the PRs that made this possible?
Oh I have no idea :laughing: I found it by bisecting.
Looks like is it


I hope this is not already known, but my searching has not turned up anything. Compiling a rust binary with the dependency panices in nightly. How to reproduce: a new rust binary. to dependencies in This gives the following output It compiles on stable and beta. Edit: Just running in gives the same result.
Tried a few different nightlies. And it looks like it broke sometime between and
I have managed to get a much smaller example. Compiling this on nightly gives the above panic:
Looks like it's fixed in the newest nightly ()
Bisecting between ... gives as the regression PR.


Was looking at the printout of llvm passes when I noticed that the functions that was inlined everywhere, and due to this was dead code, was optimized more after inlining. So as a test I at the line and this reduces the compile time of release build in racer by an average of 23%. I do not know if this is a good place to add this extra pass but maybe someone that knows how llvm works can use this information to speedup the compilation of release builds. was also wondering how this works in MIR I see that there is an inline pass but I can not find any dead code elimination
the stage1 compilation of rustc went from 828.89 to 691.75 secs with this fix on my computer but that is only a 15% improvement
15% is pretty significant.
Wow, great work!
That's some nice improvements! If you feel up to it, go ahead an submit a pull request with your suggested changes. That way someone with experience with LLVM is guaranteed to look at the patch and it won't get lost.
I believe the PR should be targeted at
:+1: If you want to push through this patch the general process works like this: Submit the patch against the currently active branch of (which is at the moment) Wait for it to get reviewed & merged Submit a pull request against which updates the submodule. If you have any questions about the process or want someone else to do this, just mention it here or contact me or someone else on one of the .
cc
cc
Ideally, the process should include discussion with upstream LLVM too.
Unfortunately it looks like we were a bit too eager to close this in :(
From what I have learned from the llvm maintainers I think that we have received the improvement that can be expected. The to good to be true improvements I measured was probably due to less optimizations was possible and resulted in less optimized code.


I tried to build on a new machine. Got this message: Which I'm used to. I googled a bit, installed , figured out how to get PATH set up, et cetera. Then I built again. And got this: I'm not sure, but: Isn't solely necessary in our build for building LLVM? if that's the case, then shouldn't both the failure and the failure be providing the same level of feedback (namely, suggesting that one side-step building LLVM altogether as an alternative option to downloading and installing )? (Or is the assumption here that will be used by so many crates, people should just bite bullet and install it? Even so, we could give better guidance up front about where to look for it.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I don't think cmake intentionally has a worse error, it's just that a bunch of people building from source for the first time have been confused what ninja is and where to get it. If you made a PR improving the error for cmake I'd approve it :)
label: +E-easy
claim
Hello I'd like to claim this issue if you're interested in releasing it.
Sorry about that Gave it a try but got sidetracked and wasn't really interested in doing it anymore
claim


The CI tests building with all our supported linkers: Rust's provided , ARM GCC's , and ARM GCC's . It recently encountered an error when using in nightly builds since . The most likely culprit is that the failing version has started to the linker arguments, which was not present in previous working versions. I wonder if we're meant to be adding some other argument to disable adding ? The error occurs with the cortex-m-rt CI and can be reproduced like so: Or viewed in CI . The error is: nightly-2023-07-02 nightly-2023-07-03 bisected to from PR modify labels: +regression-from-stable-to-nightly -regression-untriaged
shows that the default for the target is rust-lld. i wonder if the new code uses the default instead of the linker in -C linker for some reason?
You were not meant to do anything, sorry about that. I'll fix it.
I can't build a toolchain locally, via , which would be complete enough for this test to build. There are issues about missing core/std. I tried on a example, and can also reproduce the issue and investigate more there, and that and work. The code I in is asked to add CLI arguments for a flavor: this asks to link using via a c/c++ compiler, and why is . I assume that flavor is incorrect when using ? (I don't know who the target maintainers are, so I'll also ping the other 2 people involved in : and still work because they result in a non- request, and we don't do anything there as expected. For my own understanding: does use by default maybe ? And if so, I'd expect that explicitly specifying the linker would also fix the issue, à la which seems to work for me ? I'll look into why this surprising flavor is used in this situation, as it seems to be the pre-existing issue here uncovered by the PR, and report back. It could be an issue in the flavor inference, or some information missing in the targets' definitions, and so on.
Technically, the target builds. As a tier 2 target, we would strongly prefer it to not require additional antics to build. There was but I have taken lqd's remarks that this may be just exposed preexisting problems as a reason to set it slightly lower.


The linker flavor used is a mix between what can be inferred from the CLI () and the target's default linker flavor: there is no linker flavor on the CLI (and that also offers another workaround on nightly: ), so it will have to be inferred to . in  infers a cc hint, and no hint about lld. the target's is combined in with these hints. We have our , but there is no hint about lld, . It's . so we now have our flavor is the linker people are expected to use on supposed to be some ? Is the default linker and flavor in correct ? In the meantime, I'll see to change this so that the lld flags are only when the unstable MCP510 options are used, to keep this stable and unfortunate behavior unchanged when the CLI and target conflict instead of compose.
Thanks for looking into this quickly! Most people building for will use the default linker today. It works fine for (I believe) all Rust-only projects. However, it's not uncommon to use , maybe to use specific GCC linker script directives, or just when hunting down linker-related bugs. For both of those use cases there's no problem with nightly, and I think the default in thumb_base is therefore fine. Some people do need to use when linking with pre-compiled C libraries - I understand that using gcc pulls in a target specific libc, and a lot of pre-compiled C libraries will be trying to link against symbols it exports which Rust doesn't. I believe does delegate to . Passing either or does work to get a build without errors, though I don't have a test case handy to check it's actually getting what people need out of . I'll try and dig around a bit more for the specific use cases where it's required over .
My main recollection is that gcc requires you to put in front of your linker arguments and using ld directly you don't But I think and friends are gcc options not ld options so maybe ld won't bring in libc and the C startup automatically. I'll test it out shortly.
main.c: Compile object code: Link with GCC: Link with ld: This does imply that for trivial invocations will include both the default start code (which provides ) and newlib (the C library), whilst will not.


See also , where I set the default target for bare-metal SPARC to be gcc, precisely because the default libraries it links in are so useful - they include not only the start-up code (no idea how that works, didn't need to find out) but also a C library for talking to the stdout of a popular SPARC CPU emulator. So, yeah, GCC is a really useful linker driver in some scenarios and we don't want to stop that from working.
Thanks for the information, it's very helpful. The good news is that using GCC as a linker is still working . In the future where we switch to lld, maybe rustc will also need an explicit linker flavor here, to make sure the flavor it guesses actually matches your expectations. But that's a topic for another day/stabilization: in the more immediate future, things will return to normal for the target and 's tests in a day or two.
Thank you! Just to come back to this point: I was under the impression that Arm Ltd were maintaining the targets. However, they don't appear to have the platform-support documentation that is required for more recently targets. Maybe that could be addressed.
This is now on beta, reopening to track backport.
Pursuant to your concern I have opened to summarize the issue that affects indeed all our tier 2 targets.
The backport of has landed on beta in We can close this issue as fixed.


The build time of html5ever has gone up by more than 70% for debug builds recently: There are quite a few candidates for introducing this regression in the changeset: Would anybody from or care to bisect further?
The "tuple stress" benchmark is affected even more while most of the other things have improved. Maybe that gives a hint?
My first guess would be quadratic or exponential blowup. Maybe someone can do a ?
Yes, good idea!
Bisection for tuple-stress points to (cc Before that PR took ~4s and afterwards I killed it after 2m as I didn't want to wait for it to finish
That may also be the source of the html5ever regression. takes 10s before that commit (the entire time) and 21s afterwards.
Thanks, cc also &
Could you post instructions for replicating the slow down? Neither or I could reproduce it -- despite running perf on the appropriate commit range locally.
So should we revert that PR's commits?
sure yeah, using I did the equivalent of:
We should probably only run the disaggregation pass if the opt level is 1. That's what's done for the copy prop pass already
assuming and can reproduce I think yeah we'll probably want to start off by reverting and possibly doing what suggests in a follow-up
I cannot reproduce, which is odd, since I can't tell what the difference could be that would make this much of a difference...
No repro on macOS, although the c116 version is consistently slower than a272. <details</details
Ok I swear I'm not going crazy! I think though given this data it may only be reproducible on Ubuntu 16.04? I can reproduce with this : Can y'all reproduce the slowdown for html5ever?
Sure enough starting the docker image from 18.04 means I cannot reproduce the regression. Maybe some glibc bug was fixed which I was accidentally running into? The html5ever regression though is still worrisome and seems like it may not be connected to a glibc bug
I can repro the tuple-stress slow down on 16.04.4 LTS. indicates it is stuck at the step.


<details<summaryGDB backtrace sample</summary</details<details<summaryCode surrounding the call of that memmove</summary</details
Presuming the same two commits would be responsible for the html5ever regression, I also cannot reproduce it on 18.04 Ubuntu.
Using this dockerfile: I can reproduce the regression from 10s to 20s on html5ever. Starting from 18.04 it does indeed not show a regression. The perf server is indeed 16.04. Ok so it looks like this is a regression specific to something that changed between glibc 2.23 and 2.27. With the profiles it looks like it's something related to the efficiency of memcpy/memmove. It also seems like this isn't reproducible on OSX (thanks ). I can, however, reproduce it locally on Windows 64-bit MSVC. Since could reproduce a slightly slowdown on OSX, I wonder if these code paths do something like exercise a ton of moves? It may be the case that glibc optimized one of its routines in the 2.23 -2.27 transition (and OSX already had it). In that case it may appear like there's no regression on Linux/OSX but on glibc 2.23 and Windows they may have unoptimized versions of the routines causing slowdowns. All in all I think that this is a regression that is still worth fixing, despite it not immediately being applicable on glibc 2.27 or OSX. The fact that it affects somewhat-recent versions of Ubuntu and Windows is enough for me.
Isn't glibc 2.27 the version released after the spectre/meltdown/whatever fixes that slow (primarily Intel but to a lesser extent AMD as well) systems down?
No sorry glibc 2.27 is just what I tested. I've now narrowed it down (conveniently) to glibc 2.23 and 2.24. Ubuntu 16.04 ships with 2.23 and 16.10 ships with 2.24. On 2.24 I'm seeing a faster compilation Perusing the it looks like may be why we're not seeing the regression in newer Linux
Ok I've found the source of the regression, will post a PR soon.
It's a pleasure watching you folks work!


I've posted what I believe is a fix to
triage: P-high Has pending fix.


E.g. if a test doesn't have a fn it can prevent the test from ICEing because ICEing codepath might not yet be reached before compilation is aborted. In this case, the stderr should be printed to help the person figure out that "I forgor to annotate crate type" is the cause.
you can set env var which should print stdout, stderr and exit code
Oh right, good point, I forgor this existed. We should (I'll do this later unless you want to work on it): Mention this env var in the panic message for when the crashes test no longer crash. () Mention this env var in rustc-dev-guide. () EDIT: ended up duplicating some description of ` in because I would not have thought to look there for docs specifically.


Creating a recursive type with infinite size by removing a leads to an internal compiler error. Might be the same issue as . To reproduce this bug, run on this code: Replace by and run again: I expected to see this happen: Instead, this happened: :
triage: P-high. Removing nomination.
assigning to with expectation that they will delegate.
nominating to try to find someone to investigate this.
well spotted ;) Because this issue has the tag and the other doesn't I will post the incremental test here:
triage: Reassigning to self and in hopes that one of us will find time to investigate, since it seems to be an issue with the dep-graph/incr-comp infrastructure.
triage: Downgrading to P-medium. I still want to resolve this, but it simply does not warrant revisiting every week during T-compiler triage.
I encountered the same bug. I starting to create a new issue, but it's exactly the same than this one. In case it's needed, I uploaded the code on on the branch (there is two commits, the first is fine, the second generate the ICE) in case you want to validate your patch when you will eventually have time to fix it.
I am running into this issue as well. Since the corresponding pr has been merged 24 days ago and the latest version was tagged 14 days ago, I am not sure, if this error should have been fixed with . (I did not find the commit on the master but I am also unsure if it was squashed with other commits.) Therefore, I thought I would at least post my error as well, just in case this is supposed to work. In my case I have an enum which holds a struct which in turn references that enum. I know that this can't work and I know how the correct way of handling this scenario is, I just wanted to let you know that this crashes the compiler. If you need a more detailed code sample, let me know and I will try to reproduce the error outside of my project.


run Output: Miri: The underlying issue was found when reviewing the implementation of . The code is a reproduction to trigger the unsoundness. The implementation in question features: Where is turned into and dropped. Yes, that’s , not . The code for seems to be doing the same thing. For comparison: The code for (and the same thing for ) seems to properly use a … no actually, that’s a with zero lengths… notably the allocator is correct though. So the buggy code for should just switch to create a presumably. label I-unsound requires-nightly T-libs


<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --- ~Related release note: ~Related PR: ~ ~Though the PR describes the change is related to improve its truncation better, the changed behavior is rounding up which was down before.~ EDIT: The upper changes and issue . It is not related to this issue. I want to check if this is expected change or regression. I tried this code: I expected to see this happen: explanation Until 1.62.1, Instead, this happened: explanation In 1.63.0, <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Until 1.62.1 <!-- Provide the version you are using that has the regression. --:
-- that PR you linked landed in 1.60, not 1.63?
Oh, I am sorry. I probably didn't check how much I scrolled down from release note. Then which change would be related?


This function still takes its argument by explicit .
also,
I'm doing this, just waiting for tests.
Done, pending
Fixed in


Hey! Ran into what appears to be a bug - crate's exported macros each appear twice in the left sidebar: ! Toolchain versions (per log): rustc 1.60.0-nightly ( 2022-02-09), docsrs 0.6.0 ( 2022-02-01) Please let me know if I can provide additional info.
Thank you for the report! This is definitely not an issue with itself, but with rustdoc. is this known? Should a rustdoc issue be created?
Not known afaik. Please do file an issue (or transfer this one)!
Seems similar to
Thanks for transferring the issue. One difference between this and - both macros are exported using a wildcard in crate root (not rename):
Well, just another reexport issue. It's common around here. :laughing: I'll try to take a look in the next days.
This is what I have on currently nightly: ! So I guess it's fixed?
Trying locally with the latest nightly (, more current than that of issue open) I get the same initial landing page for but if I click on one of the macros listed (e.g. "drill down") duplicates still appear on the sidebar: ! So the tiny bug is still there, just deeper/hidden on the latest nightly?
Ah indeed! I can also reproduce it now. Will take another look tomorrow then.


Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. 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!
It looks like miri just has one instance of , which should be replaced with . Should be easy enough.
This can be closed when the miri submodule is bumped.


Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. 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! cc the PR reviewer, and -- nominating for prioritization.
Caused by
I'm working on this.


The following GitHub action fails with nightly-2024-02-27 but passes with nightly-2024-02-26 for (I believe) any project with a file: The error I got is the following: This only affects x8664-pc-windows-gnu (not MVSC), and switching from to fixes the issue. I have reproduced the issue in I may end up deleting that repo in the future, so for posterity, I've included all the code below: <details<summaryExample project to reproduce the issue:workflows (See above) src </detailsThe original discovery of this issue is reported in Running yielded the following for the latest nightly version without the issue: Running on three versions with_ the issue (the next nightly version, the latest nightly version, and the current beta) yielded the following: This issue is not present in rustc 1.77.2 (the latest stable version).
The imports should mostly be shared between msvc and gnu so the fact the targets differ is a bit puzzling. My hypothesis would be that mingw on Windows Server 2019 is using an older version of an import library that maps one or more functions to the wrong DLL. Specifically I think this could be caused by the import library. cc in case you've heard of anything like this before
I doubt it's a problem with the old MinGW-w64; in that case, the program would fail to link. I helped with a similar issue recently, and it was caused by the wrong being loaded. There are two DLLs called that, and if a manifest is not provided, Windows will load the wrong one:
Hm... I ran on both windows-2019 and windows-latest and the import tables do look different (see ). <details<summarywindows-2019</summary</details<details<summarywindows-latest</summary</detailsNote that is listed under in windows-2019 but it's more correctly listed under in windows-latest.
Yeah, that is probably the culprit but mingw-w64 links from since mid 2016: If it's caused by miingw-w64 toolchain preinstalled on image it must be terribly out of date.
Quite possibly it is that out of date. The other explanation would be it's coming from somewhere else, which Is a bit worrying.


Based on , my first impression is that mingw-w64 isn't preinstalled on the image. Unless Windows Subsystem for Linux is relevant, I assume that the mingw-w64 toolchain is installed as part of the run of .
Various tools like Perl might come with GCC. Could you determine location of and ?
I'm not sure. I've only been able to reproduce this via a GitHub action, not on my own machine, although I might be able to use something like to explore around. Alternatively, I could just run a fixed list of commands. If there's a set of commands I can run to answer any questions you have, please let me know. I'm not sure how the Rust toolchain determines which version of to run when building Rust code, but that seems like something you might know. EDIT: Based on your question, I might need to just run with the two applications you asked about. EDIT2: and are both in according to .
Here are the versions of based on running :
Thanks, apparently there was a bug in mingw-w64 fixed in 2020: IIRC this toolchain is older than that so it's indeed a bug in mingw-w64 shipped with this .
Oh, weird. also comes shipped with so this image generally has up-to-date packages. I also didn't see mingw or mingw-w64 mentioned anywhere in its README, so now I'm wondering if there's a bug in the image itself. I expect this means that no action will be needed for this particular issue unless we want to be more robust to bad environments like this. EDIT: It looks like it's defined here: EDIT2: It was documented after all. I had to search for "gcc", not "mingw".
I was rather confused because states that the latest version from the 8.x series is 8.0.2, but the version installed of in the the Windows 2019 image is 8.1.0, which seems like it shouldn't exist. However, based on the releases of , the number after the is probably what's important, which means that we're on version 6.0.0, which is indeed before the fix. I might ask in the project to see if it's worth updating mingw64 for this reason.


EDIT: Filed Depending on their response, if they decide not to update, it's possible could be fixed instead to stop trying to install Rust over an incompatible version of MinGW.
For some reason, my original issue description code snippet mentioned instead of . I think that's because I copy/pasted the wrong version, when I was seeing whether the workaround worked (which I believe it did). I apologize if that caused any confusion. I've now edited the description to fix this mistake.
Given that seems to be in progress and would close this issue, I mentioned that in for extra transparency.
Thank you for all your help on this! It's awesome that all this happened in only 4 days. I can confirm on my end that this issue is now fully resolved on the latest nightly release of Rust (2024-04-19).


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! cc the PR reviewer, and nominating for compiler team prioritization.
Cc The error is with the following backtrace
Ah but further up the call stack we have so I think this will be fixed by


I have pinned down the regression to a specific commit, thanks to recommending me . searched nightlies: from nightly-2024-07-28 to nightly-2024-07-30 regressed nightly: nightly-2024-07-30 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.9</summaryHost triple: aarch64-apple-darwin Reproduce with: : </details
Based on the commits in that rollup, I feel like might be the culprit, but it isn't obvious to me why that might be the case (cc
Thanks for the ping, will fix this.


<!-- 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 have the following code, split into two files: This code, as expected, produces , shown below. However, the help message at the bottom of the error appears to be referencing line 2 in , while displaying the filename , thus suggesting we add the annotation to a comment in . It should instead point to the in . <!-- 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
The issue is that in , the span we use to look up the file/line mapper is the primary span of the message, i.e. the error in


<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: Rustdoc compiles the documentation as for older toolchains (stable, < nightly-2022-08-10) or as it is happening for / Instead, this happened: Rustdoc reports an compiler error <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: nightly-2022-08-09 : : points to as merge that introduced this regression which is a roll-up PR. and are included there and seems to be rustdoc releated. Pinging and as authors of these PR's. <!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-nightly -regression-untriaged --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think the bug is coming from cc EDIT: also, would be quite useful to have a minimum code that we can use as a regression test.
Reducing compiler errors coming from diesel is quite hard and takes a lot of time. Diesel is already part of the rust compiler tests-suite, although in an older version. So it might be easier to just update this version to a current diesel version.
This is due to my PR. claim
is not documented inside the compiler so it wouldn't be very helpful unfortunately. Also, I didn't ask you specifically, just thought it might be useful to say it, so don't worry if you don't have time for it. :wink: Thanks !
The corresponding test code is here: I think it did not catch this issue as it uses an older diesel version (and it does not enable the corresponding feature flag).
I minimized this: And fix PR incoming.
This apparently was not fixed.
I can confirm that this is fixed for . Thank you all for the fast fix :tada:


Rust 1.70 build on Solaris sometimes files on some machines: I wonder whether it can do something with: ?!
are you running in parallel? that's not supported on solaris (you made the PR removing the build locking IIRC).
I see it does: . I think I should look once again if it's possible make to use fcntl locking (as it's now in `rustix... You can close the bug. Thank you!
Adding reference to main proble - isn't supported on Solaris due missing syscall).
I'm confused now. I have seen the same error even with (just one ocurance, not two as mentioned above). Also tried to dig closely how locking works and put into some debug prints with process id and lock file name. But later when I was inspecting still running process it didn't have any lock file open. No file descriptor no lock?!
did you clear the cache before running ? if the build directory gets into an inconsistent state we don't recover it automatically. i don't know what's going on with fd-lock, but the file that bootstrap locks is .
Everything is removed before new build...
exactly what command are you running and what is your
If I see it right, lock file is created/opened here: and the file descriptor for the lock file is closed on block exit here: Isn't it mean that locking isn't working even on Linux?
no, it's declared outside the block
Right. Unfortunatelly version 1.70.0 hasn't fix for this (my) regression. And the declaration is still insde the block.
we do not support old versions of rust. the only supported release is the latest stable release.
Isn't version 1.70.0 latest stable version? I'm just curious.
yes, you're right. i'm sorry. i think you should ask someone else for help on this issue. i am having trouble focusing today.
I run: and then: Where on some systems helps to run while on others it breaks it. When I look into the directory where rustc should be present:
i'm not sure why this is looking in . can you verify that exists? i wonder if is a hard-link to and that confuses on solaris.
It does: It's hardling. When I remove the asserion the build passes.


It wasn't true. It just didnt' hit the problem when the code was rebuilt. Now I'm trying following: It must execute sometime deps/bootstrap-[hash] instead of just bootstrap.


The Windows CI build with LLVM assertions enabled recently hung without an error message. It turned out to be an LLVM assertion failure resulting in a dialog which needed to be acknowledged, see According to the such a dialog is always displayed, but that is not the whole truth. Apparently can be used to customize assertion failure handling. We should definitely make assertions failures exit with error after printing failure information to stderr instead of displaying a dialog and hanging. label O-windows
Could this be part of why we're getting so many hangs in the CI?
That was responsible for four stuck builds recently. I don't think it was responsible for many timed out builds before that.
Posted with a possible solution.


Minimal reproducible example, targeting the STM32G030F6 microcontroller: This panics in the computation of when built with: Note: this had to be tested with in the dev profile, in order to fit on the small flash size on the chip. This was confirmed on the and toolchains. <details<summaryGDB backtrace at the panic</summary</details<details<summaryFull to build</summary</details<details<summarymemory.x for the STM32G030F6</summary</details
Would it be possible to provide the output for this test case?
This is inside compiler-builtins. The arguments in the stack trace seem all sorts of wrong all over the place, though. But the shift width passed into is what you'd expect. An ABI mismatch, maybe?
To elaborate on my remark above: the LLVM IR will only reveal a plain instruction, which becomes a libcall only in codegen. To the issue author: can you please also post the exact command you're building? I'm not able to reproduce a similar issue when using a based approach – in particular I see many more functions being inlined away, functions which in your case don't appear to be. This is what I was trying:
Cortex-M0+ uses , which is also shipped via rustup
Hm, I cannot reproduce inside QEMU (using , steps described below), but maybe I'm missing something (maybe the error only shows up on the real hardware and not in QEMU). Please correct me, if I'm wrong. <details<summaryReproduction</summary</details
Sorry, I will put together a package that fully demonstrates it and upload a tarball later today. I'll also provide the LLVM and executable output. To be clear, I wasn't building using any direct invocation of rustc, just with cargo.
So I managed to simplify the minimal example further a bit, as it turns out that simply panics too, since the formatter for integers involves multiplication. This is reflected in the following attachments. I have tested these on a live STM32G030 chip; the GDB backtrace is from that (over openocd through the SWD port). I don't consider myself knowledgable enough with QEMU to try to reproduce it there.


Complete example: Executable: <details<summaryGDB backtrace at panic</summary</details<details<summaryLLVM IR</summary</details
does it also reproduce on Rust stable (or beta)? Just to understand here if it's a regression or this issue has "always" been here (I suspect the latter)
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Good thinking... I just tested it on stable and it appears to not be present there (or at least not with all else equal). I confirmed the issue on again just to be sure I didn't change anything else. I'm not sure if there's a good way to bisect the rust toolchain to find the regression? If there is I may be able to script it to see if GDB reports a panic and use that. Of course QEMU would be better-suited for that, so I may try to repro in it as well.
cool then probably we can try to find the regression To bisect we use , it will download nightlies in a range of time and bisect them to find where the regression starts. You'll need to download the Rust sources beforehand (this repo) and then run it like: should be 755 and something like: cargo-bisect will then download nightlies. The first one must not reproduce the issue, so if it does, move a bit back in time until you hit one of the last good nightly. If everything goes well you should get an ouput similar to Thanks a lot for trying to bisect the issue! :-) label regression-from-stable-to-nightly
Here's the report: searched nightlies: from nightly-2021-04-01 to nightly-2021-06-05 regressed nightly: nightly-2021-05-15 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:
That is a huge commit, but if it helps, I have a hunch that the regression may actually be in , since a) the version of it changed as part of that commit and b) that's where the implementaiton of this is.


On the other hand, the connection to is weird. Before reporting the issue I did delve into the source but most of the arithmetic implementation stuff kinda went over my head unfortunately.
This is highly likely to slip into stable next week -- let's ping arm to at least get some more eyes on it (doesn't look like that was done yet).
Error: Parsing ping command in failed: ...'t ping arm' ' to at lea'... Please let know if you're having trouble with this bot.
ping arm
Hey ARM Group! This bug has been identified as a good "ARM candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
I can reproduce this on qemu. I'm not sure precisely what I'm doing differently to but I'm using the source tarball uploaded (plus a modified memory layout for the QEMU machine). Possibly in the cargo config would do it. From the last working rust commit bumping compiler-builtins to 0.1.40 (from 0.1.39) is enough to trigger this. Unfortunately, patching out compilerbuiltins to a local path (checked out to 0.1.39) also seems to reliably trigger it so I haven't been able to narrow down to a specific compilerbuiltins commit. Additionally I can't reproduce on , only v6.
That matches what I observed on real hardware as well.
54 stable will be built today and released on Thursday, this will unfortunately have to slip into stable :( The target is not tier 1 so this won't block the release, but it will be in the compatibility notes section.
Is the build process documented somewhere? Is it a highly optimized binary?
The build itself is done by our normal CI and the full release process is . The build doesn't take that long to finish though. The Release Team prepares the final release on Monday to be able to publish a pre-release on Monday evening, allowing testing from the wider community before the actual release goes out. It's possible to do a rebuild after Monday if critical issues are found and need to be fixed, but is not a Tier 1 target so a fix for this would likely not result in a rebuild, and would slip into 1.55.
Thanks!


I noted that the python scripts use the aws cli instead of the excellent boto3 library. But probably the scripts are battle proof by now.
This is a bug in LLVM's expansion of 128-bit shifts: The 128-bit shift is expanded to a series of 64-bit shift via . Note how the shift value in is only masked with before being passed to . This means that the shift value passed to may be larger than 64, which is UB according to the specification for (shift value must be < 64).
A bisect on compiler-builtins leads to this commit as the incidental "cause": Reverting it does fix this bug if a quick & dirty fix is wanted.
On second thought, I don't think this is an LLVM bug: it seems that the code calls with an out-of-range shift, but then doesn't actually use the result of that call in that case. I opened which should fix this, could someone test to see if this actually resolves the issue?
looks fixed to me. Nice work!


I tried this code: I expected to see this happen: rustc prints the target spec successfully, because it knows it exists: Instead, this happened: rustc fails to load the LLVM specification: Note that this is different from the error we emit for an unrecognized target: Also, this only happens for local builds, because we don't use the LLVM in the component in rustup, only when building rustc from source. ... wtf ??? HEAD is branched from
cc do you know what could be going wrong here?
Thank you for bringing this to my attention. It is possible that the locally builds has enabled , and that prebuilt LLVM does not support LoongArch architecture. It would be great if you could provide specific steps to reproduce. Thank you.
Yes, that's exactly what's happened, I have download-ci-llvm enabled and the prebuilt LLVM differs. Here's steps to reproduce:
The RustDev component builds LLVM here: but I'm not sure how that differs from the component?
I think the difference is that the of ci-llvm does not contain LoongArch, but locally it does. Is it time to update ci-llvm?
Maybe need to bump download-ci-llvm-stamp to pick up the LoongArch enablement?
Thank you for catching that. I was mistaken to think that the cached prebuilt ci-llvm would automatically update over time.
no worries :) it updates every six weeks when we make a new release, or if the submodule is updated, but it's cached until then so it's not constantly re-uploaded on every change to bootstrap.
Is there any way CI could help prevent such problems? Like, complain if gets changed but the stamp file does not, or something like that?
we can use heuristics, but they're only heuristics and I wouldn't want to fail CI on them. That said, having rustbot leave a comment if you touch rustc_llvm or seems reasonable, so the PR author can make a judgement call but also doesn't forget about the stamp.


It seems pretty strange to me that the env variable would take precedence over --config. It would be nice to switch the precedence. cc Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Added in ; it seems like it makes sense for --config to override, though probably not typically all that useful. Happy to see a PR, should be pretty easy so marking as such.
claim


I tried this code: I expected it to work on Windows 7 the same as it works on other platforms. Instead, this happened: the code get stuck in the initialization of logging, we acquired same-ish stack from multiple people using Windows 7 It was always calling ! On Windows 10 as under Wine the application starts normally My rust code produces DLL that is loaded by C++ application from 10 years ago Latest working version: Earliest version that gets stuck:
seems possibly relevant, but since this is just hanging, I’m not sure we can blame it all on snake oil this time. Though maybe? Wouldn’t be the first time it breaks the system in incomprehensible ways. First and foremost – could you minimize the reproducer? Both from the perspective of the Rust code (sounds like simply calling from should suffice?) and the OS setup (does this occur on a fresh OS install? If not, what modifications are necessary for the reduced reproducer to start hanging)
The nightly that it first started failing under is the first nightly after was merged, which just happens to be directly related to ? That's really whack given that the stack trace above shows the hang taking place just before any of the changes that PR introduced are invoked.
I personally do not have Windows 7, and would prefer not not bother players with more testing unless really necessary. But I can confirm that at least one of the systems was clean Windows 7 Home Premium from . And calling directly seems pretty complicated :( It requires calling which still requires knowing which algorithm to chose, and what flags to use :( I also see this in the documentation: and this in the code: , but unfortunately I can not say how relevant that it.
It's unlikely to be a problem with itself as that works in the earlier version. Is this code being used in ? In any case, I think the fix here is to simplify the rng code so it's as close to the old version as possible.
Yes logging is initialized in DllMain, I will soon post a very small example
So it is related to it being library.


It have something to do with initializing the logs in , but I have no clue what specific small detail it is that breaks it <details<summaryExe code (not much interesting)</summary<p</p</details<details<summaryDLL code</summary rust-toolchain </p</details
Ok, I've submitted a fix. See the PR linked above. is tricky because of the loader lock and other tricks the OS does while a dll is loading.
I know is tricky, but is there any better option to do initialization, if I do not control the exe? And I need to fix the exe (by doing memory patches) before it reaches its .
Possibly not, which is why I filed a fix. Using the std in only works on a "best effort" basis. We do try to support it as much as reasonably possible but there are always going to be limitations due to the OS.
I get maybe a bit crazy idea, but my DLL hooks functions anyway, so if I would limit to and before the hooked main do my initialization. (for my use case any time before main is good enough) Would that eliminate wast majority of potential breaks related to ? Or is it not worth it?
Calling load_library in is susceptible to deadlocks unless the library is already loaded. I think you might just need to be very careful about the dependencies you use. Maybe there's a different or lighter weight logger you can use in place of log4js that doesn't use HashSet?
On further inspection it seems unlikely that fixes the issue although I still think it's a good cleanup and simplification (so I stand by my r+). That is, looking at your back trace... the deadlock you're hitting is from inside BCryptGenRandom itself, not from our code that synchronizes while calling it. It looks like BCryptGenRandom does some synchronizing when getting the preferred RNG (I guess). My hunch is for whatever reason this ends up needing to take the loader lock, and because the loader lock is already held inside , this causes a deadlock. If this is the case, I don't think there's a way for us to solve it... we can't detect it this in advance, nor is there a good alternative approach we can take that doesn't make things worse when outside (and/or on newer systems, which apparently works?). So I'm not sure what we can do about this.


To be clear, we (at least at the moment) don't really support calling into libstd from initialization contexts like DllMain. We sometimes fix bugs from this it, but mostly on a best-effort basis, which depending on stuff like severity/impact/maintance burden/hackiness/the weather/etc, all of which is mostly judged on an ad-hoc basis. Even when we fix it, there's no guarantee it'd going to keep working in the future. Given that it's only broken on Win7[^1] and there doesn't seem to be a great approach that wouldn't make things worse outside of it (and/or for on newer windows), I'm inclined to just say... sorry, it's not really supported. Anyway, while things from libstd like HashMap (well, the it uses in particular) is unlikely to be viable in DllMain (at least on win7), I think things from liballoc should be fine (so long as your allocator supports it), so my recommendation might be to switch to using /, which shouldn't have this issue. Another option would be to use a different hasher that doesn't need randomness, but be careful about that. [^1]: It may be worth reconsidering if this happens on newer Windows as well. There are some... unpleasant approaches we could consider, but I don't think they're worth it for Win7 given how close to EOL it is, and the fact that we don't really support use from DllMain anyway.
I am loading an dll from DLL main for years now, and you just told me that Microsoft can screw me over at any time Well thanks for warning. I will keep doing that and hope Microsoft will never change that.
If you scroll down this page it has a list of things Microsoft says you should never do in DllMain:
This is what I was saying before about the stack trace not actually reflecting the changes -- but I also mentioned the bizarre coincidence that this hang bisects to exactly the same nightly as the one with the patch. I agree with keeping the revised changes in all cases and libstd support being a best-effort deal, but I'm guessing that something in how/what gets locked/attempted before the call into changes the state in some unsupported way that caused the bug to surface. I'd be curious what Application Verifier finds if you run it against a minimum repro.


I tried Application Verifier, because I was wondering what it does. My code is in the dll, and it seems to not work for only dll, so I needed to enable the tests for the exe directly. did not catch anything. But what is bit more funny is that enabling causes the application to fail so early that none of my code is executed... (at least if I set it up correctly and understand what it is doing)


<!-- 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. --Minimized from a program was trying to debug. I tried this code: I expected to see this happen: Instead, this happened: I see this on aarch64 and not on x86_64. I don't have access to any other architectures. Output is as expected with . I can also observe this bug on the previous stable (1.56.1), current beta (1.58.0-beta.3) and current nightly ( 2022-01-10). :
Was able to also test Rust 1.53 & 1.55, both perform as expected and show i: 0
Are the numbers printed the same every time or do they vary?
Consistently on the problem arch & compilers
Thanks. The reason I was asking is that, if you're reading invalid memory, the result is usually random. Since this result is consistent, something else is probably going on.
For the sake of convenience, could you please provide the output for this program?
here you go:
It might be a coincidence but, is (4 bytes in 32-bits) and rounded to the . Seems like maybe the bits are being inverted?
~I'm able to reproduce with , but if I emit the IR and then compile it with , I do not see the issue.~ I get different IR if I compile with vs. the entire command from . Only the 2nd has the bug. Edit: It's caused by . Lowering it to removes the problem.
When I use the llc from the rustup toolchain, I see LLVM going wild with clobbers: Note that also gets passed , so we're actually converting some condition flags to float, which makes about zero sense. Weirdly I don't see this when using the llc from my local rust build :/
For this example, the llc distributed by rustup produces (with ): While my own build produces:
Looks like it works if LLVM is compiled with assertions and breaks when compiled without assertions :(
Are you saying that you can reproduce two different results using the same IR? I was seeing the issue with distributed from Homebrew. Not sure if that's compiled with or without assertions.


I only see the problem with IR generated with and compiling with . This is the line of IR that is causing the issues. It is only present with and removing it fixes the bug: Additionally, it's only a problem if I assign to the spill directly. If I store a constant or use a temporary, the issue goes away.
seems like it may be relevant. Switching to fixes the miscompilation.
Bisect shows this is fixed by on main. Edit: It looks that shortly after that landed and the change was reverted again.
The revert comment suggests that it should be fixed by . Are you able to confirm?
I've filed to check whether we can still get this in 13.0.1, though probably not. In that case I'll cherry-pick into our fork.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical


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!
Ah, I see now. That PR removes splats (hopefully temporarily), and unfortunately, because of how natural it is, a few tests for Miri already use the splatting syntax. Yes, I can clean this up.
Yeah I just tried and was happy to see it work. :)
Fix happening on the Miri side in (it was so easy I just quickly did it)


I was just investigating a that Fedora's rust binaries for armv7hl use NEON, but they should not per , supposedly fixed in . (Fedora's build is 1.11, but I applied that patch.) I can see the exact same issue in the latest official , whose version file says . In particular, they flagged that as a problem. I'm no ARM expert, but from it appears the registers are NEON-only. I believe those instructions using are also a problem, because with VFP3-D16 we should only have to .
Hm looks like it's definitely still there:
( TIL of ! :open_mouth: )
Just to confirm: No . This doesn't explicitly mention vs. though. I ran on all binaries in . I see no mention of NEON registers. I see uses of -, but no higher, so I think is OK too. I'll know better if someone with a limited armv7 actually tries to run this, but LGTM!
Thanks for the confirmation


This program takes an inordinate amount of time and memory to compile (it's worse if the array is actually used, but this is a minimal test case): const SIZE: usize = 1 << 30; static SLICE: [u8; SIZE] = [0u8; SIZE]; fn main() {} I was hoping this would be a viable way to get a big chunk of so I don't have to depend on an crate to get a lot of static zeroes, but the effect on compile time makes that impractical. If I run , the big offender is: Although the time (and memory) is reportedly spent checking lints, setting doesn't make any difference. I'm guessing the "lint checking" pass includes some things that need to be checked even if lints are suppressed? If not, it seems like a separate issue is that a lot of work could be saved with cap-lints set (e.g. when compiling dependencies). Here are the top results from , for : So it looks like miri is actually creating the array and folding over it. I know it's not going to find any problems, because I have ECC memory :laughing:. There are already some bugs relating to slow compilation of large arrays, with the most relevant I could find being , . I think this is separate from those cases because: the input in this case is a [0; _] array, whereas the others initialize arrays from sequences of elements those cases seem to refer to superlinear runtime; this issue appears roughly linear in time and space and only becomes noticeable for much larger arrays the bottleneck in this case occurs during lint checking, which I didn't see in any other array performance bugs
Have you seen any improvement after ?
I've wondered before whether we should special-case constants whose bits are all defined and zero. I'll open a discussion in the const-eval zulip channel.
I also ran into this problem. has that discussion happened?
Kind of. We will have special treatment for constants that consist solely of undef bytes (see ). This scheme can likely be extended to support all bytes being zero withour requiring time or space overhead.
I opened for this.
was closed, are there still plans to implement this?
Not right now... there are other more important construction sites in const eval.


url: function: asref() Examples: Perhaps I'm just confused, but shouldn't that say: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Transferring to the rust-lang/rust repository, as that is where the standard library documentation is. I think it is trying to illustrate the conversion from → → . The text is just eliding the middle step, and explaining where it is starting from and where it is finishing.
No, that seems fine; what confuses you (or leads you to the &str conclusion)? I could follow but not . Perhaps you're thinking the impl on would make the contain or such?
I guess I'm extremely confused then. If I have an , what good does an do me? If I have &Some( "fubar" ), how does that translate to a usize? Is it giving me the length of the string or it's pointer in memory? Neither seems useful nor relevant to the description of "Converts from &Option<Tto Option<&T.".
You can call . just describes the example code's functionality, not 's. It's showing one of the ways you could use .
Okay, sorry, I understand now that comment is talking about the upcoming example instead of discussing as_ref() in general. In order to help others not experience the same confusion I did, perhaps I could suggest a tweak to the wording, such as: ?
memory address
claim


I was under the impression that should work on stable channel with version 1.51, however using the example code from I get rustc -Vv output (its the ):
attributes are used to enable unstable/gated features in the nightly compiler. Once a feature stabilizes, the attribute is no longer required.
I think the compiler should suggest removing the feature gate if it's been stabilized.
I see, I was unsure whether the error message was referring to the referred feature or the feature flag itself (since the example code of the stabilize PR was using it too I was assuming the former). And yes, removing the feature line from the example code makes it compile, thanks. Is there any way to make rustc ignore the feature flag and try to compile it anyway? The crate I want to use still has it included and I'd prefer not having to remove it manually until it gets removed upstream. (re-opening since seems to think its a valid issue/suggestion)
No, you'll need to either patch the crate or fix it upstream.


searched nightlies: from nightly-2024-03-07 to nightly-2024-03-10 regressed nightly: nightly-2024-03-09 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.8</summaryHost triple: aarch64-apple-darwin Reproduce with: </details modify labels: +regression-from-stable-to-nightly -regression-untriaged
I suspect caused this regression, but I don't know how to use to test this pr(I tried some times but all failed). Do you have any ideas about this?
if you use the latest version of cargo-bisect-rustc it will bisect the roll-up for you.
Hi, I'm using the latest version of , but seems that it fails to bisect the roll-up. Here's the complete log: bash cargo bisect-rustc --start 2024-03-08 --end 2024-03-09
It does bisect to for me. (With this visitor change in particular )
The fix has landed on master. Reopening to track beta backport.
Hi, 1.77.0 has been released, can this be backported to beta now?
I wasn’t at the weekly meeting and I don’t know for sure: is not yet marked as accepted for backport (it may just be an oversight in labeling, I’ll try to find out). Once that is done though, the release team, I believe, will backport it.
updated labels on (sorry for the delay)
That was backported in .


Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. 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! cc the PR reviewer, and -- nominating for prioritization.
I suspect the or-pattern PR, , is to blame.
Fix for Clippy repo:


The unbounded channel implementation from can segfault due to what looks like a race condition when dropping channel senders and receivers. You can find a repro at Unfortunately it is not minimal at all, since it depends on the timely-dataflow crate, which is the actual channel user. I hope it is still self-contained enough that people familiar with the channel implementation can run it and use it as a starting point for debugging. Run the example like this: On some machines it will segfault after some time, e.g.: The segfault happens inside , as visible in the gdb backtrace below. The same segfault also happens with . You can reproduce this by reverting the second-to-last commit on the repro branch. I understand that is a port of , so that's not surprising. : I can reproduce the segfault on nightly as well. The segfault is not reproducible on all machines! We were able to reproduce it on: a c5.2xlarge EC2 instance running Ubuntu an AMD Threadripper Thinkpad running Debian an Intel i5-8250U Dell XPS 13 running Arch Linux It doesn't seem to reproduce on: an M1 MacBook Pro Also note that the repro is using more and more memory over time. That is because the different worker threads create and drop dataflows at different speeds and timely-dataflow keeps per-dataflow communication state (including channels) around until the last worker has dropped the dataflow. It is possible to avoid that by adding a that lets late workers catch up, but in my experience that also stops the segfault from happening. <details<summaryBacktrace</summary<p</p</details
Here are the results of some initial investigation I have been doing. I used , but I assume the results will apply to the std port as well: The segfault happens in . In the linked line, is a null pointer, and so is . It seems like there is an inconsistency between the channel's and . is pointing to nothing while points to a block. I observed the following variable assignments at the time of the segfault: If I change all the atomic orderings in to , the segfault still occurs. This suggests that the issue is not caused by the usage of too-weak orderings. If I add an after , it is triggered under the repro.


This is where the sender is advancing and it seems plausible that this is the place where the inconsistency between and described above is introduced. I couldn't figure out why becomes a null pointer. The same method makes sure that the head is allocated previously, so some other thread must set it to null after the check.
cc
This suggests that the issue is not caused by the usage of too-weak orderings. I wouldn't be so quick to write off an ordering issue, the race condition could require stronger synchronization to fix (e.g. fences).
The segfault did occur (after about 5 minutes of runtime) on my Macbook Pro with an Intel Core i7 processor running macOS 13.3 and rustc 1.68.2. So whatever is causing this, it's not exclusive to Linux.
I have a feeling the issue is to do with a CAS failure when updating the tail not synchronizing with the update to head. If the thread that actually makes the update is preempted, the second thread might continue with the assumption that head has been updated, which might matter if it quickly writes to the entire block and the channel is disconnected before the head is ever touched. I haven't verified if this is possible, but it would be extremely rare if it is, which explains why this issue hasn't been hit before.