This reverts commit 743a31d639,
"[ruby/date] [DOC] Make document coverage 100%". This file is only
for rdoc coverage in the date gem, and useless when the built-in Time
is documented.
When loading a crafted marshal data of Random, a pointer to an illegal
address was created. I don't think there is any harm since the data is
normalized before access, but just to be safe, I add a check to make it
an error.
With https://github.com/ruby/ruby/pull/12156,
the memory of the `struct fast_fallback_getaddrinfo_shared`
is now allocated even if there is only one address family.
This change will always free it when `TCPSocket.new` finishes.
(https://github.com/ruby/rdoc/pull/1212)
Currently, the gemspec's files are defined by hand, which is error-prone.
For example: https://github.com/ruby/rdoc/pull/1211
This commit uses `Dir.glob` where possible to reduce the risk of that
happening again.
- Additional files added with this approach:
```
# This should have been added by only captured by this commit
lib/rdoc/parser/prism_ruby.rb
# These are folders and can be included/ignored either way
lib/rdoc/generator/template/darkfish
lib/rdoc/generator/template/darkfish/css
lib/rdoc/generator/template/darkfish/fonts
lib/rdoc/generator/template/darkfish/images
lib/rdoc/generator/template/darkfish/js
lib/rdoc/generator/template/json_index
lib/rdoc/generator/template/json_index/js
```
- Files that are ignored after this change:
```
# They make no difference on documentation generation
# Probably can be removed
lib/rdoc/generator/template/darkfish/.document
lib/rdoc/generator/template/json_index/.document
```
ac2a151f10
A follow-up to ef59175a68. That commit
uses `&body->local_table[...]` but `body->local_table` is already freed.
I think it is an undefined behavior to calculate a pointer that exceeds
the bound by more than 1.
This change moves the free of `body->local_table` after the calculation.
Coverity Scan found this issue.
fill_lines is passed -1 for offset, which causes it to read the -1 index
of traces. This is not valid memory as -1 is reading before the trace
global variable in rb_print_backtrace. This code comes from commit
99d1f5f88b, where there used to be special
handling for the -1 index.
We can see this error in ASAN:
==71037==ERROR: AddressSanitizer: global-buffer-overflow on address 0x00010157abf8 at pc 0x00010116f3b8 bp 0x00016f92c3b0 sp 0x00016f92c3a8
READ of size 8 at 0x00010157abf8 thread T0
#0 0x10116f3b4 in debug_info_read addr2line.c:1945
#1 0x10116cc90 in fill_lines addr2line.c:2497
#2 0x101169dbc in rb_dump_backtrace_with_lines addr2line.c:2635
#3 0x100e56788 in rb_print_backtrace vm_dump.c:825
#4 0x100e56db4 in rb_vm_bugreport vm_dump.c:1155
#5 0x100734dc4 in rb_bug_without_die error.c:1085
#6 0x100734ae4 in rb_bug error.c:109
macOS clang 16 generates DWARF5, which have Mach-O section names that
are limited to 16 characters, which causes sections with long names to
be truncated and not match above.
See: https://wiki.dwarfstd.org/Best_Practices.md#Mach-2d-O
GCC 13 prints the following warning.
20241127T001003Z.log.html.gz
```
compiling generator.c
generator.c: In function ‘raise_generator_error’:
generator.c:91:5: warning: function ‘raise_generator_error’ might be a candidate for ‘gnu_printf’ format attribute [-Wsuggest-attribute=format]
91 | VALUE str = rb_vsprintf(fmt, args);
| ^~~~~
```
This change prevents the warning by specifying the format attribute.
b8c1490846
While profiling `strscan`, I noticed `rb_must_asciicompat` was quite
slow, as more than 5% of the benchmark was spent in it: https://share.firefox.dev/49bOcTn
By checking for the common 3 ASCII compatible encoding index first,
we can skip a lot of expensive operations in the happy path.
