fixes#4695
ref https://github.com/nim-lang/Nim/pull/15818
Since `nkState` is only for the main loop state labels and `nkGotoState`
is used only for dispatching the `:state` (since
https://github.com/nim-lang/Nim/pull/7770), it's feasible to rewrite the
loop body into a single case-based dispatcher, which enables support for
JS, VM backend. `nkState` Node is replaced by a label and Node pair and
`nkGotoState` is only used for intermediary processing. Backends only
need to implement `nkBreakState` and `closureIterSetupExc` to support
closure iterators.
pending https://github.com/nim-lang/Nim/pull/23484
<del> I also observed some performance boost for C backend in the
release mode (not in the danger mode though, I suppose the old
implementation is optimized into computed goto in the danger mode)
</del>
allPathsAsgnResult???
Nim manual says:
> When using the Cpp backend, params marked as byref will translate to
cpp references `&`
But how `byref` pragma translate to depends on whether it is used with
`importc` or `importcpp`.
When `byref` pragma used with `importc` types and compiled with the Cpp
backend, it is not traslated to cpp reference `&`.
---------
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
This is in reference to a [feature
request](https://github.com/nim-lang/Nim/issues/22142) that I posted.
I'm making this PR to demonstrate the suggested change and expect that
this should be scrutinized
---------
Co-authored-by: Bung <crc32@qq.com>
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
This PR modernises the NEP1 style guide to prefer hanging indent over
vertial alignment for long code statements while still allowing
alignment in legacy code.
The change is based on research and study of existing style guides for
both braced and indented languages that have seen wide adoption as well
as working with a large Nim codebase with several teams touching the
same code regularly.
The research was done as part of due diligence leading up to
[nph](https://github.com/arnetheduck/nph) which uses this style
throughout.
There are several reasons why hanging indent works well for
collaboration, good code practices and modern Nim features:
* as NEP1 itself points out, alignment causes unnecessary friction when
refactoring, adding/removing items to lists and otherwise improving code
style or due to the need for realignment - the new recommendation aligns
NEP1 with itself
* When collaborating, alignment leads to unnecessary git conflicts and
blame changes - with hanging indent, such conflicts are minimised.
* Vertical alignment pushes much of the code to the right where often
there is little space - when using modern features such as generics
where types may be composed of several (descriptively named) components,
there is simply no more room for parameters or comments
* The space to the left of the alignemnt cannot productively be used for
anything (unlike on the right, where comments may be placed)
* Double hanging indent maintaines visual separation between parameters
/ condition and the body that follows.
This may seem like a drastic change, but in reality, it is not:
* the most popular editor for Nim (vscode) already promotes this style
by default (if you press enter after `(`, it will jump to an indent on
the next line)
* although orthogonal to these changes, tools such as `nph` can be used
to reformat existing code should this be desired - when done in a single
commit, `git blame` is not lost and neither are exsting PRs (they can
simply be reformatted deterministically) - `nph` is also integrated with
vscode.
* It only affects long lines - ie most code remains unchanged
Examples of vertical alignment in the wild, for wildly successful
languages and formatters:
* [PEP-8](https://peps.python.org/pep-0008/#indentation)
*
[black](https://black.readthedocs.io/en/stable/the_black_code_style/current_style.html#how-black-wraps-lines)
* [prettier](https://prettier.io/docs/en/)
The above examples are useful mainly to show that hanging-indent
_generally_ is no impediment to efficient code reading and on the whole
is an uncontroversial choice as befits the standard library.
(Inspired by this pragma in nir asm PR)
`inlineAsmSyntax` pragma allowing specify target inline assembler syntax
in `asm` stmt.
It prevents compiling code with different of the target CC inline asm
syntax, i.e. it will not allow gcc inline asm code to be compiled with
vcc.
```nim
proc nothing() =
asm {.inlineAsmSyntax: "gcc".} """
nop
"""
```
The current C(C++) backend implementation cannot generate code for gcc
and for vcc at the same time. For example, `{.inlineAsmSyntax: "vcc".}`
with the ICC compiler will not generate code with intel asm syntax, even
though ICC can use both gcc-like asm and vcc-like. For implement support
for gcc and for vcc at the same time in ICC compiler, we need to
refactor extccomp
---------
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
refs #23091, especially post merge comments
Unsure if `experimental` and `bind` are the perfect constructs to use
but they seem to get the job done here. Symbol nodes do not get marked
`nfOpenSym` if the `bind` statement is used for their symbol, and
`nfOpenSym` nodes do not get replaced by new local symbols if the
experimental switch is not enabled in the local context (meaning it also
works with `push experimental`). However this incurs a warning as the
fact that the node is marked `nfOpenSym` means we did not `bind` it, so
we might want to do that or turn on the experimental switch if we didn't
intend to bind it.
The experimental switch name is arbitrary and could be changed.
---------
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
I came across this sentence in the Nim Manual and couldn't make sense of
it. I believe this is the correct fix for the sentence.
---------
Co-authored-by: ringabout <43030857+ringabout@users.noreply.github.com>
I couldn't find any documentation on the syntax for --hint:X:on|off with
`nimscript` except in [this old forum
post](https://forum.nim-lang.org/t/8526#55236).
The goal of this PR is to make `typeRel` accurate to it's definition for
generics:
```
# 3) When used with two type classes, it will check whether the types
# matching the first type class (aOrig) are a strict subset of the types matching
# the other (f). This allows us to compare the signatures of generic procs in
# order to give preferrence to the most specific one:
```
I don't want this PR to break any code, and I want to preserve all of
Nims current behaviors. I think that making this more accurate will help
serve as ground work for the future. It may not be possible to not break
anything but this is my attempt.
So that it is understood, this code was part of another PR (#22143) but
that problem statement only needed this change by extension. It's more
organized to split two problems into two PRs and this issue, being
non-breaking, should be a more immediate improvement.
---------
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
This implements Pandoc Markdown-style footnotes,
that are compatible with Pandoc referencing syntax:
Ref. [^ftn].
[^ftn]: Block.
See https://pandoc.org/MANUAL.html#footnotes for more examples.
* fix#22492
* Update nimdoc.css
remove scroll-y
* Update nimdoc.out.css
* Update nimdoc.css
* make it sticky again
* Update nimdoc.out.css
* danm sticky, use fixed
* Update nimdoc.out.css
* fix margin
* Update nimdoc.out.css
* make search input react to any change (not just keyboard events) according to https://github.com/nim-lang/Nim/pull/22511#issuecomment-1685218787
* #22514 Expand docs on testament spec options
The file, line and column options of testament are not in the docs,
but can be very important to know.
They allow you to specify where a compile-time error originated from.
Particularly given that testament assumes the origin to always be
the test-file, this is important to know.
* #22514 Specify nimout relevance a bit more
* #22514 Fix slightly erroneous doc-link
* #22514 Add example
* #22514 Add some docs on ccodecheck
* Infer generic bindings
* Simple test
* Add t
* Allow it to work for templates too
* Fix some builds by putting bindings in a template
* Fix builtins
* Slightly more exotic seq test
* Test value-based generics using array
* Pass expectedType into buildBindings
* Put buildBindings into a proc
* Manual entry
* Remove leftover `
* Improve language used in the manual
* Experimental flag and fix basic constructors
* Tiny commend cleanup
* Move to experimental manual
* Use 'kind' so tuples continue to fail like before
* Explicitly disallow tuples
* Table test and document tuples
* Test type reduction
* Disable inferGenericTypes check for CI tests
* Remove tuple info in manual
* Always reduce types. Testing CI
* Fixes
* Ignore tyGenericInst
* Prevent binding already bound generic params
* tyUncheckedArray
* Few more types
* Update manual and check for flag again
* Update tests/generics/treturn_inference.nim
* var candidate, remove flag check again for CI
* Enable check once more
---------
Co-authored-by: SirOlaf <>
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
