search

alliedmodders / sourcepawn

A small, statically typed scripting language.
Other
362 stars 62 forks source link

Pragmas not affecting includes. #797

Closed JoinedSenses closed 2 years ago

JoinedSenses commented 2 years ago

Was told that #pragma semicolon was intentionally modified to not affect included files. #pragma newdecls also now has no effect on included files (so I'm told) and unsure if intentional. If this is intentional, could a compiler switch be added to revert to previous behavior on these? It was a useful behavior to have when updating plugins and maintaining consistency across files. (I'm not even sure why this behavior wouldve been changed)

Fyren commented 2 years ago

It is intentional that those pragmas don't affect anything but the file they're in, but you can just use them in each file. Acting like a global setting as before meant it was extremely annoying if they were used inside a file you included.

We can add a compiler option to default to requiring newdecls like how there is one for semicolons.

JoinedSenses commented 2 years ago

Hm. I think it's more annoying to change that behavior since it's mostly known the pragmas can be used after includes.

JoinedSenses commented 2 years ago

It would make more sense for the pragmas to be local only for .inc files (if for some reason someone puts them in there (which i have never seen)) and be global if it is contained within the main .sp file that is being compiled. Maybe this could be the default behavior on top of adding compiler switches? The new behavior is weird. By now, most have adopted new syntax except for folks still getting familiar with the language, and almost all use semicolons.

dvander commented 2 years ago

It doesn't make sense to work that way because third-party includes may not have newdecls. A command-line option to do a global override seems fine though, I'd take a PR for that.

JoinedSenses commented 2 years ago

It doesn't make sense to work that way because third-party includes may not have newdecls. A command-line option to do a global override seems fine though, I'd take a PR for that.

Not sure what you mean? It sounds like my suggestion was misinterpreted. I'm suggesting maintain most previous behavior by giving the plugin dev control over which includes should have the pragma enforced by placing the pragma before or after includes (within the .sp file that is being compiled), same as it was before, but if a .inc file has the pragmas written out, then don't override the global rules, but only locally for just that node (which sounds like the exact reason why this behavior was changed)

#include <somelibwitholdsyntax>
#pragma newdecls required
//... include everything else
JoinedSenses commented 2 years ago

I've even made a repo for this purpose of maintaining libs, updating their syntax to make it easier for people to grab new syntax versions of popular libs. https://github.com/JoinedSenses/SourceMod-IncludeLibrary

This behavior change makes it annoying to maintain stuff like this, because now I would have to go through every single file to add pragmas.

JoinedSenses commented 2 years ago

This behavior change makes it annoying to maintain stuff like this, because now I would have to go through every single file to add pragmas.

To add onto this, the new approach is a problem for backwards compatability because if i add the pragmas to every single file, that then fucks with global pragma rules for folks using older compilers, further contributing to the original problem...

I don't think it's a good solution to the problem, which is why my suggestion is to revert the behavior and then have pragmas within .inc files not affect the global pragma rules, instead only itself. Have the rules affect the node and the children included after the #pragmas, while not affecting its parent - propagating downwards, not upwards

dvander commented 2 years ago

That's not a backwards compatibility problem. Updating source to use newer compiler standards means older compilers won't work. This happens all the time.

The old transitive behavior is broken, it doesn't guarantee composition, and it's not coming back. We're moving past the token-paste nature of #includes and you should think of them as being encapsulated translation units.

The command-line override is fine though. I'm in favor of adding lint-style functionality.

JoinedSenses commented 2 years ago

Man, I still stand behind this being a terrible solution to the problem.