Windows 11 SDK Version 10.0.26100.0 introduced a new internal inline
function in ucrt/corecrt_math.h. Even it appears in object files and
will be included in the DEF file, it will be removed from the DLL and
result in a linker error.
http://ci.rvm.jp/results/trunk_asan@ruby-sp1/5409001
```
=================================================================
==3263562==ERROR: AddressSanitizer: stack-use-after-return on address 0x735a8f190da8 at pc 0x735a6f58dabc bp 0x735a639ffd10 sp 0x735a639ffd08
READ of size 4 at 0x735a8f190da8 thread T211
=================================================================
```
* Disable HEv2 tests temporarily
To suppress error log output in CI.
They should have been DISABLE in PR #12070.
---
Additionally, the following fixes have been made:
- Remove unnecessary `assert_separately` from the related tests
In #225 it was reported that the output looks incorrect:
```
$ cat /tmp/4a71c7e417cc9eac0971e3a2519b295c/scratch.rb
def x.y.z
end
$ ruby /tmp/4a71c7e417cc9eac0971e3a2519b295c/scratch.rb
/tmp/4a71c7e417cc9eac0971e3a2519b295c/scratch.rb: --> /tmp/4a71c7e417cc9eac0971e3a2519b295c/scratch.rb
expected a delimiter to close the parametersunexpected '.', ignoring it
> 1 def x.y.z
> 2 end
```
Specifically:
```
expected a delimiter to close the parametersunexpected '.', ignoring it
```
However this does not show up when executing the debug executable:
```
$ bin/bundle exec exe/syntax_suggest /tmp/4a71c7e417cc9eac0971e3a2519b295c/scratch.rb
--> /tmp/4a71c7e417cc9eac0971e3a2519b295c/scratch.rb
expected a delimiter to close the parameters
unexpected '.', ignoring it
> 1 def x.y.z
> 2 end
```
This is because `exe/syntax_suggest` uses STDOUT.puts while calling `ruby` with the filename uses a fake IO object represented by MiniStringIO. This class was incorrectly not adding a newline to the end of the print.
The fix was to move the class to it's own file where it can be tested and then fix the behavior.
close https://github.com/ruby/syntax_suggest/pull/225https://github.com/ruby/syntax_suggest/commit/d2ecd94a3b
Co-authored-by: Andy Yong <andyywz@gmail.com>
http://ci.rvm.jp/results/trunk_asan@ruby-sp1/5408428
```
==3159643==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x796cf8f09041 at pc 0x6539bbf68ded bp 0x796cfadffcf0 sp 0x796cfadff4b8
READ of size 2 at 0x796cf8f09041 thread T13
#0 0x6539bbf68dec in strlen (/tmp/ruby/build/trunk_asan/ruby+0x18edec) (BuildId: cca267c7ae091060e1b82a6b4ed1aeaf00edebab)
```
Do not wait Connection Attempt Delay without in progress fds
Reset Connection Attempt Delay when connection fails and there is no other socket connection in progress.
This is intended to resolve an issue that was temporarily worked around in Pull Request #12062.
`TCPServer::new` (used in tests such as `TestNetHTTP_v1_2_chunked#test_timeout_during_non_chunked_streamed_HTTP_session_write`) can only connect over either IPv6 or IPv4, depending on the environment.
Since HEv2 attempts to connect over IPv6 first, environments where IPv6 connections are unavailable return ECONNREFUSED immediately.
In such cases, the client should immediately retry the connection over IPv4.
However, HEv2 includes a specification for a "Connection Attempt Delay," where it waits 250ms after the previous connection attempt before starting the next one.
This delay causes Net::OpenTimeout (100ms) to be exceeded while waiting for the next connection attempt to start.
With this change, when a connection attempt fails, if there are sockets still attempting to connect and there are addresses yet to be tried, the Connection Attempt Delay will be resetted, allowing the next connection attempt to start immediately.
---
Additionally, the following minor fixes have been made:
- The `nfds` value used for select(2) is now reset with each wait.
This avoids the need to malloc, and reduces the complexity of truncating
the long string for display in RUBY_DESCRIPTION.
The developer of a GC implementation should be responsible for giving it
a succinct name.
This will add +MOD_GC to the version string and Ruby description when
Ruby is compiled with shared gc support.
When shared GC support is compiled in and a GC module has been loaded
using RUBY_GC_LIBRARY, the version string will include the name of
the currently active GC as reported by the rb_gc_active_gc_name function
in the form
+MOD_GC[gc_name]
[Feature #20794]
And a default and readonly key to the GC.config hash that names the
current GC implementation.
This is provided by each implementation by the API function
rb_gc_impl_active_gc_name