Rename tests/ to test/. NFC (#17502)

The name of the directory where tests live is more commonly known as
just `test`.  This matches the convention used by sister projects of
emscripten: llvm, binaryen, and wabt.

This is big change but git is good a tracking renames so anyone with
outstanding changes in this directory should not have any issues.

Author: sbc100

.circleci/config.yml

@@ -108,12 +108,12 @@ commands:
           name: embuilder build ALL
           command: |
             ./embuilder build ALL
-            ./tests/runner test_hello_world
+            ./test/runner test_hello_world
       - run:
           name: embuilder (LTO)
           command: |
             ./embuilder build MINIMAL --lto
-            ./tests/runner test_hello_world
+            ./test/runner test_hello_world
       - run:
           name: embuilder (WASM64)
           command: |
@@ -122,12 +122,12 @@ commands:
           name: embuilder (PIC)
           command: |
             ./embuilder build MINIMAL_PIC --pic
-            ./tests/runner test_hello_world
+            ./test/runner test_hello_world
       - run:
           name: embuilder (PIC+LTO)
           command: |
             ./embuilder build MINIMAL --pic --lto
-            ./tests/runner test_hello_world
+            ./test/runner test_hello_world
       - run:
           name: freeze cache
           command: |
@@ -169,7 +169,7 @@ commands:
       - run:
           name: run tests
           command: |
-            ./tests/runner << parameters.test_targets >>
+            ./test/runner << parameters.test_targets >>
             $EMSDK_PYTHON ./tools/check_clean.py
   run-tests-linux:
     description: "Runs emscripten tests"
@@ -229,7 +229,7 @@ commands:
             echo "-----"
             echo "Running browser tests"
             echo "-----"
-            tests/runner browser skip:browser.test_sdl2_mouse skip:browser.test_html5_webgl_create_context skip:browser.test_webgl_offscreen_canvas_in_pthread skip:browser.test_webgl_offscreen_canvas_in_mainthread_after_pthread skip:browser.test_glut_glutget
+            test/runner browser skip:browser.test_sdl2_mouse skip:browser.test_html5_webgl_create_context skip:browser.test_webgl_offscreen_canvas_in_pthread skip:browser.test_webgl_offscreen_canvas_in_mainthread_after_pthread skip:browser.test_glut_glutget
             # posix and emrun suites are disabled because firefox errors on
             #  "Firefox is already running, but is not responding."
             # TODO: find out a way to shut down and restart firefox
@@ -256,8 +256,8 @@ commands:
             # PIC version of libSDL which is used by test_sdl2_misc_main_module
             export EM_FROZEN_CACHE=""
             # skip test_zzz_zzz_4gb_fail as it OOMs on the current bot
-            tests/runner browser posixtest_browser.test_pthread_create_1_1 skip:browser.test_zzz_zzz_4gb_fail
-            tests/runner emrun
+            test/runner browser posixtest_browser.test_pthread_create_1_1 skip:browser.test_zzz_zzz_4gb_fail
+            test/runner emrun
   test-sockets-chrome:
     description: "Runs emscripten sockets tests under chrome"
     steps:
@@ -276,7 +276,7 @@ commands:
             CHROME_FLAGS_NOCACHE: "--disk-cache-dir=/dev/null --disk-cache-size=1 --media-cache-size=1 --disable-application-cache --incognito"
           command: |
             export EMTEST_BROWSER="/usr/bin/google-chrome $CHROME_FLAGS_BASE $CHROME_FLAGS_HEADLESS $CHROME_FLAGS_WASM $CHROME_FLAGS_NOCACHE"
-            tests/runner sockets
+            test/runner sockets
 
 jobs:
   build-docs:

.coveragerc

@@ -1,6 +1,6 @@
 [run]
 source = .
-omit = ./tests/*
+omit = ./test/*
        ./third_party/*
        ./tools/emcoverage.py
        test.py

.eslintrc.yml

@@ -10,7 +10,7 @@ ignorePatterns:
   - "site/"
   - "cache/"
   - "third_party/"
-  - "tests/"
+  - "test/"
   - "src/polyfill/"
   - "src/library*.js"
   - "src/runtime_*.js"

.flake8

@@ -4,7 +4,7 @@ exclude =
  ./third_party/, # third-party code
  ./tools/filelock.py, # third-party code
  ./tools/scons/, # third-party code
- ./tests/third_party/, # third-party code
+ ./test/third_party/, # third-party code
  ./site/source/conf.py,
  ./tools/debug/,
  ./system/lib/, # system libraries
@@ -14,5 +14,5 @@ exclude =
 # they need to implement the specific plugin APIs
 per-file-ignores =
   ./tools/ports/*.py: U100
-  ./tests/*.py: U100
+  ./test/*.py: U100
   ./tools/toolchain_profiler.py: U100

.gitattributes

@@ -3,9 +3,9 @@
 tools/crunch-worker.js -diff
 third_party/lzma.js/lzma-decoder.js -diff
 third_party/lzma.js/lzma-full.js -diff
-tests/other/test_emsize.js -diff
+test/other/test_emsize.js -diff
 src/emscripten-source-map.min.js -diff
-tests/* linguist-vendored
+test/* linguist-vendored
 third_party/* linguist-vendored
 system/ linguist-vendored
 

.gitmodules

@@ -1,3 +1,3 @@
-[submodule "tests/third_party/posixtestsuite"]
-	path = tests/third_party/posixtestsuite
+[submodule "test/third_party/posixtestsuite"]
+	path = test/third_party/posixtestsuite
 	url = https://github.com/emscripten-core/posixtestsuite

ChangeLog.md

@@ -20,6 +20,9 @@ See docs/process.md for more on how version tagging works.
 
 3.1.18
 ------
+- The tests/ directory was renamed to just test/ to match other project close
+  emscripten (llvm, wabt, binaryen).  This should not effect any users of
+  emscripten, only developers. (#17502)
 
 3.1.17 - 07/22/2022
 ------

docs/packaging.md

@@ -6,7 +6,7 @@ linux distributions, or other downstream SDKs.
 
 Firstly, we provide an install script in `tools/install.py`.  This allows
 just the end-user parts of emscripten to be installed.  For example this avoids
-including the `tests/third_party` directory which is of that biggest parts 
+including the `test/third_party` directory which is of that biggest parts 
 of the source tree.
 
 If you prefer, you can use `make install` or `make dist` which invokes

emcc.py

@@ -1118,7 +1118,7 @@ def run(args):
       compiler = shared.EMCC
       if run_via_emxx:
         compiler = shared.EMXX
-      cmd = [compiler, utils.path_from_root('tests', input_file), '-v', '-c', '-o', temp_target] + args
+      cmd = [compiler, utils.path_from_root('test', input_file), '-v', '-c', '-o', temp_target] + args
       proc = run_process(cmd, stderr=PIPE, check=False)
       if proc.returncode != 0:
         print(proc.stderr)

requirements-dev.txt

@@ -18,5 +18,5 @@ jinja2<3.1
 # Pin docutils because newer versions are not compatible with sphinx 2.4.4
 docutils==0.17.1
 
-# Needed by tests/test_sockets.py
+# Needed by test/test_sockets.py
 websockify==0.10.0

site/source/docs/api_reference/Filesystem-API.rst

@@ -16,7 +16,7 @@ Emscripten predominantly compiles code that uses synchronous file I/O, so the ma
 
 File data in Emscripten is partitioned by mounted file systems. Several file systems are provided. An instance of :ref:`MEMFS <filesystem-api-memfs>` is mounted to ``/`` by default. The subdirectories `/home/web_user` and `/tmp` are also created automatically, in addition to several other special devices and streams (e.g. `/dev/null`, `/dev/random`, `/dev/stdin`, `/proc/self/fd`); see `FS.staticInit()` in the FS library for full details. Instances of :ref:`NODEFS <filesystem-api-nodefs>` and :ref:`IDBFS <filesystem-api-idbfs>` can be mounted to other directories if your application needs to :ref:`persist data <filesystem-api-persist-data>`.
 
-The automatic tests in `tests/test_core.py <https://github.com/emscripten-core/emscripten/blob/1.29.12/tests/test_core.py#L4285>`_ (search for ``test_files``) contain many examples of how to use this API. The :ref:`tutorial <tutorial-files>` also shows how to pre-load a file so that it can be read from compiled C/C++.
+The automatic tests in `test/test_core.py <https://github.com/emscripten-core/emscripten/blob/1.29.12/tests/test_core.py#L4285>`_ (search for ``test_files``) contain many examples of how to use this API. The :ref:`tutorial <tutorial-files>` also shows how to pre-load a file so that it can be read from compiled C/C++.
 
 A high level overview of the way File Systems work in Emscripten-ported code is provided in the :ref:`file-system-overview`.
 
@@ -75,7 +75,7 @@ NODEFS
 
 This file system lets a program in *node* map directories (via a mount operation) on the host filesystem to directories in Emscripten's virtual filesystem. It uses node's synchronous `FS API <http://nodejs.org/api/fs.html>`_ to immediately persist any data written to the Emscripten file system to your local disk.
 
-See `this test <https://github.com/emscripten-core/emscripten/blob/main/tests/fs/test_nodefs_rw.c>`_ for an example.
+See `this test <https://github.com/emscripten-core/emscripten/blob/main/test/fs/test_nodefs_rw.c>`_ for an example.
 
 .. _filesystem-api-noderawfs:
 
@@ -260,7 +260,7 @@ File system API
        });
      }
 
-  A real example of this functionality can be seen in `test_idbfs_sync.c <https://github.com/emscripten-core/emscripten/blob/main/tests/fs/test_idbfs_sync.c>`_.
+  A real example of this functionality can be seen in `test_idbfs_sync.c <https://github.com/emscripten-core/emscripten/blob/main/test/fs/test_idbfs_sync.c>`_.
 
   :param bool populate: ``true`` to initialize Emscripten's file system data with the data from the file system's persistent source, and ``false`` to save Emscripten`s file system data to the file system's persistent source.
   :param callback: A notification callback function that is invoked on completion of the synchronization. If an error occurred, it will be provided as a parameter to this function.

site/source/docs/api_reference/emscripten.h.rst

@@ -1282,7 +1282,7 @@ Typedefs
 
   Unaligned types. These may be used to force LLVM to emit unaligned loads/stores in places in your code where :ref:`SAFE_HEAP <debugging-SAFE-HEAP>` found an unaligned operation.
 
-  For usage examples see `tests/core/test_set_align.c <https://github.com/emscripten-core/emscripten/blob/main/tests/core/test_set_align.c>`_.
+  For usage examples see `test/core/test_set_align.c <https://github.com/emscripten-core/emscripten/blob/main/test/core/test_set_align.c>`_.
 
   .. note:: It is better to avoid unaligned operations, but if you are reading from a packed stream of bytes or such, these types may be useful!
 

site/source/docs/api_reference/fetch.rst

@@ -87,7 +87,7 @@ attributes:
   }
 
 For a full example, see the file
-tests/fetch/example_async_xhr_to_memory_via_indexeddb.c.
+``test/fetch/example_async_xhr_to_memory_via_indexeddb.c``.
 
 Persisting data bytes from memory
 ---------------------------------

site/source/docs/api_reference/html5.h.rst

@@ -131,9 +131,9 @@ Test/Example code
 
 The HTML5 test code demonstrates how to use this API:
 
-  - `test_html5_core.c <https://github.com/emscripten-core/emscripten/blob/main/tests/test_html5_core.c>`_
-  - `test_html5_fullscreen.c <https://github.com/emscripten-core/emscripten/blob/main/tests/test_html5_fullscreen.c>`_
-  - `test_html5_mouse.c <https://github.com/emscripten-core/emscripten/blob/main/tests/test_html5_mouse.c>`_
+  - `test_html5_core.c <https://github.com/emscripten-core/emscripten/blob/main/test/test_html5_core.c>`_
+  - `test_html5_fullscreen.c <https://github.com/emscripten-core/emscripten/blob/main/test/test_html5_fullscreen.c>`_
+  - `test_html5_mouse.c <https://github.com/emscripten-core/emscripten/blob/main/test/test_html5_mouse.c>`_
 
 
 General types

site/source/docs/api_reference/module.rst

@@ -159,15 +159,15 @@ Other methods
 
 .. js:function:: Module.getPreloadedPackage
 
-  If you want to manually manage the download of .data file packages for custom caching, progress reporting and error handling behavior, you can implement the ``Module.getPreloadedPackage = function(remotePackageName, remotePackageSize)`` callback to provide the contents of the data files back to the file loading scripts. The return value of this callback should be an Arraybuffer with the contents of the downloade file data. See file ``tests/manual_download_data.html`` and the test ``browser.test_preload_file_with_manual_data_download`` for an example.
+  If you want to manually manage the download of .data file packages for custom caching, progress reporting and error handling behavior, you can implement the ``Module.getPreloadedPackage = function(remotePackageName, remotePackageSize)`` callback to provide the contents of the data files back to the file loading scripts. The return value of this callback should be an Arraybuffer with the contents of the downloade file data. See file ``test/manual_download_data.html`` and the test ``browser.test_preload_file_with_manual_data_download`` for an example.
 
 .. js:function:: Module.instantiateWasm
 
   When targeting WebAssembly, Module.instantiateWasm is an optional user-implemented callback function that the Emscripten runtime calls to perform the WebAssembly instantiation action. The callback function will be called with two parameters, ``imports`` and ``successCallback``. ``imports`` is a JS object which contains all the function imports that need to be passed to the WebAssembly Module when instantiating, and once instantiated, this callback function should call ``successCallback()`` with the generated WebAssembly Instance object.
 
   The instantiation can be performed either synchronously or asynchronously. The return value of this function should contain the ``exports`` object of the instantiated WebAssembly Module, or an empty dictionary object ``{}`` if the instantiation is performed asynchronously, or ``false`` if instantiation failed.
 
-  Overriding the WebAssembly instantiation procedure via this function is useful when you have other custom asynchronous startup actions or downloads that can be performed in parallel to WebAssembly compilation. Implementing this callback allows performing all of these in parallel. See the file ``tests/manual_wasm_instantiate.html`` and the test ``browser.test_manual_wasm_instantiate`` for an example of how this construct works in action.
+  Overriding the WebAssembly instantiation procedure via this function is useful when you have other custom asynchronous startup actions or downloads that can be performed in parallel to WebAssembly compilation. Implementing this callback allows performing all of these in parallel. See the file ``test/manual_wasm_instantiate.html`` and the test ``browser.test_manual_wasm_instantiate`` for an example of how this construct works in action.
 
   .. note:: Sanitizers or source map is currently not supported if overriding WebAssembly instantiation with Module.instantiateWasm. Providing Module.instantiateWasm when source map or sanitizer is enabled can prevent WebAssembly instantiation from finishing.
 

site/source/docs/api_reference/proxying.h.rst

@@ -135,5 +135,5 @@ defined within namespace ``emscripten``.
     ``emscripten_proxying_finish`` or ``ProxyingCtx::finish`` and ``false`` otherwise.
 
 .. _proxying.h: https://github.com/emscripten-core/emscripten/blob/main/system/include/emscripten/proxying.h
-.. _test_pthread_proxying.c: https://github.com/emscripten-core/emscripten/blob/main/tests/pthread/test_pthread_proxying.c
-.. _test_pthread_proxying_cpp.cpp: https://github.com/emscripten-core/emscripten/blob/main/tests/pthread/test_pthread_proxying_cpp.cpp
+.. _test_pthread_proxying.c: https://github.com/emscripten-core/emscripten/blob/main/test/pthread/test_pthread_proxying.c
+.. _test_pthread_proxying_cpp.cpp: https://github.com/emscripten-core/emscripten/blob/main/test/pthread/test_pthread_proxying_cpp.cpp

site/source/docs/api_reference/wasm_workers.rst

@@ -89,7 +89,7 @@ Pthreads and Wasm Workers share several similarities:
  * Both types of threads have thread-local storage (TLS) support via ``thread_local`` (C++11),
    ``_Thread_local`` (C11) and ``__thread`` (GNU11) keywords.
  * Both types of threads support TLS via explicitly linked in Wasm globals (see
-   ``tests/wasm_worker/wasm_worker_tls_wasm_assembly.c/.S`` for example code)
+   ``test/wasm_worker/wasm_worker_tls_wasm_assembly.c/.S`` for example code)
  * Both types of threads have a concept of a thread ID (``pthread_self()`` for pthreads,
    ``emscripten_wasm_worker_self_id()`` for Wasm Workers)
  * Both types of threads can perform an event-based and an infinite loop programming model.
@@ -352,4 +352,4 @@ The following build options are not supported at the moment with Wasm Workers:
 Example Code
 ============
 
-See the directory tests/wasm_workers/ for code examples on different Wasm Workers API functionality.
+See the directory ``test/wasm_workers/`` for code examples on different Wasm Workers API functionality.

site/source/docs/building_from_source/verify_emscripten_environment.rst

@@ -43,7 +43,7 @@ The next test is to actually build some code! On the command prompt navigate to
 ::
 
   cd emscripten/<version of emscripten you installed>
-  ./emcc tests/hello_world.cpp
+  ./emcc test/hello_world.cpp
 
 This command should complete without warnings and you should find the newly-compiled JavaScript file (**a.out.js**) in the current directory.
 

site/source/docs/compiling/Building-Projects.rst

@@ -189,7 +189,7 @@ Using libraries
 Built-in support is available for a number of standard libraries: *libc*, *libc++* and *SDL*. These will automatically be linked when you compile code that uses them (you do not even need to add ``-lSDL``, but see below for more SDL-specific details).
 
 If your project uses other libraries, for example
-`zlib <https://github.com/emscripten-core/emscripten/tree/main/tests/third_party/zlib>`_
+`zlib <https://github.com/emscripten-core/emscripten/tree/main/test/third_party/zlib>`_
 or *glib*, you will need to build and link them. The normal approach is to build
 the libraries (to object files, or ``.a`` archives of them) and then link those
 with your main program to emit JavaScript+WebAssembly.
@@ -217,7 +217,7 @@ Emscripten Ports is a collection of useful libraries, ported to Emscripten. They
 
 .. code-block:: bash
 
-  emcc tests/sdl2glshader.c -sUSE_SDL=2 -sLEGACY_GL_EMULATION -o sdl2.html
+  emcc test/sdl2glshader.c -sUSE_SDL=2 -sLEGACY_GL_EMULATION -o sdl2.html
 
 You should see some notifications about SDL2 being used, and built if it wasn't previously. You can then view ``sdl2.html`` in your browser.
 
@@ -370,7 +370,7 @@ set via an environment variable.  e.g::
 Examples / test code
 ====================
 
-The Emscripten test suite (`tests/runner.py <https://github.com/emscripten-core/emscripten/blob/main/tests/runner.py>`_) contains a number of good examples — large C/C++ projects that are built using their normal build systems as described above: `freetype <https://github.com/emscripten-core/emscripten/tree/main/tests/third_party/freetype>`_, `openjpeg <https://github.com/emscripten-core/emscripten/tree/main/tests/third_party/openjpeg>`_, `zlib <https://github.com/emscripten-core/emscripten/tree/main/tests/third_party/zlib>`_, `bullet <https://github.com/emscripten-core/emscripten/tree/main/tests/third_party/bullet>`_ and `poppler <https://github.com/emscripten-core/emscripten/tree/main/tests/third_party/poppler>`_.
+The Emscripten test suite (`test/runner.py <https://github.com/emscripten-core/emscripten/blob/main/test/runner.py>`_) contains a number of good examples — large C/C++ projects that are built using their normal build systems as described above: `freetype <https://github.com/emscripten-core/emscripten/tree/main/test/third_party/freetype>`_, `openjpeg <https://github.com/emscripten-core/emscripten/tree/main/test/third_party/openjpeg>`_, `zlib <https://github.com/emscripten-core/emscripten/tree/main/test/third_party/zlib>`_, `bullet <https://github.com/emscripten-core/emscripten/tree/main/test/third_party/bullet>`_ and `poppler <https://github.com/emscripten-core/emscripten/tree/main/test/third_party/poppler>`_.
 
 It is also worth looking at the build scripts in the `ammo.js <https://github.com/kripken/ammo.js/blob/main/CMakeLists.txt>`_ project.
 

site/source/docs/contributing/developers_guide.rst

@@ -52,7 +52,7 @@ Patches should be submitted as *pull requests* in the normal way on GitHub.
 When submitting patches, please:
 
 - Add an automatic test if you add any new functionality or fix a bug. Search
-  in ``tests/*.py`` for related tests, as often the simplest thing is to add to
+  in ``test/*.py`` for related tests, as often the simplest thing is to add to
   an existing one. If you're not sure how to test your code, feel free to ask
   for help.
 - Pay attention to our coding style specified in