Say I didn't like the syntax of objC blocks... (or: how to customize llvm a little bit) - objective-c

...is there anything I could do about it?
To be more precise, I would like to replace the caret "^" with something like "§" - granted, there's not much left on the keyboard that's not in use already.
After thinking about it for a while (dismissed using run script build phases along the way) I think the only way to do it would be a custom llvm build.
While I don't quite think I'm ready to deal with the internals of compilers, I have the naive hope that replacing one symbol with another isn't too hard. And the idea of building and running my own version of a compiler tickles me, be it just for a good deal of childish fun.
So I started poking around in the llvm sources, but - surprise - got nowhere so far.
If someone is familiar with these kind of things, could you please point me to a place to look at?
That would be awesome! Thanks!

Extending LLVM can be a bit of a hassle, especially considering how fast-moving the compiler team is, so it's a good thing you don't have to. The C preprocessor exists to perform the exact same thing you've outlined (text replacement). I'm fairly sure § isn't aliased to anything important, so #define § ^ should work great. If you still want to write your own module, LLVM provides instructions on how to extend their compiler.

Actually the code relevant for such a change isn't a part of LLVM at all, but a part of its Objective-C frontend, called Clang. Confusingly, "Clang" is also the name of the entire C/C++/ObjC compiler based on both Clang and LLVM.
While I don't quite think I'm ready to deal with the internals of compilers, I have the naive hope that replacing one symbol with another isn't too hard.
And you'll be right. What you're trying to do is very simple change.
In fact, if ^ was only used for blocks, it would be a trivial change - just modify the lexer to generate the "caret" token from § instead of ^: take a look at the lexer code to see what I mean (search for ^).
Unfortunately it's used for xor as well, so we'll have to modify both the lexer and the parser. The lexer to add a new token type and create that token from §, the parser to actually do something with it, e.g. by adding:
case tok::section: // 'section' is the token type you've added
Res = ParseBlockLiteralExpression();
break;
(and then fixing the assert at the beginning of ParseBlockLiteralExpression()).
You might run into some issues, though, as § isn't in ASCII - though as far as I know Clang should be able to deal with UTF-8 encoded files.

Related

Compiling Pascal code for embedded system (AT89C51RC2)

I am working on making a pretty trivial change to an old existing pascal source file. I have the source code, but need to generate a new hex file with my changes.
First, I tried compiling with "Embedded Pascal", which is the program used by my predecessor. Unfortunately, it is an unregistered copy and gives the message that the file is too large for the unregistered version. Support for and even the homepage for the project has disappeared (old), so I have no idea how I would register.
I tried a couple other compilers, "Free Pascal" and "Turbo51", and they are both giving similar errors:
Filename.pas (79): Error 36: BEGIN expected.
Linkcode $2E
^
The source code begins with
Linkcode $2E
LinkData $0A // normally 8 - make room for capacitance data
Program Main; Vector LongJmp Startup_Vector; //This inserts the start to the main routine.
uses IntLib;
I'm not well-versed in Pascal or embedded programming, but as I understand it, the Linkcode and LinkData lines are required to set up the RAM as needed. Following the "Const" and "var" declarations are subroutines that indeed start with procedure... begin... end.
I realize that Pascal is a bit out of date, but we are stuck with it and our old micro. Any ideas why previously working source code with trivial changes cannot be compiled? I am willing to consider other compilers, including paid options, if any are available with decent support. I am using Windows 10 x64 processor to compile, and flashing to an Atmel 89C51RC2.
If more source code is needed for diagnosis, please let me know what in particular, as I'll need to change some proprietary information before posting. Thanks!
Statements like linkcode and linkdata are not general, but target and compiler specific. Unless you have the know-how to reengineer to a different compiler, getting the original one is best.
Thanks to all for the information. While I didn't find an exact solution here, your comments were helpful for me to understand just how compiler-specific the Pascal code was.
In the end, I was able to get into my predecessors files and transfer registration, solving the issue for now. As suggested, I think I will port to C in the future to avoid fighting all the unsupported compiler nonsense.

Useless use of LOOP_BLOCK_1 symbol in sink context

With a snippet like
perl6 -e 'loop { FIRST say "foo"; last }'
I get
WARNINGS for -e:
Useless use of LOOP_BLOCK_1 symbol in sink context (line 1)
foo
I know how to work around the warning. I'm wondering about what the source of the warning is. I found this open ticket, but it doesn't seem to have received any attention.
What is this warning about?
And what about this is useless?
Version
$ perl6 --version
This is Rakudo version 2018.06 built on MoarVM version 2018.06
implementing Perl 6.c.
It's a bug, a bogus warning.
I know how to work around the warning.
That's the main thing.
I'm wondering about what the source of the warning is.
It's a bogus warning from the compiler.
I found this open ticket, but it doesn't seem to have received any attention.
I think it got some attention.
bbkr, who filed the bug, linked to another bug in which they showed their workaround. (It's not adding do but rather removing the FIRST phaser and putting the associated statement outside of the loop just before it.)
If you follow the other links in bbkr's original bug you'll arrive at another bug explaining that the general "unwanted" mechanism needs to be cleaned up. I imagine available round tuits are focused on bigger fish such as this overall mechanism.
Hopefully you can see that it's just a bizarre warning message and a minor nuisance in the bigger scheme of things. It appears to come up if you use the FIRST phaser in a loop construct. It's got the very obvious work around which you presumably know and bbkr showed.
What is this warning about?
Many languages allow you to mix procedural and functional paradigms. Procedural code is run for its side effects. Functional code for its result. Some constructs can do both.
But what if you use a construct that's normally used with the intent of its result being used, and the compiler knows that, but it also knows it's been used in a context in which its value will be ignored?
Perls call this "useless use of ... in sink context" and generally warn the coder about it. ("sink" is an alternative/traditional term for what is often called "void" context in other language cultures.)
This error message is one of these warnings, albeit a bogus one.
And what about this is useless?
Nothing.
The related compiler warning mechanism has gotten confused.
The "Useless use of ... in sink context" part of the message is generic and hopefully self-explanatory.
But there's no way it should be saying things like "LOOP_BLOCK_1 symbol". That's internal mumbo-jumbo.
It's a warning message bug.

can i make an equivalent to /* and */ for comment blocks?

Its driving me crazy, I spend soo much time getting it wrong, and then fixing it wrong.
I'm thinking of using -= and =- as delineators, but it probably means a lot of hours in learning how to fool the compiler into a substitution. Is this a quixotic quest? can such be done? has it been done already, albeit with different keystrokes?
I work alone. I don't collaborate.
So I don't mind a non-standard work environment
If I need to in the future i could make a scheme whereby both could work.
Not without building your own custom version of the preprocessor. Comment syntax is an inherent part of the language and is not designed to be configurable.
(Incidentally, -= is already a token in Objective-C — it means "assign to LHS the result of subtracting RHS from LHS.")
It should be possible to extend clang, then modify your Xcode builds to include your clang extensions. I have no personal experience with writing complier extension for clang, but I did work on a tool that extended cl.exe. Warning: this would be a very deep dive into the internals of the build system.
Extending Clang
Good Luck

How to create documentation for instance variable and methods in Xcode?

I'd like to be able to Alt-Click an instance variable (or a method) as part of the program i created and read what it's purpose is.
The fact that Xcode is telling me the class variable is declared at - is nice but not enough. In this case i'd like to see custom text i typed to describe what an asset really is. Additionally type of the ivar would also be useful to know.
How can this be done? In this case, i wonder what exactly did i mean by assets
I specifically wonder if this information can be viewed from inside Xcode, similar to how Eclipse shows JavaDoc content.
You would need to create a documentation set for your project and install it in Xcode. appledoc can help you with this. This is a command-line tool that can generate documentation in Apple's style from specially formatted comments in your headers. You can also integrate this into your build process with a run script build phase, so that documentation is always up-to-date.
For small projects, it's usually not worth the effort though and you're probably better off just adding comments to your header files and jumping there with Cmd-click (Ctrl+Cmd+left-arrow to go back to where you came from).
You'll probably want to take a look at Apple's documentation on Documentation Sets as well as their article on generating doc sets using Doxygen. The latter is based on Xcode 3.x, so how relevant it is is somewhat questionable, but it'd be a good idea to take a look nonetheless.
That said, if you decide to use Doxygen (alternatives like HeaderDoc can be used for documentation, but I'm not sure what's available to you as far as creating doc sets goes), it looks like the main point is you'll want to throw GENERATE_DOCSET=YES into your Doxyfile (or whatever you decide to call it). After that, you'd just throw the results into ~/Library/Developer/Shared/Documentation/DocSets (according to Doxygen's documentation). I don't know whether this works in Xcode 4.x - it's worth a shot though, and it'd be nice to hear back on it.
Note: most of this was based on this answer by Barry Wark. Figure credit is due there, since I wouldn't have bothered looking into this were it not for his answer.

How can i find out the symbol name the compiler generated for my code?

I know this is pretty much a stupid question. I know almost nothing about how compiler really works.
But recently I want find what symbol name does the compiler generate for my ivar, my methods.
Where and how can I know the answer? (I have only used some IDEs. So if the solution is better to be simple . And it would be great help if the instructions you provide is really explicit)
(By the way,is there any reference that i can learn about the things like this?)
PS.I'm IOS developer.And if gcc and LLVM works different answer on this question , I would like to know both.
You can use nm to dump the content of a binary object. Then, each compiler has its own way of mangling. I suggest you have a look at Name mangling for objective C in wikipedia, it will help you understand how mangling works.
Surely GCC and Clang must have compatible name-mangling schemes, since they can use each other's code.
If you are using XCode 3 select a source file and then pick "Show Assembly Code" from the Build menu.
Apparently XCode 4 users do not need assembly code :-(