Is there a way to get rustc to only output the first few errors when compiling with Cargo, or even better, to print the oldest errors last? It seems the default threshold for aborting the compile is set quite high:
error: aborting due to 25 previous errors
I don't have the patience to scroll through 6-10 pages of text to find the first error.
Normally I would handle this by compiling inside my editor (vim), but the vim configuration that ships with rust doesn't seem to be setting errorformat properly.
Piping to a pager is also failing for some reason:
cargo test | less
cargo test writes errors to stderr, so you have to redirect stderr to stdout like this:
cargo test --color always 2>&1 | less -r
Related
I am writing a Rust program with some C integration so I'm using a custom build script. In this script, I pass -L <path to library> to rustc, but this works only if <path to library> does not contain a space.
The exact line in the build.rs:
println!(r"cargo:rustc-flags= -L {}/target/sdsl/sdsl_install/lib -l sdsl -l divsufsort -l divsufsort64 -l stdc++", current_dir);
If current_dir contains a space I get this error
error: Only `-l` and `-L` flags are allowed in build script of `top_tree_compression v0.1.0 (file:///home/jan/Uni/Bachelorarbeit/Programme/Top_Tree%20Compression)`: `-L /home/jan/Uni/Bachelorarbeit/Programme/Top_Tree Compression/target/sdsl/sdsl_install/lib -l sdsl -l divsufsort -l divsufsort64 -l stdc++`
I tried to write a \ before the space to escape it but it gives me the same error. Then I tried to replace the space with %20 because in the error message the space was replaced with this, but then I get a linking error because the path is not correct.
It appears you cannot as of Rust 1.29. The source code for the current master of Cargo:
let mut flags_iter = value
.split(|c: char| c.is_whitespace())
.filter(|w| w.chars().any(|c| !c.is_whitespace()));
This naively splits the argument on any whitespace, regardless of where it occurs. This seems to be a bug or limitation of Cargo and you should look for an already-filed issue or file one yourself.
That being said, if you use the more fit-for-purpose rustc-link-lib and rustc-link-search parameters, spaces work fine:
println!(r#"cargo:rustc-link-search={}/target/sdsl/sdsl_install/lib"#, "some thing");
$ cargo run --verbose
Compiling xx v0.1.0 (file:///private/tmp/xx)
[...snip...]
Running `rustc [...snip...] -L 'some thing/target/sdsl/sdsl_install/lib'`
This is really just out of curiosity.
A typo made me notice that in Bash, the following:
$ .anything
does not print any error ("anything" not to be interpreted literally, it can really be anything, and no space after the dot).
I am curious about how this is interpreted in bash.
Note that echo $? after such command returns 127. This usually means "command not found". It does make sense in this case, however I find it odd that no error message is printed.
Why would $ anything actually print bash:anything: command not found... (assuming that no anything cmd is in the PATH), while $ .anything slips through silently?
System: Fedora Core 22
Bash version: GNU bash, version 4.3.39(1)-release (x86_64-redhat-linux-gnu)
EDIT:
Some comments below indicated the problem as non-reproducible at first.
The answer of #hek2mgl below summarises the many contributions to this issue, which was eventually found (by #n.m.) as reproducible in FC22 and submitted as a bug report in https://bugzilla.redhat.com/show_bug.cgi?id=1292531
bash supports a handler for situations when a command can't be found. You can define the following function:
function command_not_found_handle() {
command=$1
# do something
}
Using that function it is possible to suppress the error message. Search for that function in your bash startup files.
Another way to find that out is to unset the function. Like this:
$ unset -f command_not_found_handle
$ .anything # Should display the error message
After some research, #n.m. found out that the described behaviour is by intention. FC22 implements command_not_found_handle and calls the program /etc/libexec/pk-command-not-found. This program is part of the PackageKit project and will try to suggest installable packages if you type a command name that can't be found.
In it's main() function the program explicitly checks if the command name starts with a dot and silently returns in that case. This behaviour was introduced in this commit:
https://github.com/hughsie/PackageKit/commit/0e85001b
as a response to this bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=1151185
IMHO this behaviour is questionable. At least other distros are not doing so. But now you know that the behaviour is 100% reproducible and you may follow up on that bug report.
I have a problem with ghci and I need an advice on how to debug it. The problem is that when I execute a function from my imported project I have a duplicate definition error and ghci exits because it can't continue:
> ghci -v0 --interactive -ignore-dot-ghci -isrc -idist/build/autogen tests/System/Console/Hawk/PreludeTests.hs -no-user-package-db -package-db /mnt/git/hawk/.cabal-sandbox/x86_64-linux-ghc-7.6.3-packages.conf.d
*System.Console.Hawk.PreludeTests> test [] "1" ""
GHCi runtime linker: fatal error: I found a duplicate definition for symbol
__stginit_stringsearchzm0zi3zi6zi5_DataziByteStringziSearch
whilst processing object file
/mnt/git/hawk/.cabal-sandbox/lib/x86_64-linux-ghc-7.6.3/stringsearch-0.3.6.5/libHSstringsearch-0.3.6.5.a
This could be caused by:
* Loading two different object files which export the same symbol
* Specifying the same object file twice on the GHCi command line
* An incorrect `package.conf' entry, causing some object to be
loaded twice.
GHCi cannot safely continue in this situation. Exiting now. Sorry.
The problem is that I can't find where this is happening. The symbol is unique in my cabal sandbox:
> for f in `find .cabal-sandbox -type f -iname "*.a"`; do nm $f | grep '__stginit_stringsearchzm0zi3zi6zi5_DataziByteStringziSearch$'; done
0000000000000000 D __stginit_stringsearchzm0zi3zi6zi5_DataziByteStringziSearch
so probably the stringsearch library is somehow loaded two times, but ghci is vague about it.
I would like to know if there is a way to debug this or, at least, to get more informations on the error before ghci kills itself. I already tried to change verbosity but I still get no informations.
Often this can occur when you are indirectly depending on two different versions of a library that both export the same symbol. This could occur, for example, if you also had a library from outside your sandbox (e.g. in the global package db) that depended on a stringsearch from there.
Additionally, to get more debug info, you should pass a flag indicating a higher verbosity.
I'm trying to compile a haskell file that has a HUGE number of errors in it. I want to start debugging the first one but unfortunately there are so many that they go off the screen.
I want to pipe the error messages to a file so that I can read from the top, but normal methods don't seem to work.
I've tried:
ghc File.hs > errors.log
ghc File.hs >> errors.log
ghc File.hs | more
None of them work. Using > and >> only writes the first couple of lines to the file and then the rest to standard output. Using more, less, cat etc doesn't make any difference at all.
Is there a flag for GHC that will let me output to a file?
(I should probably let you know that I'm working on a Windows machine with Cygwin.)
Most programs write output to the standard output (file descriptor 1) and error messages to the standard error (file descriptor 2).
You can ask your shell to redirect the standard error to another location like this:
ghc File.hs > output.log 2> errors.log
or if you want them in the same file:
ghc File.hs > output.log 2>&1
See your shell's manpage section of redirections for full details. Note that the shells are picky about the order of the redirections.
You can also view the output directly, using the same redirect as sarnold's solution, but without the intermediate output file:
ghc File.hs 2>&1 | less
(same goes for more instead of less, etc.)
I am use to using VC++ and like the feature when you compile the program it tells you how many warnings and errors there are so at a quick glance you can tell if you made a positive change.
I am now working in Linux so have to use g++ and am getting tired of having a massive stream of errors that I have to scroll through and guess at how many there are.
is there a way I can make g++ count the errors and warnings like VC++ does ?
{ g++ 2>&1 | tee /proc/self/fd/3 | grep Error | wc -l } 3>&1