https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120676
--- Comment #5 from Larry Smith <admin at hexadigm dot com> --- > I'm somewhat surprised actually that 114990 is working now, but in GCC15 we > fixed some issues with too much being emitted in the module CMI so that may > have hidden the issue. (Feel free to close the PR if it's no longer > relevant though; I'm currently using 99000 as the dup target for all these > kinds of bugs regardless.) Haven't done any major testing of 114990 actually (given the new issue I'm dealing with in the thread we're now discussing), but I posted a link to demo the 114990 https://godbolt.org/z/sh3c3TK8Y. The problem seems to be gone as of GCC 15.1. It compiles without errors now anyway if you select GCC 15.1. Will look into it further once I get past the issue in this new thread. > You're right that there's desire, but the reality is that there's a lot of > things to do and very few people to do it. The original developer of > modules in GCC hasn't been active for a while now. Jason Merrill and > Patrick Palka have been very helpful but both appear to be working on lots > of other things. Instead, I've been working on modules as a "spare time" > project for the last year and a half or so, and like to think I've made some > good progress given those constraints, but ultimately my "real" job and > responsibilities have to take precedence! Agreed, everyone needs to make the decision on what to work on of course, based on their own judgment about what should take priority (and presumably the feedback coming from others I assume). Their "real job and responsibilities" will always take final precedence though of course (so understood). > (Part of the issue has also always been a lack of bug reports: we know > support is incomplete, but apart from a couple of major features and a bunch > of super minor issues I haven't had a chance to work on yet I don't know > what bugs are left. So thank you again for giving the support a spin and > reporting any problems you find!) No worries. I know from plenty of experience (programming for decades), that very few programmers will report bugs unless it directly affects them (blocking issues in particular of course). Otherwise they may complain about them, try to find a work-around for them, etc., but not actually report them so they can be fixed (either no interest in doing so and/or no time, and it often does take a time-consuming effort to properly report them, including creating a minimally reproducible example which I personally always try to do myself, but for this particular bug it was way too much work and also involves an "internal compiler error" as well). > But yeah, the issue is more that there aren't enough resources in general, > and although modules are definitely nice to have, people are also clamouring > for improved support on... lots of other things. So unless funding (or I > guess more pertinently, people) materialise, slow and steady will have to be > the way to go. Yes, almost always an issue (lack of resources), and people requesting improved support for "my favorite feature X" (with a very large alphabet of features beyond just "X"). Modules however offer significant gains over many other features IMHO. The elimination of header dependency misery and significantly faster compile times can (theoretically and in practice) *greatly* improve everyone's productivity, so it would be on my own personal short list of important features "X" (and moreover, the meat and potatoes of most C++ development involves features that have been around for many years now, so the actual tangible benefit of most new features is relatively limited IMHO - modules however, at least for new development since most existing ".h" apps are unlikely to introduce them, offer a *significant* benefit compared to most other new features). In any case, thanks again for your assistance (and your own contribution to modules - very much appreciated!)
