libexpr: split yacc prologue & epilogue (NFC)

[inclyc]

Motivation

This is an NFC PR that splits epilogue & prologue from parser.

As mentioned in #8812, we can add static checking tools & auto
formatting for these files, but if it is written .y directly, the clang
parser cannot understand the code is actually "C++".

Context

#8812
#6721

Priorities

Add 👍 to pull requests you find important.

[edolstra]

Note that we use .cc, not .cpp, as the extension for C++ files.

What does "NFC" mean in this context?

[inclyc]

NFC

NFC > > "No Functional Change"

[inclyc]

Note that we use .cc, not .cpp, as the extension for C++ files.

Thanks for pointing this out, however if use .cc suffix it will be matched by the Makefile rule *.cc and will be built as a standalone source file, which results to ODR violation, maybe I can move these file in directories.

[Ericson2314]

I am surprised this works with the *.cc wildcard in local.mk.

[Ericson2314]

I don't think we should be including .cc files. Can we give it a different extension? I don't really care what it is, hell .hh-noinstall would be fine with me.

[inclyc]

I don't think we should be including .cc files. Can we give it a different extension? I don't really care what it is, hell .hh-noinstall would be fine with me.

I would like to change the extension to .inc because it indicates this file will be #included, and it contains no header-gaurds (#pragma once)

[edolstra]

Suggested change

	#ifndef BISON_HEADER
	#define BISON_HEADER
	#pragma once

[edolstra]

We should really avoid custom extensions like .inc, because that breaks syntax highlighting etc. in most editors.

[inclyc]

Can we give it a different extension?

We should really avoid custom extensions like .inc, because that breaks syntax highlighting etc. in most editors.

Would you like to kindly suggest which extension should I use :) ?

[Ericson2314]

@edolstra Yeah the issue is that we don't want the wildcard rules to install this with the other headers with the wildcards that would pick them up.

Besides using a different extension, the only other thing I can think of would be a different directory, e.g. src/*.hh for private headers, and include/*.hh for public headers is pretty convention. But I recall you didn't want that public headers moved away from the source files they go with :).