I was going through the Clang documentation and I just found some of the flags seemed to be "undocumented." For example:
-fallow-unsupported
-fassume-sane-operator-new
-fast
-fastcp
-fastf
-fautolink
-fbuiltin
...
Where can I find their docs/explanations online? Or are their docs hidden (by design)?
After clang --help-hidden, your best bet could be to skim through git history.
Checkout https://github.com/llvm/llvm-project/ , use a git tool that lets your search the diffs and search for your flag.
By looking at the commit message, surrounding code, and the review process (which goes on at https://reviews.llvm.org ), you can get a good idea of how the flag works.
http://clang.llvm.org/doxygen/ might be of interest too.
Related
Where can I see the actual key-value pairs set in Google style? I can't find the definition in the clang repository.
They can be found in the Format.cpp file of the clang lib.
https://github.com/llvm/llvm-project/blob/04ee232ff212b6c308e2ebc7b6125892681c54ae/clang/lib/Format/Format.cpp#L660
This is the start of the LLVM style, then the following functions after it hold the other pre-defined configuration settings. If you are looking at a different version of the code base, look for the function 'getPredefinedStyle' to find the sub-calls that are used based on the style chosen.
My gitignore file says nothing about podfiles. In fact, I can make it empty, and still get the same result - my 'Podfile' is being ignored. If i change it's name to something different, it sees it, but otherwise just ignores it. I'm not sure why.
There's a nifty little utility called check-ignore* that serves exactly this purpose. Example use:
git check-ignore -vn path/to/Podfile
It'll output the file, line number and pattern that makes git exclude the file.
* fun trivia: check-ignore was born right here at Stack Overflow. So go forth and thank Adam Spiers! (-:
Let's say I want to detect something in my code which I cannot check by tests.
e.g.:
- Go over my entire code base to detect there I have a space between brackets and curly brackets (using a regex).
- Go over my entire code base and detect style smells.
etc...
If one of these checks fails, I'd like to show a custom warning I define myself.
Is there anything like this in XCode?
Thanks.
I wrote a run script for Xcode that does exactly what you requested. It searches by regex for predefined "code smells" or "style smells" and warns you at compile time
Read the blog post, but the final script is here
#test if git exists.
command -v git > /dev/null 2>$1 || {exit 0}
#separate code smells with | i.e. (code_smell_1|code_smell_2)
KEYWORDS="(didDeselectRowAtIndexPath)"
git diff --name-only HEAD | grep "\.m" | xargs egrep -s --with-filename --line-number --only-matching "$KEYWORDS.*[^\/]*$" | perl -p -e "s/($KEYWORDS)/ warning: Are you sure you want to use \$1?\nTo remove this warning, append a comment at the end of this line \$1/"
This particular script searches for appearances of didDeselectRowAtIndexPath in the code, but you can change that to any string
You would need to create a project target that runs a script, which searches through your source files and does your checks (this is not trivial) and returns non-zero to indicate error.
Then make your app target dependent on this "check target" and the build will fail if the check fails.
If you want some indication of how you write this "check script" then I would be inclined to employ the clang static analyzer. However, unfortunately, scan-build is not installed as part of the Xcode Command Line tools, so you would need to use the LLVM-binaries in some way, or perhaps the macports version contains it.
For trivial checks, relating to spaces and other stylistic issues rather than real, live, code problems, then you will have to employ some other mechanism, and I have no idea how to start with that, sorry.
I just caught myself doing something I do a lot, and wanted to generalize it, express it, share it and see who else is following this general practice, to find some other example situations where it might be relevant.
The general practice is getting something wrong first, on purpose, to establish that everything else is right before undertaking the current task.
What I was trying to do, specifically, was to find examples in our code base where the dojo TextArea widget was used. I knew (because I had it in front of me - existence proof) that the TextBox widget was present in at least one file. So I looked first for what I knew was there:
grep -r digit.form.TextBox | grep -v
svn
This wasn't right - I had made a common (for me) mistake of leaving off the star, so I fixed that:
grep -r digit.form.TextBox * | grep
-v svn
which found no results! Quick comparison with the file I was looking at showed me I had misspelled "dijit":
grep -r dijit.form.TextBox * | grep
-v svn
And now I got results. Cool; doing it wrong first on purpose meant my query was correct except for looking for the wrong thing, so now I could construct the right query:
grep -r dijit.form.TextArea * | grep
-v svn
and be confident that when it gave me no results, it was because there are no such files, and not because I had malformed the query.
I'll add three other examples as answers; please add any others you're aware of.
TDD
The red-green-refactor cycle of test-driven development may be the archetype of this practice. With red, demonstrate that the functionality doesn't exist; then make it exist and demonstrate that you've done so by witnessing the green bar.
http://support.microsoft.com/kb/275085
This VBA routine turns off the "subdatasheets" property for every table in your MS Access database. The user is instructed to make sure error-handling is set to "Break only on unhandled errors." The routine identifies tables needing the fix by the error that is thrown. I'm not sure this precisely fits your question, but it's always interesting to me that the error is being used in a non-error way.
Here's an example from VBA:
I also use camel case when I Dim my variables. ThisIsAnExampleOfCamelCase. As soon as I exit the VBA code line if Access doesn't change the lower case variable to camel case then I know I've got a typo. [OR, Option Explicit isn't set, which is the post topic.]
I also use this trick, several times an hour at least.
arrange - assert - act - assert
I sometimes like, in my tests, to add a counter-assertion before the action to show that the action is actually responsible for producing the desired outcome demonstrated by the concluding assertion.
When in doubt of my spelling, and of my editor's spell-checking
We use many editors. Many of them highlight misspelled words as I type them - some do not. I rely on automatic spell checking, but I can't always remember whether the editor of the moment has that feature. So I'll enter, say, "circuitx" and hit space. If it highlights, I'll back up over the space and the "x" and type another space - and learn that I spelled circuit correctly - but if it doesn't, I'll copy the word and paste it into a known spell-checker to see whether I did.
I'm not sure it's the best way to act, as it does not prevent you from mispelling the final command, for example typing "TestArea" or something like that instead of "TextArea" (your finger just have to slip a little for such a mistake).
IMHO the best way is to run your "final" command, but on two sample files first : one containing the requested text, another that doesn't.
In other words, instead of running a "similar" command, run the real one, but over "similar" data.
(Not sure if this would be a good idea to try for real!)
For example, you might give the system to the users for testing and tell them the password to get started is "Apple".
You know the users are fully up and ready to test (everything is installed and connections to databases working) when they contact you and say the password doesn't work (it's actually "Orange").
As suggested here, latexmk is a handy way to continually compile your document whenever the source changes. But often when you're working on a document you'll end up with errors and then latex will panic and wait for user input before continuing. That can get very annoying, especially recently when I hacked up something to compile latex directly from an etherpad document, which saves continuously as you type.
Is there a setting for latex or latexmk to make it just abort with an error message if it can't compile? Or, if necessary, how would I set up some kind of Expect script to auto-dismiss LaTeX's complaints?
(I had thought pdflatex's option -halt-on-error would do the trick but apparently not.)
Bonus question: Skim on Mac OSX is a nice pdf viewer that autorefreshes when the pdf changes (unlike Preview), except that whenever there's a latex error it makes you reconfirm that you want autorefreshing. Texniscope doesn't have this problem, but I had to ditch Texniscope for other reasons. Is there a way to make Skim always autorefresh, or is there another viewer that gets this right?
ADDED: Mini-tutorial on latexmk based on the answer to this question:
Get latexmk here: http://www.phys.psu.edu/~collins/software/latexmk-jcc/
Add the following to your ~/.latexmkrc file:
$pdflatex = 'pdflatex -interaction=nonstopmode';
(For OS X with Skim)
$pdf_previewer = "open -a /Applications/Skim.app";
While editing your source file, foo.tex, run the following in a terminal:
latexmk -pvc -pdf foo.tex
Use Skim or another realtime pdf viewer to view foo.pdf. For Skim, just look at the “Sync” tab in Skim’s preferences and set it up for your editor.
Voila! Hitting save on foo.tex will now cause foo.pdf to refresh without touching a thing.
With MikTeX, pdflatex has this command-line option:
-interaction=MODE Set the interaction mode; MODE must be one
of: batchmode, nonstopmode, scrollmode,
errorstopmode.
Edit suggested by #9999years:
Those values are equivalent to a set of LaTeX \commands that provide the same functionality.
From TeX usage tips:
The modes make TeX behave in the following way:
errorstopmode stops on all errors, whether they are about errors in the
source code or non-existent files.
scrollmode doesn't stop on errors in the source but requests input when a
more serious error like like a missing file occurs.
In the somewhat misnamed nonstopmode, TeX does not request input after
serious errors but stops altogether.
batchmode prevents all output in addition to that (intended for use in
automated scripts). In all cases, all errors are written to the log file
(yourtexfile.log).
You can also put \nonstopmode or \batchmode at the very beginning of your tex file; then it'll work with any TeX version, not just pdflatex. For more info on these and related commands see the very good reference on (raw) TeX commands by David Bausum. Especially the command from the debugging family could be of interest here.
Another possible hack is simply to use:
yes x | latexmk source.tex
You could always create an alias for 'yes x | latexmk' if you're going to use this option lots. The main advantage of this that I can see above the other suggestions is that it is very quick for when you occasionally want latexmk to behave like this.
Mehmet
There is also a \batchmode command may do the work.