nico wrote: Thanks for taking a look!
First, maybe it makes sense to check if we agree that this is a problem at all. If we don't agree on the problem, we certainly won't agree on a path forward. At least in my corner of the woods, "C++ has very long error messages" is a common trope, and it was my impression that this is a widely shared belief. (I certainly run into long error and hard to read error messages myself often while working on things!).I just tried a quick web search for "c++ long error message" and it seems to find lots of hits, and it found e.g. https://codegolf.stackexchange.com/questions/1956/generate-the-longest-error-message-in-c , which also backs this up a bit. So I thought maybe we could try and improve this a bit :) It's well possible we won't find the right path forward immediately, and people also have different tastes. So my bigger idea was the following, a sequence of 3 PRs (this is the 1st): 1. This PR 2. A second PR that (morally) extends felide-types a bit (spelling of that flag is a shed to be painted in that PR) 3. A `-fdiagnostics-brief` flag that's morally an alias for `-fno-diagnostics-show-note-snippets -fdiagnostics-elide-template-args -fshow-overloads=best -ftemplate-backtrace-limit=2 -fmacro-backtrace-limit=2 -fconstexpr-backtrace-limit=2 -fcaret-diagnostics-max-lines=1` (`-fdiagnostics-elide-template-args` is my local flag name for 2; subject to upstreaming, discussion, and change.) Then I thought we could put something in the release notes linking to a bug asking people to try that flag and leave feedback (and ask people working on LLVM itself to give it a try too) after the next release, and then maybe (*gasp*) actually change some of the defaults if people like any of the changes. Experimenting and maybe making some progress on this seems better to me than not the status quo. (But maybe folks disagree!) I really get the "expensive to support many flags" angle – (*) but also, this is a fairly small patch that doesn't add any new abstractions and fits in fairly neatly with the existing ones. (The patch for (2) above is similar.) Does that make sense? Do you think this general approach is something we should try? Should I drop this immediately and do other things instead? (I think there's even more we could do in this "usability of diags" area (push SARIF forward, something like `rustc --explain`, identifiers for error messages like we have them for warnings -- I think this was discussed a few times and has general support and just needs doing), and I might be motivated to try and push some of these too, but I wanted to start with what I thought are low hanging and potentially high-bang-for-buck changes.) *: (hand-typed em-dash with opt-- on macOS; all my comments on this PR 100% hand-written :P) https://github.com/llvm/llvm-project/pull/216250 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
