nokogiri 1.16.0.rc1-x86-mingw32 → 1.16.0-x86-mingw32

Sign up to get free protection for your applications and to get access to all the features.

Potentially problematic release.


This version of nokogiri might be problematic. Click here for more details.

checksums.yaml CHANGED
@@ -1,7 +1,7 @@
1
1
  ---
2
2
  SHA256:
3
- metadata.gz: ad1d3852369d8539242e08228539f984e704e7f9b43b38a653f46faef1834f21
4
- data.tar.gz: cc6bc3ad4a8336c3ca013cf858d41fb0bbf210ec8958f55081039ee9be5b3ec8
3
+ metadata.gz: 871cc994c3c3efb913eeb9c6dde979bd0c219ad0bc2516206fd4efcd8b3f9d26
4
+ data.tar.gz: f9c8c63ea315743c416c24fc64f204cd82df482bfa69b0987f207b122091fe96
5
5
  SHA512:
6
- metadata.gz: 720f9547d72e421c830aceed387f5f85e0ac28c4458c3b0b77684b910608ef85b97e29661e61efe3dc08981b2c7c4ff408b9a39ee7c6e361463f1de737c1d504
7
- data.tar.gz: c54a795dd7457e046262643b8315264acd2d3720422cdb85dee6c3c7de0c9e681d2b7f3c31b160d8a1ed1e69f17951737d42c6ff2a47ca454a45384c4db56353
6
+ metadata.gz: baf21f55d793209dc142ec6dca5efb5046af8eb3b17131f4383bc47e51261772231436e5c67d01ccf26f499849d602931e0fb60a628342c76ddf3fcf7d3a3d84
7
+ data.tar.gz: fc995b693a34fbc686c522cfdc4aa1daa30fb20bb3cca8195fadedebace2f45adfa6968204c98cf3aa8bc96fa6578623538c9c3280ad38f77c8589a4cf899328
data/Gemfile CHANGED
@@ -11,7 +11,7 @@ group :development do
11
11
 
12
12
  # building extensions
13
13
  gem "rake-compiler", "1.2.5"
14
- gem "rake-compiler-dock", "1.4.0.rc2"
14
+ gem "rake-compiler-dock", "1.4.0"
15
15
 
16
16
  # parser generator
17
17
  gem "rexical", "= 1.0.7"
@@ -19,16 +19,16 @@ group :development do
19
19
  # tests
20
20
  gem "minitest", "5.20.0"
21
21
  gem "minitest-parallel_fork", "2.0.0"
22
- gem "ruby_memcheck", "2.2.1"
22
+ gem "ruby_memcheck", "2.3.0"
23
23
  gem "rubyzip", "~> 2.3.2"
24
24
  gem "simplecov", "= 0.21.2"
25
25
 
26
26
  # rubocop
27
27
  if Gem::Requirement.new("~> 3.0").satisfied_by?(Gem::Version.new(RUBY_VERSION))
28
- gem "rubocop", "1.58.0"
29
- gem "rubocop-minitest", "0.33.0"
28
+ gem "rubocop", "1.59.0"
29
+ gem "rubocop-minitest", "0.34.2"
30
30
  gem "rubocop-packaging", "0.5.2"
31
- gem "rubocop-performance", "1.19.1"
31
+ gem "rubocop-performance", "1.20.1"
32
32
  gem "rubocop-rake", "= 0.6.0"
33
33
  gem "rubocop-shopify", "2.14.0"
34
34
  end
@@ -38,5 +38,5 @@ end
38
38
  # `bundle config set --local without rdoc`
39
39
  # Then re-run `bundle install`.
40
40
  group :rdoc do
41
- gem "rdoc", "6.6.1"
41
+ gem "rdoc", "6.6.2"
42
42
  end
data/README.md CHANGED
@@ -55,6 +55,7 @@ There are a few ways to ask exploratory questions:
55
55
 
56
56
  - The Nokogiri mailing list is active at https://groups.google.com/group/nokogiri-talk
57
57
  - Open an issue using the "Help Request" template at https://github.com/sparklemotion/nokogiri/issues
58
+ - Open a discussion at https://github.com/sparklemotion/nokogiri/discussions
58
59
 
59
60
  Please do not mail the maintainers at their personal addresses.
60
61
 
@@ -90,6 +91,8 @@ We bump `Major.Minor.Patch` versions following this guidance:
90
91
  - Updating packaged libraries for non-security-related reasons.
91
92
  - Dropping support for EOLed Ruby versions. [Some folks find this objectionable](https://github.com/sparklemotion/nokogiri/issues/1568), but [SemVer says this is OK if the public API hasn't changed](https://semver.org/#what-should-i-do-if-i-update-my-own-dependencies-without-changing-the-public-api).
92
93
  - Backwards-incompatible changes to internal or private methods and constants. These are detailed in the "Changes" section of each changelog entry.
94
+ - Removal of deprecated methods or parameters, after a generous transition period; usually when those methods or parameters are rarely-used or dangerous to the user. Essentially, removals that do not justify a major version bump.
95
+
93
96
 
94
97
  `Patch`:
95
98
 
@@ -59,6 +59,10 @@ parse_io(VALUE klass, VALUE io, VALUE encoding)
59
59
  (xmlInputReadCallback)noko_io_read,
60
60
  (xmlInputCloseCallback)noko_io_close,
61
61
  (void *)io, enc);
62
+ if (!ctxt) {
63
+ rb_raise(rb_eRuntimeError, "failed to create xml sax parser context");
64
+ }
65
+
62
66
  if (ctxt->sax) {
63
67
  xmlFree(ctxt->sax);
64
68
  ctxt->sax = NULL;
Binary file
Binary file
Binary file
Binary file
@@ -2,5 +2,5 @@
2
2
 
3
3
  module Nokogiri
4
4
  # The version of Nokogiri you are using
5
- VERSION = "1.16.0.rc1"
5
+ VERSION = "1.16.0"
6
6
  end
@@ -1049,29 +1049,35 @@ module Nokogiri
1049
1049
 
1050
1050
  return Nokogiri::XML::NodeSet.new(document) if contents.empty?
1051
1051
 
1052
- # libxml2 does not obey the +recover+ option after encountering errors during +in_context+
1053
- # parsing, and so this horrible hack is here to try to emulate recovery behavior.
1054
- #
1055
- # Unfortunately, this means we're no longer parsing "in context" and so namespaces that
1056
- # would have been inherited from the context node won't be handled correctly. This hack was
1057
- # written in 2010, and I regret it, because it's silently degrading functionality in a way
1058
- # that's not easily prevented (or even detected).
1059
- #
1060
- # I think preferable behavior would be to either:
1061
- #
1062
- # a. add an error noting that we "fell back" and pointing the user to turning off the +recover+ option
1063
- # b. don't recover, but raise a sensible exception
1064
- #
1065
- # For context and background: https://github.com/sparklemotion/nokogiri/issues/313
1066
- # FIXME bug report: https://github.com/sparklemotion/nokogiri/issues/2092
1067
1052
  error_count = document.errors.length
1068
1053
  node_set = in_context(contents, options.to_i)
1069
- if node_set.empty? && (document.errors.length > error_count)
1070
- if options.recover?
1054
+ if document.errors.length > error_count
1055
+ raise document.errors[error_count] unless options.recover?
1056
+
1057
+ if node_set.empty?
1058
+ # libxml2 < 2.13 does not obey the +recover+ option after encountering errors during
1059
+ # +in_context+ parsing, and so this horrible hack is here to try to emulate recovery
1060
+ # behavior.
1061
+ #
1062
+ # (Note that HTML4 fragment parsing seems to have been fixed in abd74186, and XML
1063
+ # fragment parsing is fixed in 1c106edf. Both are in 2.13.)
1064
+ #
1065
+ # Unfortunately, this means we're no longer parsing "in context" and so namespaces that
1066
+ # would have been inherited from the context node won't be handled correctly. This hack
1067
+ # was written in 2010, and I regret it, because it's silently degrading functionality in
1068
+ # a way that's not easily prevented (or even detected).
1069
+ #
1070
+ # I think preferable behavior would be to either:
1071
+ #
1072
+ # a. add an error noting that we "fell back" and pointing the user to turning off the
1073
+ # +recover+ option
1074
+ # b. don't recover, but raise a sensible exception
1075
+ #
1076
+ # For context and background:
1077
+ # - https://github.com/sparklemotion/nokogiri/issues/313
1078
+ # - https://github.com/sparklemotion/nokogiri/issues/2092
1071
1079
  fragment = document.related_class("DocumentFragment").parse(contents)
1072
1080
  node_set = fragment.children
1073
- else
1074
- raise document.errors[error_count]
1075
1081
  end
1076
1082
  end
1077
1083
  node_set
metadata CHANGED
@@ -1,7 +1,7 @@
1
1
  --- !ruby/object:Gem::Specification
2
2
  name: nokogiri
3
3
  version: !ruby/object:Gem::Version
4
- version: 1.16.0.rc1
4
+ version: 1.16.0
5
5
  platform: x86-mingw32
6
6
  authors:
7
7
  - Mike Dalessio
@@ -20,7 +20,7 @@ authors:
20
20
  autorequire:
21
21
  bindir: bin
22
22
  cert_chain: []
23
- date: 2023-12-13 00:00:00.000000000 Z
23
+ date: 2023-12-27 00:00:00.000000000 Z
24
24
  dependencies:
25
25
  - !ruby/object:Gem::Dependency
26
26
  name: racc
@@ -307,9 +307,9 @@ required_ruby_version: !ruby/object:Gem::Requirement
307
307
  version: 3.4.dev
308
308
  required_rubygems_version: !ruby/object:Gem::Requirement
309
309
  requirements:
310
- - - ">"
310
+ - - ">="
311
311
  - !ruby/object:Gem::Version
312
- version: 1.3.1
312
+ version: '0'
313
313
  requirements: []
314
314
  rubygems_version: 3.3.26
315
315
  signing_key: