This commit attempts to improve testing of strictFuncs and views, and
prevent regressions like #16873 (resolved by 0b01eddace).
We previously only explicitly tested strictFuncs and views with a
smaller number of stdlib modules, mostly in:
- tests/effects/tstrict_funcs.nim
- tests/views/tcan_compile_nim.nim
Note that this commit leaves the `pegs` module commented out; it
cannot currently be compiled with `--experimental:views` (see #16892).
Note also that this commit is not sufficient to test strictFuncs and
views, but it does detect a subset of problems.
* minor improvements
* IC: added the required logic for compilerProcs
* LazySym ftw
* we need this testing logic
* reimplement the old way we use for module package creation
* fixes a regression; don't pick module names if you can avoid it
* link similar compiler option proc together
* fixup links
* fix formatting and links
* example formatting
* drop declared
* link to compilesettings
* only link define pragmas once
* drop another declared
* backlink to compileOptions from compilesettings
* remove newline
* fix#16885
* Fixup nimdoc for the CSS filter change
* Use the same Nim devel versions
* Revert "Use the same Nim devel versions"
This reverts commit 8559308f9b.
* Revert "Fixup nimdoc for the CSS filter change"
This reverts commit 99ec00a4bd.
* Fixup nimdoc.out.css
Co-authored-by: zetashift <rishi2@laptop.localdomain>
Previously, compiling a file containing just `import critbits` with
`nim c --experimental:strictFuncs` would produce the following error:
critbits.nim(529, 6) Error: 'toCritBitTree' can have side effects
This was introduced by 2aed418698 (#16564).
Fixes: #16873
* penalizes the quality score of deprecated symbols
* uses quality more pervasively in order to reflect deprecation impact
* impacts both sug and con
additional notes:
* linux i386 CI was failing
* this is because the suggested results differ slightly in their sort
* 64 bit tables.getOrDefault:441 was returned, while 32 bit returned 422
* for now simply removing the last line is good enough
* A new request should always have a new content-length
In [my last PR](https://github.com/nim-lang/Nim/pull/16618) I made a mistake by assuming that the client.headers were cleared on every request, like the Python version. So, due to the fact that Nim keeps the client headers, we need to clear the Content-Length header on each request (which makes sense because you almost never want to use the same Content-Length twice, but you may want to reuse other headers)
* Move content-length to newHeaders instead of in the global client headers
* Use single backticks
* removed dead code
* we need even more laziness for the generic caches
* make it bootstrap on older Nims
* wrote more deserialization code
* IC: replay required methods information