Too many errors on one line, make fewer.
I don't regret reading this comment before clicking the link
There was one that went something like "a typedef (or something) at this point was a complete surprise to me.'
Better than the infamous PHP error message made in Hebrew: T_PAAMAYIM_NEKUDOTAYIM
While those are funny, I'd hate using a compiler that actually gave me error messages like that.
everyone opines about lovely rust error messages are. but in there is 'you really need to add lifetime annotations'. advice, which is followed, will result in days of mad refactoring, only to discover that was a _really bad plan_.
I think they were an inspiration for most modern languages. Either directly or indirectly.
If you enjoy tight feedback loops and want something even quicker than "rebuild on save", you should try something like Clojure and hook up your editor to a REPL running in the background. Rather than "recompile the whole program on save", you can send small snippets to be evaluated in the live environment, updating your program on the fly :)
I was fairly happy doing REPL development with Scheme, and then I decided to give Common Lisp a try and I discovered what REAL REPL-driven development is.
The first time I changed some data representation from a defclass to a defstruct and SBCL asked me what I wanted to do with existing instances of the type was mindblowing.
In OCaml, if your pattern match is non-exhaustive, then the compiler generates example patterns that you aren't accounting for in addition to showing the missing type.
Here's an example: https://stackoverflow.com/questions/22737031/this-pattern-ma...
The first time I tried writing a C++ program with templates (very early on, like mid-late 90s), the compiler error messages were longer than the little program I was trying to write. It put me off on the language and the compiler so much that I went back to plain C and off into Perl and other languages, and never really got back to it.
> The editor should try to find if 'file:5' exist and open it if so, if it doesn't it should try to open 'foo' and then go to line 5.
Opening a file is often done in creation, and `file:5` is a perfectly valid filename, so it's a bit debatable for a default.
OTOH in Emacs you should be able to define a find-file-not-found-functions hook and implement whatever fallback you want. I assume `emacs <file>` calls `find-file` after it's initialised the editor itself.
> Opening a file is often done in creation, and `file:5` is a perfectly valid filename, so it's a bit debatable for a default.
It gets even more fun on Windows! Giving a filename of `foo:5` can result in a file called `foo` with an alternate datastream called `5`.
> Opening a file is often done in creation, and `file:5` is a perfectly valid filename, so it's a bit debatable for a default
You're right, but even as an option I think it'd be nice.
Visual Studio Code does this (see "File links"): <https://code.visualstudio.com/docs/terminal/basics#_links>
That works in Emacs compilation buffers. You can also define custom patterns to match the output formats of different compilers.
It works with kwrite/kate/kdevelop.
JetBrains products do this for lots of stuff if you use the built in terminal to launch stuff or their runner.
Maybe as an opt-in (mode or blanket approval), having to continue on every compiler error which has a fixer would be rather frustrating.
Clippy supports fixes, but will only apply them if `--fix` is supplied. It does not ask for individual case, the assumptions likely being that if you're running this opt-in you can probably do so with a clean working copy and revert whichever fixes you didn't want or are incorrect.
An other issue is if you're providing fixers for suggestions, the fixer has to be extremely reliable, not a 90% thing, because replacing broken code by possibly subtler broken code is not great.
On top of what others said, cargo is looking to further improve the fix workflow.
Right now, some errors offer fixes and these are marked machine-applicable. cargo-fix will apply these. The workflow was originally written for Edition migrations and has had little attention past that. Changes are applied in bulk and the worktree must be clean. There are known bugs and it isn't trusted to fix errors.
We want to slowly raise the visibility so we can collect feedback and gain more confidence in it. The first thing we did is tell users when there is something for cargo fix to do when getting compiler errors. Currently, this is limited to warnings and the nightly toolchain. I look forward to expanding this to more users (myself included).
Both Rust (via 'cargo fix') and Clang (via `clang-tidy -fix` have ways of doing this, I don't think I've seen someone offer this automatically/interactively though.
I don't think I've ever used them, but I've ABSOLUTELY used suggested fixes from LSP/rust-analyzer tools, which fit much more into my typical workflow. For things like match statements in Rust (which need to be exhaustive), I now have muscle memory to just write an empty match statement, and trigger the first LSP/r-a suggestion, which fills the match block with placeholder items.
I guess I see LSP as my "compiler in interactive mode" interface (even if that isn't EXACTLY true).