* fix#19882 Improve error message when instantiating generics that lack a type
* Update tests/errmsgs/t19882.nim
Co-authored-by: Clay Sweetser <Varriount@users.noreply.github.com>
put mOpenArrayToSeq in compile-time evaluation whitelist
(it was mNone before which was whitelisted), homogenize
"ordinal type expected" errors, put overloadable enums
in non-experimental manual
prevent use-after-free bugs in cased objects
the bug happens specifically when deleting
an item in a seq. The item taking it's place
might not have the same case fields. Then =sink(x[i], move x[xl])
might leave the deleted fields still in memory!
If the new item switches branches again, you get a use-after-free bug.
* remove deprecated pragma syntax from 0.20.0
closes#4651, closes#16653 with a cheap fix for now due to
how early `tfFinal` is set
* remove type pragma between name and generics
* undo removal, try removing bind expression (0.8.14)
* fix test, unremove bind expr
* remove again
* Update changelog.md
Co-authored-by: konsumlamm <44230978+konsumlamm@users.noreply.github.com>
* dependencies @ HEAD & weave test dependencies
* try fix package ci
Co-authored-by: konsumlamm <44230978+konsumlamm@users.noreply.github.com>
* Fix 16937: Make --clib option works
* Make tests/compiler/tcmdlineclib.nim works from any current dir
* Try to fix link error on macosx
* Add a comment to tests/compiler/tcmdlineclib.nims
Co-authored-by: Clay Sweetser <Varriount@users.noreply.github.com>
* implement case for cstring
for now just converts to string on C backend
* custom implementation for cstring
* remove leftover
* revert even more
* add nil + fix packages weird variant literal bug
* update docs
- apparently TLineInfo's implementation of `==` ignores the column. After I fixed
the code to use exact TLineInfo comparison I fixed several other issues hidden
by that issue.
- Replaced `tuple[sym, info]` with `SymInfoPair`
Fix links to subheader when TOC is present
It was observed (in https://github.com/nim-lang/Nim/pull/20112)
that links to 2nd- (and subsequent) -level headings
fail if TOC is present, e.g.:
```nim
.. contents::
Type relations
==============
Convertible relation
--------------------
Ref. `Convertible relation`_
```
The problem here is that links are resolved in `rst.nim` but later
`rstgen.nim` fixes ("fixes") anchors to make them unique so that
TOC always works (if e.g. there was another sub-section like
"Convertible relation").
The solution implemented in this PR is to move that fix-up of anchors
into `rst.nim`, so that link resolution could know final anchors.
The bug seems to be added in https://github.com/nim-lang/Nim/pull/2332
in 2015, that is it is present in Nim 1.0.
* micro implementation of rfc 149
refs https://github.com/nim-lang/RFCs/issues/149
* number/array/seq literals, more statements
* try fix number literal alias issue
* renew expectedType with if/case/try branch types
* fix (nerf) index type handling and float typed int
* use typeAllowed
* tweaks + const test (tested locally) [skip ci]
* fill out more of the checklist
* more literals, change @ order, type conversions
Not copying the full call tree before the typedesc call check
in `semIndirectOp` is also a small performance improvement.
* disable self-conversion warning
* revert type conversions (maybe separate op later)
* deal with CI for now (seems unrelated), try enums
* workaround CI different way
* proper fix
* again
* see sizes
* lol
* overload selection, simplify int literal -> float
* range, new @ solution, try use fitNode for nil
* use new magic
* try fix ranges, new magic, deal with #20193
* add documentation, support templates
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
* Add `doctype: RST|Markdown|RstMarkdown` pragma
Implements https://github.com/nim-lang/RFCs/issues/68 ,
see also discussion in https://github.com/nim-lang/Nim/issues/17987
The permitted values:
* `markdown`, which is default. It still contains nearly all of
the RST supported but it is assumed that in time we will give up
most or all RST features in this mode
* `rst`, without any extensions
* `RstMarkdown` — compatibility with Nim 1.x. It's basically RST
with those Markdown features enabled that don't conflict with RST.
* Apply suggestions from code review
Co-authored-by: Clay Sweetser <Varriount@users.noreply.github.com>
* Additional fix in spirit of review
* Fix test after #20188
Co-authored-by: Clay Sweetser <Varriount@users.noreply.github.com>
* remove a special case in sigmatch; distinct pointer types no longer match `nil` type
* add tests
* fixes tests
* Update changelog.md
Co-authored-by: konsumlamm <44230978+konsumlamm@users.noreply.github.com>
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
Co-authored-by: konsumlamm <44230978+konsumlamm@users.noreply.github.com>
The Nim manual says that an implicit conversion to cstring will
eventually not be allowed [1]:
A Nim `string` is implicitly convertible to `cstring` for convenience.
[...]
Even though the conversion is implicit, it is not *safe*: The garbage collector
does not consider a `cstring` to be a root and may collect the underlying
memory. For this reason, the implicit conversion will be removed in future
releases of the Nim compiler. Certain idioms like conversion of a `const` string
to `cstring` are safe and will remain to be allowed.
And from Nim 1.6.0, such a conversion triggers a warning [2]:
A dangerous implicit conversion to `cstring` now triggers a `[CStringConv]` warning.
This warning will become an error in future versions! Use an explicit conversion
like `cstring(x)` in order to silence the warning.
However, some files in this repo produced such a warning. For example,
before this commit, compiling `parsejson.nim` would produce:
/foo/Nim/lib/pure/parsejson.nim(221, 37) Warning: implicit conversion to 'cstring' from a non-const location: my.buf; this will become a compile time error in the future [CStringConv]
/foo/Nim/lib/pure/parsejson.nim(231, 39) Warning: implicit conversion to 'cstring' from a non-const location: my.buf; this will become a compile time error in the future [CStringConv]
This commit resolves the most visible `CStringConv` warnings, making the
cstring conversions explicit.
[1] d2318d9ccf/doc/manual.md (cstring-type)
[2] d2318d9ccf/changelogs/changelog_1_6_0.md (type-system)
