Add a Spec Scanner

[ThadHouse]

There was a generator to generate our HAL functions, but the more I think about it the worse of an idea that is. Instead, we should add a spec scanner, so make sure that we have a wrapper around every function in the HAL.

For the C# side, this is fairly easy. We can just use Roslyn to get a list of all our methods. The C side is going to be a little trickier. If there is a prebuilt GCC C parser for C#, we can use that. But we might have to build our own.

[jkoritzinsky]

Instead of GCC, we should use one of the Clang libraries. I know one of them has a C# wrapper to it. That way we can utilize Roslyn and only have one code base.

[ThadHouse]

We don't need to be able to actually compile the program. We only need to parse the header files. And I mentioned GCC since that is what they use to actually compile the HAL, so we would need to be able to parse a header file made for GCC.

[jkoritzinsky]

Clang will be able to parse almost all GCC headers. Additionally, GCC is not built to be used as a library; Clang was built with library use in mind.

[ThadHouse]

Finally got around to testing, and clang I do not believe will work. It does not like the uintX_t variables, and just seems to think they are all Int. And since we want to be able to check the type, it will not work properly.

[jkoritzinsky]

Put the code up somewhere and I'll take a look. If clang couldn't understand uintX_t types than it wouldn't be useful for anything, so I have a hard time believing that this is a problem in clang.

[ThadHouse]

I just commited it. Its in https://github.com/robotdotnet/robotdotnet-wpilib/blob/master/WPILib.Tests/SpecScaners/NativeProjects.cs

Even if I just print the raw type directly to a string it always outputs int for uintX_t types.

[ThadHouse]

Most of the code is modified from their PInvoke generator, which also thinks everything is int when directly giving that executable header files.

[ThadHouse]

We have a slighly better spec scanner now, so I'm going to close this.