1. 28 Jul, 2020 2 commits
  2. 02 Mar, 2020 1 commit
  3. 19 Jan, 2020 7 commits
    • Philip Chimento's avatar
      js: Remove jsapi-wrapper.h · d783d40c
      Philip Chimento authored
      With SpiderMonkey 68, it's no longer necessary to mark SpiderMonkey
      header files as system headers, and it's also no longer necessary to
      include <js-config.h> before any other header files, as SpiderMonkey
      has sorted that out internally.
      
      We remove jsapi-wrapper.h and define DEBUG directly in config.h instead
      of indirectly in jsapi-wrapper.h via HAVE_SPIDERMONKEY_DEBUG.
      
      This should reduce compile time, on average, because in most .h files
      we now only need to include <js/TypeDecls.h>.
      d783d40c
    • Philip Chimento's avatar
      context: Rewrite promise job queue · b29e8362
      Philip Chimento authored
      SpiderMonkey 68 has a new promise job queue API, where instead of
      setting up callbacks when initializing the JS engine, you have to pass
      it an object with overridden methods. It makes the most sense for this
      object to be the GjsContextPrivate object, since the previous callbacks
      were already members of GjsContextPrivate. This means that
      GjsContextPrivate now inherits from JS::JobQueue.
      b29e8362
    • Philip Chimento's avatar
      engine: Add missing headers · 00f39892
      Philip Chimento authored
      Some APIs in SpiderMonkey 68 have only moved to a separate header file
      and not otherwise changed.
      00f39892
    • Philip Chimento's avatar
      engine: Remove locale callbacks · 9f7a5ba5
      Philip Chimento authored
      Since SpiderMonkey 68, the locale callbacks are only ever called if
      SpiderMonkey was compiled without the Intl API. Instead, SpiderMonkey
      uses libicu to provide this behaviour.
      
      Since we do already require a version with the Intl API enabled, there's
      no point in providing these callbacks any longer.
      9f7a5ba5
    • Philip Chimento's avatar
      js: Use JS::SourceText to store source code · 3b19f3fb
      Philip Chimento authored
      JS::SourceText<char16_t> and JS::SourceText<mozilla::Utf8Unit> have
      replaced the JS::SourceBufferHolder API. Use the new API instead of the
      old one.
      
      It's now possible to compile UTF-8 source text directly, without
      converting it to two-byte characters first. We do this wherever
      possible, but it is currently broken when trying to execute with an
      environment object, as we do in eval_with_scope() and module imports.
      See https://bugzilla.mozilla.org/show_bug.cgi?id=1404784
      3b19f3fb
    • Philip Chimento's avatar
      js: Use new warnings API · cec9a234
      Philip Chimento authored
      The new warnings API is JS::WarnUTF8(), JS::WarnLatin1(), and
      JS::WarnASCII(). It can now fail, in the case where the warning was
      upgraded into an error.
      
      There was one instance where we used the old ASCII API which is now
      replaced by the UTF8 API. It is possible, though extremely unlikely,
      that a boxed union type might have a non-ASCII name, so just change it
      to UTF8 here.
      cec9a234
    • Philip Chimento's avatar
      js: Rename "compartments" to "realms" · 7b644626
      Philip Chimento authored
      In SpiderMonkey 68, a "realm" is the term for the environment belonging
      to a particular global object, so when you enter the "realm" of a global
      object you are executing code with that object as the global object.
      
      "Compartments" are still a thing but they are now more focused on
      security, and are used for isolating code in different browser tabs in
      Firefox, for example. All code in GJS except the debugger and the
      coverage collector is run within the same compartment.
      
      Some APIs that previously operated on a global object that was passed
      in, now operate on the current realm.
      7b644626
  4. 30 Nov, 2019 1 commit
  5. 28 Oct, 2019 1 commit
    • Chun-wei Fan's avatar
      gjs/*.cpp, util/*.cpp: Check for sys/signal.h and _WIN32 · 5629c6ce
      Chun-wei Fan authored
      Add a configure-time check for sys/signal.h and only include it in the
      sources when it is found.  For context.h, since it is public, only
      include it when we are not building for Windows (i.e. _WIN32 is not
      defined), because it does not exist for Windows.
      
      Also, we might be checking for G_OS_WIN32 before we include the GLib
      headers, so check for the presence of _WIN32 in those cases, since it
      will be defined by default on all compilers targeting Windows.
      5629c6ce
  6. 19 Aug, 2019 1 commit
  7. 09 Jun, 2019 1 commit
    • Philip Chimento's avatar
      maint: Fix header includes once and for all · 01920362
      Philip Chimento authored
      Previously #include statements were a bit of a mess across the codebase.
      This commit is the result of a pass by the IWYU (Include What You Use)
      tool, which suggests headers to add or remove based on what is in the
      file, and can also suggest forward-declaring classes instead of
      including their headers, if they are only used as a pointer in a
      particular file. Cleaning this up should in general speed up compile
      times.
      
      IWYU isn't perfect, it produces a number of false positives, so we don't
      try to automate this process and we don't accept all of its
      recommendations. We do add a script and configuration file to the tools/
      directory so that IWYU can be every so often in the future.
      
      We also clean up all the includes according to a consistent style, which
      is now described clearly in the C++ style guide.
      01920362
  8. 08 May, 2019 1 commit
    • Philip Chimento's avatar
      build: Annotate all unused arguments · ba402686
      Philip Chimento authored
      In order to compile cleanly with -Wunused-parameter, we annotate all
      unused function parameters. We do have a lot of these, as we make heavy
      use of callbacks and don't always need all the parameters of these
      callbacks.
      
      If the parameter name does not carry any meaning (for example,
      JSContext* cx, or void* user_data) then we just delete the name and
      leave the type to indicate that it is intentionally unused. If the name
      is important, then we annotate the parameter with G_GNUC_UNUSED.
      
      In the case where a parameter is used in one branch of an #ifdef only,
      we mark it in the other branch with a (void) cast.
      ba402686
  9. 02 May, 2019 1 commit
  10. 06 Nov, 2018 1 commit
    • Philip Chimento's avatar
      context: Move all private context methods to C++ class · 1abdf08f
      Philip Chimento authored
      This is in preparation for having an "Atoms" accessor object for strings
      that are interned in the JS engine. This moves all internal GjsContext
      API to GjsContextPrivate, the private struct of GjsContext which is now
      also a C++ class.
      1abdf08f
  11. 05 Nov, 2018 1 commit
  12. 04 Nov, 2018 1 commit
    • Philip Chimento's avatar
      engine: Use a "source hook" and keep sources in memory · b032fda4
      Philip Chimento authored
      Previously we always set the "source is lazy" flag on all code that we
      evaluated. This was incorrect, since that meant that SpiderMonkey would
      not keep the source code in memory, so it would not do on-the-fly
      bytecode generation, and the debugger would not be able to examine
      sources.
      
      If you use lazy sources, you are supposed to define a "source hook"
      object that will return source code based on the source's URI.
      
      This commit removes the lazy bit from all sources, except for compartment
      bootstrap code; those sources already come from a GResource, so they are
      already stored in memory and it's easy to write a source hook to retrieve
      them.
      
      That could be expanded to cover modules imported from GResource sources,
      but that seems a bit overcomplicated.
      b032fda4
  13. 30 Oct, 2018 1 commit
    • Philip Chimento's avatar
      js: Introduce annotations for using return values · 425b94d6
      Philip Chimento authored
      This introduces two annotations to functions. GJS_USE is a macro for GCC
      and Clang's "warn_unused_result" annotation, meaning that the return
      value of a function must not be ignored. This allows us to catch some
      cases where we are neglecting to do error checking.
      
      The second annotation is GJS_JSAPI_RETURN_CONVENTION which for now is
      identical to GJS_USE, but could be made into a custom annotation in the
      future which a static analyzer plugin could use to enforce further checks
      at compile time. The "JSAPI return convention" is valid on functions that
      return bool or a pointer type, and whose first parameter is JSContext*. If
      false or nullptr is returned, then an exception must be pending at return
      time on the passed-in JSContext. If true or a non-nullptr value is
      returned, then no exception must be pending.
      
      This commit only has the addition of the attributes, and a few fixes
      mandated by the autoformatter, so it can be reviewed "lightly".
      425b94d6
  14. 23 Oct, 2018 1 commit
    • Andrea Azzarone's avatar
      engine: mozjs60 changes for GC sweeping tracking · eb9ece54
      Andrea Azzarone authored
      With the switch to mozjs60, the sweeping happens in three phases insted of two:
      JSFINALIZE_GROUP_PREPARE, JSFINALIZE_GROUP_START, and JSFINALIZE_GROUP_END.
      Update the code to keep track of whether the runtime is currently doing GC
      sweeping, and prevent calling JS code at that time.
      
      Fixes: #212
      eb9ece54
  15. 13 Oct, 2018 1 commit
  16. 29 Jul, 2018 1 commit
    • Philip Chimento's avatar
      js: Misc mozjs60 API changes · 67d7efc6
      Philip Chimento authored
      - An argument that we didn't use was removed from the JSFinalizeCallback
        signature
      
      - JS_SetLocaleCallbacks API changed (is JSRuntime coming back again?)
      
      - Giving a JSVERSION to a compartment or CompileOptions is not supported
        anymore
      
      - Use JS::CurrentThreadIsHeapCollecting() instead of our hacky workaround
        in GC
      
      - JS::PromiseRejectionHandlingState now is in the JS namespace
      
      - JS::Value is now incompatible with C-linkage, so any function returning
        one must be moved outside G_BEGIN_DECLS/G_END_DECLS
      
      - JSPROP_SHARED is gone
      
      - Defining a property with getter and setter now doesn't take a JS::Value
      
      See: #161
      67d7efc6
  17. 08 Jun, 2018 1 commit
  18. 14 Apr, 2018 1 commit
  19. 04 Apr, 2018 1 commit
  20. 22 Jan, 2018 1 commit
    • Philip Chimento's avatar
      js: Remove context from GjsAutoJSChar · 93551813
      Philip Chimento authored
      SpiderMonkey now clarifies in the comments in their header file, that
      it's OK to pass a null JSContext to JS_free(cx, ptr). This allows us to
      stop tracking the JSContext in GjsAutoJSChar, which was a big pain.
      93551813
  21. 30 Nov, 2017 1 commit
    • Philip Chimento's avatar
      js: Use JS_EncodeStringToUTF8() directly where advantageous · 6aafd113
      Philip Chimento authored
      We have gjs_string_to_utf8() which takes a JS::Value, checks if it holds
      a string and throws an exception if not, then converts to a JSString and
      calls JS_EncodeStringToUTF8() on it. This fixes some inefficient uses of
      that function.
      
      In a few cases the typecheck was repeated before calling
      gjs_string_to_utf8(), the outer typecheck is simply removed.
      
      In other cases the typecheck was already guaranteed because we wanted to
      take a different code path when the value didn't hold a string, in these
      cases we inline the value.toString() call and the JS_EncodeStringToUTF8()
      call.
      
      In many other cases we were converting a JSString to JS::Value only to
      pass it to gjs_string_to_utf8() so we could convert it back to JSString.
      In these cases we just use JS_EncodeStringToUTF8() directly.
      
      gjs_string_to_utf8() is still useful when looking up a property on an
      object that is supposed to be a string, and it's still used quite often
      in the codebase.
      6aafd113
  22. 20 Nov, 2017 1 commit
    • Philip Chimento's avatar
      jsapi-util-string: Use mozjs UTF8-to-JSString conversion · 6fa31261
      Philip Chimento authored
      There are two paths for decoding UTF8 strings directly to JSString:
      JS_NewStringCopyUTF8N() and JS_NewStringCopyUTF8Z(). Mostly we have a
      zero-terminated string in GJS, so we shorten gjs_string_from_utf8() to
      remove its string length argument and use JS_NewStringCopyUTF8Z().
      
      There are a few places where we have a non-zero-terminated string, so we
      introduce gjs_string_from_utf8_n() to handle that path.
      
      A few places we were doing a UTF8 conversion where it was not necessary.
      6fa31261
  23. 19 Jul, 2017 2 commits
  24. 09 Jul, 2017 4 commits
  25. 24 May, 2017 1 commit
  26. 16 Apr, 2017 1 commit
    • Philip Chimento's avatar
      maint: Use correct mode lines in all files · 9e4169eb
      Philip Chimento authored
      I finally figured out why my highlighting was always messed up; the mode
      lines in all these files said "C" whereas they were C++ or JS files. This
      was in such a blind spot that I even copied it to new files that I had
      created in the meantime...
      
      Unreviewed.
      9e4169eb
  27. 02 Apr, 2017 2 commits
  28. 21 Feb, 2017 1 commit
    • Chun-wei Fan's avatar
      Windows: Fix DllMain() for running on SpiderMonkey 38 · b4867389
      Chun-wei Fan authored
      It appears that we need to call JS_ShutDown() during DLL_THREAD_DETACH
      right after we call gjs_destroy_runtime_for_current_thread(), otherwise
      when for example gjs-console finishes running the script, it will not exit
      as the SpiderMonkey JS engine did not ShutDown.  This appears to be in
      line with what is done on non-Windows.
      
      We still need to call JS_Init() during DLL_PROCESS_ATTACH (which is
      simplified a bit, as we can just set gjs_is_inited based on the results
      of JS_Init() and so assert later on that JS_Init() did indeed succeed).
      
      https://bugzilla.gnome.org/show_bug.cgi?id=775868
      b4867389