Labels

Milestone

Assignee

9 participants

I have made many modifications to the JSON info generation built into DMD so that it produces nicely formatted json as well as a lot more information than it use to. There are still several things that I would like added to it, such as more detail on selective imports and import renaming, but I'm not sure how to get that information.

Okay, so all the tests complete except for the one on Win32 because, for some reason, DMD adds some extra modifiers to the type of enum Y only on the Win32 platform. Json.c isn't doing anything different on different platforms, all it's doing is reporting information.

What should be done about it? Is this a separate DMD bug? I don't get why those storage class modifiers are platform specific.

That modifiers array is simply a list of all the StorageClass flags that are set, generated by this function which is called from here. It may not be correct to be dumping all of them, but I figured more information is better than not enough.

On the Win_32 platform, those 4 storage class flags are set for the enum Y; when they aren't set on any of the other platforms.

No, the issue hasn't been resolved yet, but I'm positive it isn't the fault of this pull request. This pull only increases the information being shown, no more, and there is no platform specific code. There are StorageClass flags set in the Win32 build that aren't set on the other platforms, and I don't know why or where to look.

I did not know that existed, thanks! The only problem I have is that the ideal Json format is an array of the storage classes, which is incompatible with what stcToCBuffer prints. Should I put a comment in both places (or maybe only in json.c) pointing to where it was copied from? Alternatively, the SCstring table could be moved to an externally visible location so they could at least share that table.

I agree. I thought in the beginning it would be easier to get the pull request accepted if it didn't change most of the *.h files. That reasoning doesn't really make sense to me anymore, now that I have little a better idea of what I'm doing. I'll make that change.

So the problem is that I want the storage classes to be stored as separate items in a Json array, not as a list of them separated by spaces, which is what stcToCBuffer does. The table array inside stcToCBuffer would need to be moved to a location that can be accessed from json.c. While trying to move it, I encountered a problem because the Id::* members are initialized by Id::initialize, which happens after the table is created. So I added a static StorageClassDeclaration::initialize member and called it after Id::initialize. Not terribly pretty, but I couldn't find a better way to do it.

I'm having a hard time finding a good way to recurse through all the inner declarations of a FuncDeclaration. The easiest way I can see is adding another visitor method to all Statement and Expression classes to get to the DeclarationExp class. It's going to have to wait unless someone has an idea.

I did make a lot of changes to this, that's for sure. How about I break it into one commit that is the massive upgrade I did to the formatting, and then commits after for each bug fixed? Would that be better?

Please don't let this die "just" because of how the commits are structured. The changes are desperately needed and from what the final diff looks like, there are a lot of uniform changes and it should be reviewable by taking one or two hours off (vs. possibly many hours needed to take apart and restructure everything).

Some practical solution to this would be good. My feeling is that the harm is possibly greater for not having it, even than having it with maybe some bugs.

I think this request needs to be broken up as well. Small obviously correct changes tend to be pulled far faster than huge sprawling changes. I think everyone is in general agreement that this set of changes is a good one, just need to find a way to give it a good review