pragmas: type pragmas must follow generic params #400
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
saem
force-pushed
the
saem-qw-06-pragmas-type-pragmas-must-follow-generic-params
branch
from
fc033cc to
cc88755
Compare
removed the previous deprecation where pragmas could preceed the generic
parameter list in a type definition, eg:
```
type Foo{.somePragma}[T] = ... # now an error
type Foo[T] {.somePragma.} = ... # acceptable
```
Due to lots of issues, mostly stylistic, I've pragmas on the RHS of a
type definition as legal. Largely because after changing it I realized a
more significant rethink of type declaration syntax should cover this in
the future.
Fixed a number of test failures along the way due to this change.
saem
force-pushed
the
saem-qw-06-pragmas-type-pragmas-must-follow-generic-params
branch
from
cc88755 to
edc3656
Compare
|
bors r+ |
bors bot
added a commit
that referenced
this pull request
Aug 6, 2022
400: pragmas: type pragmas must follow generic params r=saem a=saem
## Summary
removed the previous deprecation where pragmas could preceed the generic
parameter list in a type definition, eg:
```
type Foo{.somePragma}[T] = ... # now an error
type Foo[T] {.somePragma.} = ... # acceptable
```
## Details
Due to lots of issues, mostly stylistic, I've pragmas on the RHS of a
type definition as legal. Largely because after changing it I realized a
more significant rethink of type declaration syntax should cover this in
the future.
Fixed a number of test failures along the way due to this change.
Co-authored-by: Saem Ghani <saemghani+github@gmail.com>
|
Build failed: |
|
bors r+ |
bors bot
added a commit
that referenced
this pull request
Aug 7, 2022
400: pragmas: type pragmas must follow generic params r=saem a=saem
## Summary
removed the previous deprecation where pragmas could preceed the generic
parameter list in a type definition, eg:
```
type Foo{.somePragma}[T] = ... # now an error
type Foo[T] {.somePragma.} = ... # acceptable
```
## Details
Due to lots of issues, mostly stylistic, I've pragmas on the RHS of a
type definition as legal. Largely because after changing it I realized a
more significant rethink of type declaration syntax should cover this in
the future.
Fixed a number of test failures along the way due to this change.
Co-authored-by: Saem Ghani <saemghani+github@gmail.com>
|
Timed out. |
|
bors r+ |
bors bot
added a commit
that referenced
this pull request
Aug 7, 2022
400: pragmas: type pragmas must follow generic params r=saem a=saem
## Summary
removed the previous deprecation where pragmas could preceed the generic
parameter list in a type definition, eg:
```
type Foo{.somePragma}[T] = ... # now an error
type Foo[T] {.somePragma.} = ... # acceptable
```
## Details
Due to lots of issues, mostly stylistic, I've pragmas on the RHS of a
type definition as legal. Largely because after changing it I realized a
more significant rethink of type declaration syntax should cover this in
the future.
Fixed a number of test failures along the way due to this change.
Co-authored-by: Saem Ghani <saemghani+github@gmail.com>
|
Build failed: |
|
bors r+ |
|
@alaviss do you know what's up with this, all tests/checks seem good and bors continually is gets stuck. Reopening the PR, syncing, etc, aren't helping. :( |
|
Build succeeded: |
|
Sure, now it works. |
It could be that the bors server is overloaded. That does happen from time to time. Once Github Merge Queue become available I will look into it as a bors substitute. |
saem
deleted the
saem-qw-06-pragmas-type-pragmas-must-follow-generic-params
branch
haxscramper
added
the
simplification
github-merge-queue bot
pushed a commit
that referenced
this pull request
Oct 19, 2023
## Summary * Fix grammar nanny not compiling anymore * Fix the grammar generator generating `doc/grammar.txt` in `compiler/ast/parser.nim` * Rerunning the grammar generator fixed the grammar update from #400 / edc3656 not being reflected in `grammar.txt` and thus the manual ## Details * `tools/grammar_nanny` was just missing an import for the internal reports after those had been split out * The grammar generator expected the parser to be at `compiler/parser.nim`
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Summary
removed the previous deprecation where pragmas could preceed the generic
parameter list in a type definition, eg:
Details
Due to lots of issues, mostly stylistic, I've pragmas on the RHS of a
type definition as legal. Largely because after changing it I realized a
more significant rethink of type declaration syntax should cover this in
the future.
Fixed a number of test failures along the way due to this change.