Closure Compiler documentation says "But even --warning_level=VERBOSE doesn't give you all the warnings that Closure Compiler can emit". I want them all, and for that matter, I would like --jscomp_error= to report an error for any warning.
I am not exactly sure from the documentation on https://github.com/google/closure-compiler/wiki/Warnings what I am supposed to do. Do I include multiple --jscomp's for every type listed, or is there a short-cut that ensures I have not missed anything?
You either:
Specify --jscomp_error flags for each type. The list is displayed when you run the compiler with the --help flag.
Make a custom build of the compiler.
Related
I am trying to build a Fortran program, but I get errors about an undefined reference or an unresolved external symbol. I've seen another question about these errors, but the answers there are mostly specific to C++.
What are common causes of these errors when writing in Fortran, and how do I fix/prevent them?
This is a canonical question for a whole class of errors when building Fortran programs. If you've been referred here or had your question closed as a duplicate of this one, you may need to read one or more of several answers. Start with this answer which acts as a table of contents for solutions provided.
A link-time error like these messages can be for many of the same reasons as for more general uses of the linker, rather than just having compiled a Fortran program. Some of these are covered in the linked question about C++ linking and in another answer here: failing to specify the library, or providing them in the wrong order.
However, there are common mistakes in writing a Fortran program that can lead to link errors.
Unsupported intrinsics
If a subroutine reference is intended to refer to an intrinsic subroutine then this can lead to a link-time error if that subroutine intrinsic isn't offered by the compiler: it is taken to be an external subroutine.
implicit none
call unsupported_intrinsic
end
With unsupported_intrinsic not provided by the compiler we may see a linking error message like
undefined reference to `unsupported_intrinsic_'
If we are using a non-standard, or not commonly implemented, intrinsic we can help our compiler report this in a couple of ways:
implicit none
intrinsic :: my_intrinsic
call my_intrinsic
end program
If my_intrinsic isn't a supported intrinsic, then the compiler will complain with a helpful message:
Error: ‘my_intrinsic’ declared INTRINSIC at (1) does not exist
We don't have this problem with intrinsic functions because we are using implicit none:
implicit none
print *, my_intrinsic()
end
Error: Function ‘my_intrinsic’ at (1) has no IMPLICIT type
With some compilers we can use the Fortran 2018 implicit statement to do the same for subroutines
implicit none (external)
call my_intrinsic
end
Error: Procedure ‘my_intrinsic’ called at (1) is not explicitly declared
Note that it may be necessary to specify a compiler option when compiling to request the compiler support non-standard intrinsics (such as gfortran's -fdec-math). Equally, if you are requesting conformance to a particular language revision but using an intrinsic introduced in a later revision it may be necessary to change the conformance request. For example, compiling
intrinsic move_alloc
end
with gfortran and -std=f95:
intrinsic move_alloc
1
Error: The intrinsic ‘move_alloc’ declared INTRINSIC at (1) is not available in the current standard settings but new in Fortran 2003. Use an appropriate ‘-std=*’ option or enable ‘-fall-intrinsics’ in order to use it.
External procedure instead of module procedure
Just as we can try to use a module procedure in a program, but forget to give the object defining it to the linker, we can accidentally tell the compiler to use an external procedure (with a different link symbol name) instead of the module procedure:
module mod
implicit none
contains
integer function sub()
sub = 1
end function
end module
use mod, only :
implicit none
integer :: sub
print *, sub()
end
Or we could forget to use the module at all. Equally, we often see this when mistakenly referring to external procedures instead of sibling module procedures.
Using implicit none (external) can help us when we forget to use a module but this won't capture the case here where we explicitly declare the function to be an external one. We have to be careful, but if we see a link error like
undefined reference to `sub_'
then we should think we've referred to an external procedure sub instead of a module procedure: there's the absence of any name mangling for "module namespaces". That's a strong hint where we should be looking.
Mis-specified binding label
If we are interoperating with C then we can specify the link names of symbols incorrectly quite easily. It's so easy when not using the standard interoperability facility that I won't bother pointing this out. If you see link errors relating to what should be C functions, check carefully.
If using the standard facility there are still ways to trip up. Case sensitivity is one way: link symbol names are case sensitive, but your Fortran compiler has to be told the case if it's not all lower:
interface
function F() bind(c)
use, intrinsic :: iso_c_binding, only : c_int
integer(c_int) :: f
end function f
end interface
print *, F()
end
tells the Fortran compiler to ask the linker about a symbol f, even though we've called it F here. If the symbol really is called F, we need to say that explicitly:
interface
function F() bind(c, name='F')
use, intrinsic :: iso_c_binding, only : c_int
integer(c_int) :: f
end function f
end interface
print *, F()
end
If you see link errors which differ by case, check your binding labels.
The same holds for data objects with binding labels, and also make sure that any data object with linkage association has matching name in any C definition and link object.
Equally, forgetting to specify C interoperability with bind(c) means the linker may look for a mangled name with a trailing underscore or two (depending on compiler and its options). If you're trying to link against a C function cfunc but the linker complains about cfunc_, check you've said bind(c).
Not providing a main program
A compiler will often assume, unless told otherwise, that it's compiling a main program in order to generate (with the linker) an executable. If we aren't compiling a main program that's not what we want. That is, if we're compiling a module or external subprogram, for later use:
module mod
implicit none
contains
integer function f()
f = 1
end function f
end module
subroutine s()
end subroutine s
we may get a message like
undefined reference to `main'
This means that we need to tell the compiler that we aren't providing a Fortran main program. This will often be with the -c flag, but there will be a different option if trying to build a library object. The compiler documentation will give the appropriate options in this case.
There are many possible ways you can see an error like this. You may see it when trying to build your program (link error) or when running it (load error). Unfortunately, there's rarely a simple way to see which cause of your error you have.
This answer provides a summary of and links to the other answers to help you navigate. You may need to read all answers to solve your problem.
The most common cause of getting a link error like this is that you haven't correctly specified external dependencies or do not put all parts of your code together correctly.
When trying to run your program you may have a missing or incompatible runtime library.
If building fails and you have specified external dependencies, you may have a programming error which means that the compiler is looking for the wrong thing.
Not linking the library (properly)
The most common reason for the undefined reference/unresolved external symbol error is the failure to link the library that provides the symbol (most often a function or subroutine).
For example, when a subroutine from the BLAS library, like DGEMM is used, the library that provides this subroutine must be used in the linking step.
In the most simple use cases, the linking is combined with compilation:
gfortran my_source.f90 -lblas
The -lblas tells the linker (here invoked by the compiler) to link the libblas library. It can be a dynamic library (.so, .dll) or a static library (.a, .lib).
In many cases, it will be necessary to provide the library object defining the subroutine after the object requesting it. So, the linking above may succeed where switching the command line options (gfortran -lblas my_source.f90) may fail.
Note that the name of the library can be different as there are multiple implementations of BLAS (MKL, OpenBLAS, GotoBLAS,...).
But it will always be shortened from lib... to l... as in liopenblas.so and -lopenblas.
If the library is in a location where the linker does not see it, you can use the -L flag to explicitly add the directory for the linker to consider, e.g.:
gfortran -L/usr/local/lib -lopenblas
You can also try to add the path into some environment variable the linker searches, such as LIBRARY_PATH, e.g.:
export LIBRARY_PATH=$LIBRARY_PATH:/usr/local/lib
When linking and compilation are separated, the library is linked in the linking step:
gfortran -c my_source.f90 -o my_source.o
gfortran my_source.o -lblas
Not providing the module object file when linking
We have a module in a separate file module.f90 and the main program program.f90.
If we do
gfortran -c module.f90
gfortran program.f90 -o program
we receive an undefined reference error for the procedures contained in the module.
If we want to keep separate compilation steps, we need to link the compiled module object file
gfortran -c module.f90
gfortran module.o program.f90 -o program
or, when separating the linking step completely
gfortran -c module.f90
gfortran -c program.f90
gfortran module.o program.o -o program
Problems with the compiler's own libraries
Most Fortran compilers need to link your code against their own libraries. This should happen automatically without you needing to intervene, but this can fail for a number of reasons.
If you are compiling with gfortran, this problem will manifest as undefined references to symbols in libgfortran, which are all named _gfortran_.... These error messages will look like
undefined reference to '_gfortran_...'
The solution to this problem depends on its cause:
The compiler library is not installed
The compiler library should have been installed automatically when you installed the compiler. If the compiler did not install correctly, this may not have happened.
This can be solved by correctly installing the library, by correctly installing the compiler. It may be worth uninstalling the incorrectly installed compiler to avoid conflicts.
N.B. proceed with caution when uninstalling a compiler: if you uninstall the system compiler it may uninstall other necessary programs, and may render other programs unusable.
The compiler cannot find the compiler library
If the compiler library is installed in a non-standard location, the compiler may be unable to find it. You can tell the compiler where the library is using LD_LIBRARY_PATH, e.g. as
export LD_LIBRARY_PATH="/path/to/library:$LD_LIBRARY_PATH"
If you can't find the compiler library yourself, you may need to install a new copy.
The compiler and the compiler library are incompatible
If you have multiple versions of the compiler installed, you probably also have multiple versions of the compiler library installed. These may not be compatible, and the compiler might find the wrong library version.
This can be solved by pointing the compiler to the correct library version, e.g. by using LD_LIBRARY_PATH as above.
The Fortran compiler is not used for linking
If you are linking invoking the linker directly, or indirectly through a C (or other) compiler, then you may need to tell this compiler/linker to include the Fortran compiler's runtime library. For example, if using GCC's C frontend:
gcc -o program fortran_object.o c_object.o -lgfortran
I tried this on Access 2016, but I'm pretty sure this has always been like that since the first versions.
Let's use a formula in a report field, in this case Mid("abc",2):
When I show the report, the result is correct:
Now, if for any reason i've got a syntax error in a VBA Module (I cannot exclude that other categories of problems lead to the same result), not related with the function I've used in my formula, the formula goes into an error state, displaying "#Name?" error message.
And this is the result:
Well this is quite scary because it means that a report that is already validated and used can always show an error and omit information because an error is present in an non-related module.
Potentially ALL the report formula could get broken because a bug in a module; in complex reports with a lot of fields, this can go unnoticed till a customer realizes that instead of a crucial information "#Name?" is written.
I would like to prevent this scenario. Is it possible to raise an exception in the case of a broken formula, instead of just showing #Name?
Are there any other possibilities to achieve this level of reliability?
No, there is not, at least not really.
There is really only one way to avoid this: make sure your code compiles. If your code can't compile, then none of the functions can be trusted. Since VBA allows overriding functions, that's a good thing, since you might've declared a function named Mid somewhere in that section that doesn't compile and might expect the code to use that. Not compiling equals "not a clue what's going on, nothing can be trusted".
For simple projects, the fix is to mash that compile button (Debug -> Compile) after every single change and to never accept a failure to compile.
For more complex projects, you can organize code in different files and reference them (see this answer), and if one file fails to compile, that'll only affect code that references anything from that file (make sure to rename the VB project of each file to avoid name conflicts). For some projects, it's sensible to use this to keep data, forms and reports, and modules all in separate files.
I would like to identify all functions needed to run a specific function in octave. I need this to deploy an application written in Octave.
While Matlab offers some tools to analyse a function on its dependencies, I could not find something similar for Octave.
Trying inmem as recommended in matlab does not produce the expected result:
> inmem
warning: the 'inmem' function is not yet implemented in Octave
Is there any other solution to this problem available?
First, let me point out that from your description, the matlab tool you're after is not inmem, but deprpt.
Secondly, while octave does not have a built-in tool for this, there is a number of ways to do so yourself. I have not tried these personally, so, ymmv.
1) Run your function while using the profiler, then inspect the functions used during the running process. As suggested in the octave archives: https://lists.gnu.org/archive/html/help-octave/2015-10/msg00135.html
2) There are some external tools on github that attempt just this, e.g. :
https://git.osuv.de/m/about
https://github.com/KaeroDot/mDepGen
3) If I had to attack this myself, I would approach the problem as follows:
Parse and tokenise the m-file in question. (possibly also use binary checks like isvarname to further filter useless tokens before moving to the next step.)
For each token x, wrap a "help(x)" call to a try / catch block
Inspect the error, this will be one of:
"Invalid input" (i.e. token was not a function)
"Not found" (i.e. not a valid identifier etc)
"Not documented" (function exists but has no help string)
No error, in which case you stumbled upon a valid function call within the file
To further check if these are builtin functions or part of a loaded package, you could further parse the first line of the "help" output, which typically tells you where this function came from.
If the context for this is that you're trying to check if a matlab script will work on octave, one complication will be that typically packages that will be required on octave are not present in matlab code. Then again, if this is your goal, you should probably be using deprpt from matlab directly instead.
Good luck.
PS. I might add that the above is for creating a general tool etc. In terms of identifying dependencies in your own code, good software engineering practices go a long way towards providing maintenable code and easily resolving dependency problems for your users. E.g: -- clearly identifying required packages (which, unlike matlab, octave does anyway by requiring such packages to be visibly loaded in code) -- similarly, for custom dependencies, consider wrapping and providing these as packages / namespaces, rather than scattered files -- if packaging dependencies isn't possible, you can create tests / checks in your file that throw errors if necessary files are missing, or at least mention such dependencies in comments in the file itself, etc.
According to Octave Compatibility FAQ here,
Q. inmem
A. who -functions
You can use who -function. (Note: I have not tried yet.)
I would like to force my cmake based configuration to fail ( and possibly print a message ) if:
there are unused variables ( which are likely to be a typo in most cases )
there are unused modules ( same thing as before or useless stuff )
a particular if is not being evaluated to TRUE
I find that the fact that cmake is macro based solution makes it hard to spot errors on big projects, so if someone has some some hints on that. Basically cmake doesn't alert you because anything could be a custom variable and not necessarily a typo or a mistake.
Let's address your points out-of-order.
a particular if is not being evaluated to TRUE
The way to achieve this is a FATAL_ERROR message:
if(SOME_CONDITION)
message(FATAL_ERROR "You did something wrong!")
endif()
there are unused variables
This is more difficult. There are the --warn-unused-vars and --warn-uninitialized command line options, but this has to be given by the user when running CMake. It is not possible to enforce this behavior from within a CMake script.
Also, there is no way to turn these warnings into fatal errors: CMake will still try to produce a valid Makefile (and may succeed in doing so). The only viable solution here seems to be developer discipline: Whenever a developer makes changes to the build environment, they should be aware of this compile options and check their code accordingly. Just as you would do with your other source code.
If you have trouble enforcing this, try to provide a shell-script as a wrapper that already sets all of the desired command line options. While not perfect, this will at least remove the obstruction of having to look up that damn parameter in the manual for your developers.
there are unused modules
This is not possible, but I also don't see a big problem here. Worst thing that can happen is that pulling in the module adds some noise to the cached variables, but none of that would have any influence on the final generated build files.
CMake modules should always be kept small enough so that pulling them in should have no noticeable impact on the runtime of your CMake configure run.
For example, I want to catch a couldn't-read-a-file-at-that-path exception from imread(). I can do this.
imagePath = 'a_picture.jpg';
try
im = imread(imagePath);
catch exception
if strcmp(exception.identifier, 'MATLAB:imread:fileOpen')
fprintf('Couldn''t open %s.\n', imagePath);
im = [];
else
fprintf('Unexpected error (%s): %s\n', ...
exception.identifier, exception.message);
throw(exception);
end
end
But the only ways I know to discover the magic string to compare with ('MATLAB:imread:fileOpen' in this case), are:
Cause the error, catch the exception, and look at the identifier. But it would take a long time to do this right. For example, does Matlab use a different exception identifier if the file exists but is not actually an image file? How about if it exists but I don't have read permission? What if it's a directory?
Look at the source code. imread() is written in Matlab, so this is possible, but it wouldn't be for other functions. And of course imread() calls other functions that are not written in Matlab, and exceptions could bubble up from them.
Is there any authoritative way for me to know all the exceptions imread() can throw? I'm hoping this is in the documentation somewhere, but I can't find it.
No, there is not.
The problem is that even if there would be an authoritative reference on what a given function in MatLab throws, it could change from version to version. So even if you could do it, you probably should not.
I would recommend only checking for the ones that you know you can handle, and generate some generic errors for others (or reuse what MatLab gives you).
Some comments based on other languages/frameworks:
In .NET, the only list of exceptions that can be thrown from a method, is in documentation, and is not liked to the source code. These are often out of date, invalid, and incomplete.
In Java, you can specify what exception is thrown form what method. This is then verified by the compiler, and therefore an authoritative reference can be built by the compiler. MatLab lacks such a feature, therefore the best you can do is searching as outlined in other answers.
I search for that, and I did not find anything... The only thing I see it could help you, would be analyse the source code of imread, which I don't think it's possible. However, you could always try to see the source code of the same function in Octave, since it almost the same (I suppose).
If you're willing to enumerate files to generate your own reference, try
grep -r "MATLAB:" <matlab root>
you'll get a long list...but it appears errors are either thrown by error() or mexErrMsgIdAndTxt. Those plus function names let you be more specific. Pretty slow though.
grep will also note that some binary files match. Feed it -a and it will be able to pull out the error messages from many of them.