I would like to include part of a C header or a C file into my sphinx doc.
using literalinclude gets the whole file but I would like to get only some part but based on functions, struct names etc...
I don't want to use lines or start-with options as I would like to make it fail when the C idiom is not found.
I don't see any option or extension to do that.
Related
I'm documenting a C library with Sphinx and RST; I'm hoping to reference some of C's built-in types within the documentation for several functions. For example, I want to reference C's double type.
I do have at the very top of the file some config to make sure the domain is C:
.. default-domain:: c
.. highlight:: c
Referencing :type:`double` or :c:type:`double` within the function definitions does the job of formatting just fine, but I get a warning when building: Unparseable C cross-reference: 'double'. I gather this is because I haven't explicitly defined the type of double like so:
.. c:type:: double
But defining the type means that it will be visible -- and displaying the built-in types of C on my documentation is suboptimal.
Is there a way to use the :type: syntax within my documentation to reference C built-in types without defining them explicitly (or, if I must define them, to hide the definitions)? Or, alternately, is there a way to silence the build warning? Or, as a third option, is it probably just best to use the :code: syntax, and if so, is there a way to make its styling identical to that of the :type: syntax?
At this time you can not declare the built-in C types (at least it is not supposed to work). However, you can style them using the :c:expr: and c:texpr: roles (https://www.sphinx-doc.org/en/master/usage/restructuredtext/domains.html#inline-expressions-and-types).
What's the pass name in GCC that handles building string array into .rodata section? Would like to write a plugin to intercept also strings in source code, I know there're a bunch of tools in binutils can achieve the same goal, but what if we want to do some postprocessing, for example verify words.
Read-only data section, also known as .rodata, generates after the last step of all rtl passes. You can see how it works in file varasm.c, which lays in /gcc folder. Look at section
section *
default_function_rodata_section (tree decl)
and below.
You can also easily add some functions to intercept data into asm file or some other output file here or write an external function.
varasm.c file handles the generation of all the assembler code
except the instructions of a function.
This includes declarations of variables and their initial values.
What is the most idiomatic way to get some form of context to the yacc parser in goyacc, i.e. emulate the %param command in traditional yacc?
I need to parse to my .Parse function some context (in this case including for instance where to build its parse tree).
The goyacc .Parse function is declared
func ($$rcvr *$$ParserImpl) Parse($$lex $$Lexer) int {
Things I've thought of:
$$ParserImpl cannot be changed by the .y file, so the obvious solution (to add fields to it) is right out, which is a pity.
As $$Lexer is an interface, I could stuff the parser context into the Lexer implementation, then force type convert $$lex to that implementation (assuming my parser always used the same lexer), but this seems pretty disgusting (for which read non-idiomatic). Moreover there is (seemingly) no way to put a user-generated line at the top of the Parse function like c := yylex.(*lexer).c, so in the many tens of places I want to refer to this variable, I have to use the rather ugly form yylex.(*lexer).c rather than just c.
Normally I'd use %param in normal yacc / C (well, bison anyway), but that doesn't exist in goyacc.
I'd like to avoid postprocessing my generated .go file with sed or perl for what are hopefully obvious reasons.
I want to be able to (go)yacc parse more than one file at once, so a global variable is not possible (and global variables are hardly idiomatic).
What's the most idiomatic solution here? I keep thinking I must be missing something simple.
My own solution is to modify goyacc (see this PR) which adds a %param directive allowing one or more fields to be added to the $$ParserImpl structure (accessible as $$rcvr in code). This seems the most idiomatic route. This permits not only passing context in, but the ability for the user to add additional func()s using $$ParserImpl as a receiver.
For instance, I saw the following line the other day:
#define ATS_STATIC_PREFIX "_Game_of_24_"
What is the meaning of such a line? What purpose does it serve?
Its literally one search on the google.
Here is the site.
Here is the quoted answer for your question:
When the DATS-file is
compiled into C, the prefix 'foo__' is attached to the original names
of static variables and functions in the generated C code.
This feature can be very useful if one wants to mix the C code
generated from multiple ATS source files as doing so is likely to
result in name conflicts among static variables and functions in the
C code. Such conflicts can be resolved by properly setting
ATS_STATIC_PREFIX. The same applies to loading PHP code generated from
ATS source.
In other words, how to get a similar effect to that of . (dot) in bash or execfile in python in make.
Use the include directive:
include the-other-makefile
Reasonable ways in which you could have discovered this without asking it:
read POSIX 7 http://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html "Include Lines" (not present in 6 it seems)
by reading this tutorial from beginning to end before asking anything
by looking at the table of contents of this tutorial and knowing beforehand that you are probably looking for a so called directive (include is a directive)
guess that instead of source as in bash, it could be called include as in c, and then search for the include keyword in the GNU make manual
read the entire table of contents for the and deduce that include does what you need