* Add use of Windows Wide CRT API for env. vars
Replaces use of CRT API `getenv` and `putenv` with respectively
`_wgetenv` and `_wputenv`. Motivation is to reliably convert environment
variables to UTF-8, and the wide API is best there, because it's
reliably UTF-16.
Changed the hack in `lib/std/private/win_setenv.nim` by switching the
order of the Unicode and MBCS environment update; Unicode first, MBCS
second. Because `_wgetenv`/`_wputenv` is now used, the Unicode
environment will be initialized, so it should always be updated.
Stop updating MBCS environment with the name of `getEnv`. It's not
necessarily true that MBCS encoding and the `string` encoding is the
same. Instead convert UTF-16 to current Windows code page with
`wcstombs`, and use that string to update MBCS.
Fixes regression in `6b3c77e` that caused `std/envvars.getEnv` or
`std/os.getEnv` on Windows to return non-UTF-8 encoded strings.
Add tests that test environment variables with Unicode characters in
their name or value.
* Fix test issues
Fixes
* `nim cpp` didn't compile the tests
* Nimscript import of `tosenv.nim` from `test_nimscript.nims` failed
with "cannot importc"
* Fix missing error check on `wcstombs`
* Fix ANSI testing errors
* Separate ANSI-related testing to their own tests, and only executing
them if running process has a specific code page
* Setting locale with `setlocale` was not reliable and didn't work on
certain machines
* Add handling of a "no character representation" error in second
`wcstombs` call
* tests/newruntime_misc: Increment allocCount
Increments overall allocations in `tnewruntime_misc` test. This is
because `getEnv` now does an additional allocation: allocation of the
UTF-16 string used as parameter to `c_wgetenv`.
* Revert "tests/newruntime_misc: Increment allocCount"
This reverts commit 4d4fe8bd3e.
* tests/newruntime_misc: Increment allocCount on Windows
Increments overall allocations in `tnewruntime_misc` test for Windows.
This is because `getEnv` on Windows now does an additional allocation:
allocation of the UTF-16 string used as parameter to `c_wgetenv`.
* Refactor, adding suggestions from code review
Co-authored-by: Clay Sweetser <Varriount@users.noreply.github.com>
* Document, adding suggestions
Co-authored-by: Clay Sweetser <Varriount@users.noreply.github.com>
Co-authored-by: ringabout <43030857+ringabout@users.noreply.github.com>
Co-authored-by: Clay Sweetser <Varriount@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] https://github.com/nim-lang/Nim/blob/d2318d9ccfe6/doc/manual.md#cstring-type
[2] https://github.com/nim-lang/Nim/blob/d2318d9ccfe6/changelogs/changelog_1_6_0.md#type-system
When checking conditions, pass `check` untyped argument directly to if. This results in better error messages when the condition is malformed.
Previously `check 1` would fail at compile time with `Error: type mismatch: got 'int literal(-2)' for '-2' but expected 'bool'`
Now it fails with `Error: type mismatch: got 'int literal(1)' for '1' but expected 'bool'`.
Similarly `check "foo"` would fail with
```
Error: type mismatch: got <string>
but expected one of:
proc `not`(a: typedesc): typedesc
first type mismatch at position: 1
required type for a: typedesc
but expression '"somestring"' is of type: string
...
```
Now it fails with `Error: type mismatch: got 'string' for '"somestring"' but expected 'bool'`
Based on what I understand from [Wikipedia](https://en.wikipedia.org/wiki/ISO_week_date#Weeks_per_year), 2001 does not have 53 weeks, but 2004, 2009, 2015, 2020 do. The years 2000 and 2001 seem to be copy pasted from the `getDaysInYear` example above. The result of `getWeeksInIsoYear` also seem to match up with Wikipedia.
That means these runnableExamples were never tested. Why is this the case? I only discovered this in #20091.
Without this, the httpclient examples are essentially setting you up for failure. I was bitten by this when my app became unable to open any more sockets.
I'm not entirely sure how long this will relevant, as I hope destructors will be added to an upcoming version of the stdlib. But figured it was worth submitting anyways!
* Improve rand(bool)
* Use sign test instead of mod 2
* Use mod 2 again, as it works for js
* Use right shift as suggested by the authors of xoroshiro
* Update random.nim
* General case doesn't need any right shift it was correct to begin with
* Update random.nim
* add comment
Co-authored-by: flywind <43030857+xflywind@users.noreply.github.com>
* Add sink and lent to critbits
* Remove lent for pairs
I guess lent doesn't work well inside tuples
* Remove lent from template in critbits
Apparently this also doesn't work, because some checks failed
Fixes Compilation error with --app:lib when a module tries to pull os.paramStr on posix by throwing a runtime exception instead.
More details here: #19964
This changes the default for the `last` parameter of various `find`
routines from `0` to `-1`. Previous default prevents limiting the search
to the first character. This is a logic error, as full text search was
performed for 2 *valid* values of `last`: `0` and `last.high()`.
Adds an overload for `initSkipTable` which returns a newly initialized
table. This encapsulates every single usage of a `var`-acting original
func in this module.
Co-authored-by: flywind <xzsflywind@gmail.com>
it appears the documentation intends to compare & with .fmt but there is no formatting in the string. even though the assert is true it doesn't quite prove that .fmt is an equivalent formatter.
* Fix questionable suggestion in `stutils` docs
- Removes the recommendation to pass a string slice for getting a relative
index for `find` and `rfind` functions, as this currently makes a string
copy, while a simple subtraction is enough.
- Docstring for `SkipTable` type.
* Doc layout fixup
* Better error message and tests for bad await
* Use compiles to check if await is valid
* temp: disable windows noasync test
* Better error report, simplify test
Co-authored-by: flywind <xzsflywind@gmail.com>
* Remove Deprecated httpcore func
* Remove Deprecated httpcore func
* Fix a test with Deprecated func
* Restart CI, Apple can code shit anymore I tell you
