Add restrictions on modifiers in local scope #40
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Declarations for functions, classes, and variables are legal at various
different scopes (global, type-level, and local), but have different
sets of legal modifiers in each. While you might think that would be
fine and would simply improve our permissiveness, it actually ends up
restricting some valid code - in particular, code that uses those
would-be modifiers as identifiers. For instance, one file in Carthage
uses the innocent-looking variable name
prefix
, but we fail to parsethat because in other scopes, that would instead be a modifier.
To fix this, we split out declarations by scope: global, type-level, and
local. For now, we treat global and type-level as mostly the same except
that subscripts are legal in the latter and not the former. However, for
local declarations, we allow a much smaller list of operators.
Fixes #39