Nim/doc, branch devel

sort modules and added std/setutils (#24168)

2024-09-26T04:29:25Z

make `genericsOpenSym` work at instantiation time, new behavior in `openSym` (#24111)

2024-09-18T17:27:09Z

alternative to #24101 #23892 changed the opensym experimental switch so that it has to be enabled in the context of the generic/template declarations capturing the symbols, not the context of the instantiation of the generics/templates. This was to be in line with where the compiler gives the warnings and changes behavior in a potentially breaking way. However `results` [depends on the old behavior](https://github.com/arnetheduck/nim-results/blob/71d404b314479a6205bfd050f4fe5fe49cdafc69/results.nim#L1428), so that the callers of the macros provided by results always take advantage of the opensym behavior. To accomodate this, we change the behavior of the old experimental option that `results` uses, `genericsOpenSym`, so that ignores the information of whether or not symbols are intentionally opened and always gives the opensym behavior as long as it's enabled at instantiation time. This should keep `results` working as is. However this differs from the normal opensym switch in that it doesn't generate `nnkOpenSym`. Before it was just a generics-only version of `openSym` along with `templateOpenSym` which was only for templates. So `templateOpenSym` is removed along with this change, but no one appears to have used it.

Adds an example of using ident to name procedures to the macros tutorial (#22973)

2024-09-09T09:46:48Z

As discussed here: https://forum.nim-lang.org/t/10653 --------- Co-authored-by: ringabout <43030857+ringabout@users.noreply.github.com>

open new scope for const values (#24084)

2024-09-09T09:29:30Z

fixes #5395 Previously values of `const` statements used the same scope as the `const` statement itself, meaning variables could be declared inside them and referred to in other statements in the same block. Now each `const` value opens its own scope, so any variable declared in the value of a constant can only be accessed for that constant. We could change this to open a new scope for the `const` *section* rather than each constant, so the variables can be used in other constants, but I'm not sure if this is sound.

Fix CSS for `number-lines` code blocks (#24081)

2024-09-09T07:42:45Z

Adds a few fixes for when using code blocks with lines numbered - Use CSS variables for the colours so that it works in dark mode - Don't turn on normal table effects like hover and smaller font when its a line number table - With dochack.nim, don't add a clipboard copy button for the line numbers at the side [Example page showing the changes](https://66dcde6e4a655efb70771d9a--dazzling-kitten-6c3419.netlify.app/)

handle explicit generic routine instantiations in sigmatch (#24010)

2024-09-02T16:22:20Z

fixes #16376 The way the compiler handled generic proc instantiations in calls (like `foo[int](...)`) up to this point was to instantiate `foo[int]`, create a symbol for the instantiated proc (or a symchoice for multiple procs excluding ones with mismatching generic param counts), then perform overload resolution on this symbol/symchoice. The exception to this was when the called symbol was already a symchoice node, in which case it wasn't instantiated and overloading was called directly ([these lines](https://github.com/nim-lang/Nim/blob/b7b1313d21deb687adab2b4a162e716ba561a26b/compiler/semexprs.nim#L3366-L3371)). This has several problems: * Templates and macros can't create instantiated symbols, so they couldn't participate in overloaded explicit generic instantiations, causing the issue #16376. * Every single proc that can be instantiated with the given generic params is fully instantiated including the body. #9997 is about this but isn't fixed here since the instantiation isn't in a call. The way overload resolution handles explicit instantiations by itself is also buggy: * It doesn't check constraints. * It allows only partially providing the generic parameters, which makes sense for implicit generics, but can cause ambiguity in overloading. Here is how this PR deals with these problems: * Overload resolution now always handles explicit generic instantiations in calls, in `initCandidate`, as long as the symbol resolves to a routine symbol. * Overload resolution now checks the generic params for constraints and correct parameter count (ignoring implicit params). If these don't match, the entire overload is considered as not matching and not instantiated. * Special error messages are added for mismatching/missing/extra generic params. This is almost all of the diff in `semcall`. * Procs with matching generic parameters now instantiate only the type of the signature in overload resolution, not the proc itself, which also works for templates and macros. Unfortunately we can't entirely remove instantiations because overload resolution can't handle some cases with uninstantiated types even though it's resolved in the binding (see the last 2 blocks in `texplicitgenerics`). There are also some instantiation issues with default params that #24005 didn't fix but I didn't want this to become the 3rd huge generics PR in a row so I didn't dive too deep into trying to fix them. There is still a minor instantiation fix in `semtypinst` though for subscripts in calls. Additional changes: * Overloading of `[]` wasn't documented properly, it somewhat is now because we need to mention the limitation that it can't be done for generic procs/types. * Tests can now enable the new type mismatch errors with just `-d:testsConciseTypeMismatch` in the command. Package PRs: - using fork for now: [combparser](https://github.com/PMunch/combparser/pull/7) (partial generic instantiation) - merged: [cligen](https://github.com/c-blake/cligen/pull/233) (partial generic instantiation but non-overloaded + template) - merged: [neo](https://github.com/andreaferretti/neo/pull/56) (trying to instantiate template with no generic param)

opensym for templates + move behavior of opensymchoice to itself (#24007)

2024-08-28T18:51:13Z

fixes #15314, fixes #24002 The OpenSym behavior first added to generics in #23091 now also applies to templates, since templates can also capture symbols that are meant to be replaced by local symbols if the context imports symbols with the same name, as in the issue #24002. The experimental switch `templateOpenSym` is added to enable this behavior for templates only, and the experimental switch `openSym` is added to enable it for both templates and generics, and the documentation now mainly mentions this switch. Additionally the logic for `nkOpenSymChoice` nodes that were previously wrapped in `nkOpenSym` now apply to all `nkOpenSymChoice` nodes, and so these nodes aren't wrapped in `nkOpenSym` anymore. This means `nkOpenSym` can only have children of kind `nkSym` again, so it is more in line with the structure of symchoice nodes. As for why they aren't merged with `nkOpenSymChoice` nodes yet, we need some way to signal that the node shouldn't become ambiguous if other options exist at instantiation time, we already captured a symbol at the beginning and another symbol can only replace it if it's closer in scope and unambiguous.

opensym as node kind + fixed experimental switch (#23892)

2024-08-12T13:33:26Z

refs https://github.com/nim-lang/Nim/pull/23873#discussion_r1687995060, fixes #23386, fixes #23385, supersedes #23572 Turns the `nfOpenSym` node flag implemented in #23091 and extended in #23102 and #23873, into a node kind `nkOpenSym` that forms a unary node containing either `nkSym` or `nkOpenSymChoice`. Since this affects macros working on generic proc AST, the node kind is now only generated when the experimental switch `genericsOpenSym` is enabled, and a new node flag `nfDisabledOpenSym` is set to the `nkSym` or `nkOpenSymChoice` when the switch is not enabled so that we can give a warning. Now that the experimental switch has more reasonable semantics, we define `nimHasGenericsOpenSym2`.

fixes #14522 #22085 #12700 #23132; no range check for uints (#23930)

2024-08-11T11:10:04Z

fixes #14522 fixes #22085 fixes #12700 fixes #23132 closes https://github.com/nim-lang/Nim/pull/22343 (succeeded by this PR) completes https://github.com/nim-lang/RFCs/issues/175 follow up https://github.com/nim-lang/Nim/pull/12688

make routine implicitly gensym when other gensym symbol exists again (#23842)

2024-07-16T06:47:06Z

fixes #23813, partially reverts #23392 Before #23392, if a `gensym` symbol was defined before a proc with the same name in a template even with an `inject` annotation, the proc would be `gensym`. After #23392 the proc was instead changed to be `inject` as long as no `gensym` annotation was given. Now, to keep compatibility with the old behavior, the behavior is changed back to infer the proc as `gensym` when no `inject` annotation is given, however an explicit `inject` annotation will still inject the proc. This is also documented in the manual as the old behavior was undocumented and the new behavior is slightly different.