I honestly can't even find anything like this anywhere on the internet, seems kind of like an obvious feature that is missing.
Basically, I'd like the compiler to check the names of every local variable and cause a build to fail if certain variable names are used. Just as an example, I'd like the build to fail if someone tries to use "x" as a variable for anything.
I get that determined folks would find a ways around it, but I'd like to see if it could be done.
I'm interested more in hearing if this can be done in Visual Studio since that's just what I use the most, but I'd be interesting in hearing about any kind of feature like this for any language / compiler if you know of one.
Related
SUMMARY:
I need the most efficient workflow to individually edit over 200 files, and have them automatically disappear from the search results as they are updated.
DETAILS:
I am in the process of adding logging throughout a legacy system, and need to update over 200 files, each with their own custom code. I need to edit them one by one, and would like for the updated files to automatically disappear from my working search results after I have completed each one. The idea is to know how many and which ones still need to be updated as I slowly work through them all.
I already had to do something similar a few months ago, but on a much smaller scale, and I used an old-school HACK to do it. I did a search and replace for my keyword, and intentionally misspelled it. I then used the misspelled keyword for my search, and corrected it when editing each file, hence automatically removing it from the list. It "works", but is obviously a TOTAL HACK.
I recently started using IntelliJ IDEA, and am not yet familiar with the more advanced features like Find in File Scopes, Search Structurally, Search Templates, etc., but I am sure there HAS to be a "correct" way to do this in IntelliJ, and I just don't know how.
I am currently using "Find in Files" to work through the list, and recently found "All Changed Files" in the Scope list, which is actually the EXACT OPPOSITE of what I need. Is there a way to show "All UNCHANGED Files"??? That would work PERFECTLY in a pinch! But really, I would rather learn the CORRECT way to do this in IntelliJ.
Thanks!
Intellij has a really neat feature, that lets me seamlessly extract a block of code into its own method. I can then give this method a nice, descriptive name and move on with life.
However, intellij also tries to find other blocks of code that are similar, and then tries to perusade me that I should also refactor them too, to use this new method its made. And then, when I hit the oddly-named "cancel" button (which implies the whole operation is cancelled, but it's not, it just stops asking about any remaining blocks), it leaves me looking at whatever the block of code it last asked me about.
I really don't like this feature. Here's why: If I'm say comparing two ints - the naming of the code block will depend on the context of those two ints, but intellij will find any comparison between two ints anywhere in that file, and then insist that this is also a candidate for extraction.
Most times it is not, and to make it worse, when I ask intellij to stop it, in a fit of pique, leaves me wherever the last comparison was, so now I have to navigate back to where I was working.
How do I tell intellij just to extract exactly what I selected, and do nothing else?
Please follow/vote/comment the issue created for this usability problem at YouTrack:
https://youtrack.jetbrains.com/issue/IDEA-233201
Is there a lint for Elixir (like for Javascript) which checks that every function has a type specification?
There is an Erlang compiler switch, +warn_missing_spec, which does this, but I'm having trouble getting it to work with Elixir at the moment, I think there is a bug with it's parsing of the ELIXIR_ERL_OPTS environment variable which is converting +warn_missing_spec into -warn_missing_spec which isn't a valid compiler option. I'm going to open an issue on the tracker, but thought you might like to know that this does indeed exist.
EDIT: As José mentioned below, the correct flag is ERL_COMPILER_OPTIONS. You can enable the missing spec warning during compilation by doing the following:
ERL_COMPILER_OPTIONS="warn_missing_spec" mix compile
Keep in mind you may get superfluous warnings from Elixir itself, for functions like __MODULE__. It should still be useful though. One last thing to note, I discovered this morning that there is a problem using this flag with mix compile, and that it's currently only warning about mix.exs. This is being fixed, and may even be fixed by the time you see this, but it's something to be aware of.
I searched the internet but did not find a concrete answer that why decompilers are unable to produce original source code. I dint get a satisfactory answer. Somewhere it was written that it is similar to halting problem but dint tell how. So what is the theoretical and technical limitation of creating a decompiler which is perfect.
It is, quite simply, a many-to-one problem. For example, in C:
b++;
and
b+=1;
and
b = b + 1;
may all get compiled to the same set of operations once the compiler and optimizer are done. It reorders things, drops in-effective operations, and rewrites entire sections of code. By the time it is done, it has no idea what you wrote, just a pretty good idea what you intended to happen, at a raw-CPU (or vCPU) level.
It is even smart enough to remove variables that aren't needed:
{
a=5;
b=func();
c=a+b;
d=func2(c);
}
## gets rewritten as:
REGISTERA=func()
REGISTERA+=5
return(func2(REGISTERA))
For starters, the variable names are never preserved when your program is compiled. ...so the best it could possibly do would be to use meaningless variable names throughout your re-constituted program. Compiling is generally a one-way transformation - like a one-way hashing function. Like the hash, it may be possible to generate something else that could hash to the same value, but it's highly unlikely the decompiled program will be the exact same as your original.
Compilers throw out information; not all the information that is in the source code is in the compiled code. For example in compiled Java, you can't tell the difference between a parameterized and unparameterized generic type because the information is only used by the compiler; some annotations are only used at compile time and are not included in the compiled output. That doesn't mean you couldn't get some sort of source code by decompiling; it just wouldn't match nor would be as informative as the actual source code.
There is usually not a 1-to-1 correspondence between source code and compiled code. If an essentially infinite number of possible sources could result in the same object code (given unbounded variable name lengths, etc.), how is a decompiler to guess which one to spit out?
I'm working in an embedded system (RTXC) where I need to disable the debugger functionality which is enabled through a #define command. However, when I change the #define to undefine, compilation goes off fine, but when the linker runs, it encounters an error about a symbol not existing that belongs to the debug code (which should have been taken care of by the debugger variable not being defined). Is there any way for Make to ensure that a preprocessor variable does not get defined or stays undefined ?
The answer to your question is no, Make can't absolutely prevent a variable from being defined by, say, a #define expression in the code.
You seem to have an elusive problem. It could be a bug in your Makefiles, a misspelled directive, a bad macro (if you'll pardon the tautology) or something trivial. I'd suggest burning the forest: cut out everything until the problem stops, then see where it was hiding. If you get down to HelloWorld and the problem persists, let us know.
No. You will need to fix the bug in your code.
More specifically, there is something that is referencing the debug side of things outside of an #ifdef. Make won't be able to help you there.
Another possibility is that you have a .o or something left over from a previous build; you might want to try cleaning the build tree.