Merge pull request #4014 from DataDog/sarahchen6/update-ruby-core-sou…

…re-gem Replace 'debase' with 'datadog'-ruby_core_source
DataDog · Oct 22, 2024 · e20ee5b · e20ee5b
2 parents 72e8816 + 9743f03
commit e20ee5b
Show file tree

Hide file tree

Showing 555 changed files with 1,111 additions and 1,111 deletions.
diff --git a/.gitlab/install_datadog_deps.rb b/.gitlab/install_datadog_deps.rb
@@ -70,7 +70,7 @@
 }
 
 [
-  'debase-ruby_core_source',
+  'datadog-ruby_core_source',
   'ffi',
   'libddwaf',
   'msgpack',

diff --git a/datadog.gemspec b/datadog.gemspec
@@ -64,7 +64,7 @@ Gem::Specification.new do |spec|
   # Used by the profiler native extension to support Ruby < 2.6 and > 3.2
   #
   # We decided to pin it at the latest available version and will manually bump the dependency as needed.
-  spec.add_dependency 'debase-ruby_core_source', '= 3.3.1'
+  spec.add_dependency 'datadog-ruby_core_source', '= 3.3.6'
 
   # Used by appsec
   spec.add_dependency 'libddwaf', '~> 1.14.0.0.0'

diff --git a/ext/datadog_profiling_native_extension/NativeExtensionDesign.md b/ext/datadog_profiling_native_extension/NativeExtensionDesign.md
@@ -68,7 +68,7 @@ internal types, structures and functions).
 Because these private header files are not included in regular Ruby installations, we have two different workarounds:
 
 1. for Ruby versions 2.6 to 3.2 we make use use the Ruby private MJIT header
-2. for Ruby versions < 2.6 and > 3.2 we make use of the `debase-ruby_core_source` gem
+2. for Ruby versions < 2.6 and > 3.2 we make use of the `datadog-ruby_core_source` gem
 
 Functions which make use of these headers are defined in the <private_vm_api_acccess.c> file.
 
@@ -91,9 +91,9 @@ version. e.g. `rb_mjit_min_header-2.7.4.h`.
 
 This header was removed in Ruby 3.3.
 
-### Approach 2: Using the `debase-ruby_core_source` gem
+### Approach 2: Using the `datadog-ruby_core_source` gem
 
-The [`debase-ruby_core_source`](https://github.com/ruby-debug/debase-ruby_core_source) contains almost no code;
+The [`datadog-ruby_core_source`](https://github.com/DataDog/datadog-ruby_core_source) contains almost no code;
 instead, it just contains per-Ruby-version folders with the private VM headers (`.h`) files for that version.
 
 Thus, even though a regular Ruby installation does not include these files, we can access the copy inside this gem.

diff --git a/ext/datadog_profiling_native_extension/extconf.rb b/ext/datadog_profiling_native_extension/extconf.rb
@@ -256,21 +256,21 @@ def skip_building_extension!(reason)
   create_makefile EXTENSION_NAME
 else
   # The MJIT header was introduced on 2.6 and removed on 3.3; for other Rubies we rely on
-  # the debase-ruby_core_source gem to get access to private VM headers.
+  # the datadog-ruby_core_source gem to get access to private VM headers.
   # This gem ships source code copies of these VM headers for the different Ruby VM versions;
-  # see https://github.com/ruby-debug/debase-ruby_core_source for details
+  # see https://github.com/DataDog/datadog-ruby_core_source for details
 
   create_header
 
-  require "debase/ruby_core_source"
+  require "datadog/ruby_core_source"
   dir_config("ruby") # allow user to pass in non-standard core include directory
 
   # This is a workaround for a weird issue...
   #
-  # The mkmf tool defines a `with_cppflags` helper that debase-ruby_core_source uses. This helper temporarily
+  # The mkmf tool defines a `with_cppflags` helper that datadog-ruby_core_source uses. This helper temporarily
   # replaces `$CPPFLAGS` (aka the C pre-processor [not c++!] flags) with a different set when doing something.
   #
-  # The debase-ruby_core_source gem uses `with_cppflags` during makefile generation to inject extra headers into the
+  # The datadog-ruby_core_source gem uses `with_cppflags` during makefile generation to inject extra headers into the
   # path. But because `with_cppflags` replaces `$CPPFLAGS`, well, the default `$CPPFLAGS` are not included in the
   # makefile.
   #
@@ -281,12 +281,12 @@ def skip_building_extension!(reason)
   # `VM_CHECK_MODE=1` when building Ruby will trigger this issue (because somethings in structures the profiler reads
   # are ifdef'd out using this setting).
   #
-  # To workaround this issue, we override `with_cppflags` for debase-ruby_core_source to still include `$CPPFLAGS`.
-  Debase::RubyCoreSource.define_singleton_method(:with_cppflags) do |newflags, &block|
+  # To workaround this issue, we override `with_cppflags` for datadog-ruby_core_source to still include `$CPPFLAGS`.
+  Datadog::RubyCoreSource.define_singleton_method(:with_cppflags) do |newflags, &block|
     super("#{newflags} #{$CPPFLAGS}", &block)
   end
 
-  Debase::RubyCoreSource
+  Datadog::RubyCoreSource
     .create_makefile_with_core(
       proc do
         headers_available =

diff --git a/ext/datadog_profiling_native_extension/native_extension_helpers.rb b/ext/datadog_profiling_native_extension/native_extension_helpers.rb
@@ -9,7 +9,7 @@ module NativeExtensionHelpers
       # Can be set to force rubygems to fail gem installation when profiling extension could not be built
       ENV_FAIL_INSTALL_IF_MISSING_EXTENSION = "DD_PROFILING_FAIL_INSTALL_IF_MISSING_EXTENSION"
 
-      # The MJIT header was introduced on 2.6 and removed on 3.3; for other Rubies we rely on debase-ruby_core_source
+      # The MJIT header was introduced on 2.6 and removed on 3.3; for other Rubies we rely on datadog-ruby_core_source
       CAN_USE_MJIT_HEADER = RUBY_VERSION.start_with?("2.6", "2.7", "3.0.", "3.1.", "3.2.")
 
       def self.fail_install_if_missing_extension?

diff --git a/ext/datadog_profiling_native_extension/private_vm_api_access.c b/ext/datadog_profiling_native_extension/private_vm_api_access.c
@@ -13,7 +13,7 @@
   #include RUBY_MJIT_HEADER
 #else
   // The MJIT header was introduced on 2.6 and removed on 3.3; for other Rubies we rely on
-  // the debase-ruby_core_source gem to get access to private VM headers.
+  // the datadog-ruby_core_source gem to get access to private VM headers.
 
   // We can't do anything about warnings in VM headers, so we just use this technique to suppress them.
   // See https://nelkinda.com/blog/suppress-warnings-in-gcc-and-clang/#d11e364 for details.

diff --git a/gemfiles/jruby_9.2_activesupport.gemfile.lock b/gemfiles/jruby_9.2_activesupport.gemfile.lock
diff --git a/gemfiles/jruby_9.2_aws.gemfile.lock b/gemfiles/jruby_9.2_aws.gemfile.lock
diff --git a/gemfiles/jruby_9.2_contrib.gemfile.lock b/gemfiles/jruby_9.2_contrib.gemfile.lock
diff --git a/gemfiles/jruby_9.2_contrib_old.gemfile.lock b/gemfiles/jruby_9.2_contrib_old.gemfile.lock
diff --git a/gemfiles/jruby_9.2_core_old.gemfile.lock b/gemfiles/jruby_9.2_core_old.gemfile.lock
diff --git a/gemfiles/jruby_9.2_elasticsearch_7.gemfile.lock b/gemfiles/jruby_9.2_elasticsearch_7.gemfile.lock
diff --git a/gemfiles/jruby_9.2_elasticsearch_8.gemfile.lock b/gemfiles/jruby_9.2_elasticsearch_8.gemfile.lock
diff --git a/gemfiles/jruby_9.2_elasticsearch_latest.gemfile.lock b/gemfiles/jruby_9.2_elasticsearch_latest.gemfile.lock
diff --git a/gemfiles/jruby_9.2_graphql_2.0.gemfile.lock b/gemfiles/jruby_9.2_graphql_2.0.gemfile.lock
diff --git a/gemfiles/jruby_9.2_http.gemfile.lock b/gemfiles/jruby_9.2_http.gemfile.lock
diff --git a/gemfiles/jruby_9.2_opensearch_2.gemfile.lock b/gemfiles/jruby_9.2_opensearch_2.gemfile.lock
diff --git a/gemfiles/jruby_9.2_opensearch_3.gemfile.lock b/gemfiles/jruby_9.2_opensearch_3.gemfile.lock
diff --git a/gemfiles/jruby_9.2_opensearch_latest.gemfile.lock b/gemfiles/jruby_9.2_opensearch_latest.gemfile.lock
diff --git a/gemfiles/jruby_9.2_rack_1.gemfile.lock b/gemfiles/jruby_9.2_rack_1.gemfile.lock
diff --git a/gemfiles/jruby_9.2_rack_2.gemfile.lock b/gemfiles/jruby_9.2_rack_2.gemfile.lock
diff --git a/gemfiles/jruby_9.2_rack_3.gemfile.lock b/gemfiles/jruby_9.2_rack_3.gemfile.lock