Commit Graph
4 Commits
Author SHA1 Message Date
Jon Ross-Perkins 129f31710d Disable autoupdate in explorer tests. (#4023)
Just replacing AUTOUPDATE with NOAUTOUPDATE, and removing the autoupdate
script. Tests will still run, but autoupdate may need to be fixed if
significant changes are made.

I noticed this while trying to autoupdate for #4007 (because we verify
that tests have been autoupdated). Autoupdate was likely broken by
#3449.

Trying to run with no changes gives:

```
CHECK failure at testing/file_test/file_test_base.cpp:801: !absl::GetFlag(FLAGS_test_targets_file).empty(): Missing --test_targets_file.
```

This is because the `file_test` rule creates a file with test inputs
that it runs with, which the prebuilt binary doesn't provide.

A local kludge to create a `file_test` target not using prebuilt_binary
showed another error:

```
: CommandLine Error: Option ': CommandLine Error: Option 'parser_debug' registered more than once!
LLVM ERROR: inconsistency in registered CommandLine options
trace_phase' registered more than once!
LLVM ERROR: inconsistency in registered CommandLine options
```

I'm thinking here that the explorer code hasn't been in enough use, and
we're seeing some rot as a consequence. Rather than trying to maintain
it, I'm suggesting to go with NOAUTOUPDATE.
2024-06-04 16:44:36 +00:00
Richard Smith 212188a922 Prefer to put STDOUT CHECK at the end of the file. (#3073)
Allow interleaving of STDOUT and STDERR check lines. Put STDOUT lines
after the line they're attached to, and STDERR lines before. If no
STDOUT check line is attached to any line, then put them all at the end
of the file instead.

This is intended to better handle the case where stdout contains
unreplaced mentions of line numbers, and also reflects that stdout is
typically a consequence of the test rather than commentary on it, so
placing it after the test seems likely to read better.
2023-08-08 19:51:52 +00:00
Jon Ross-Perkins 82f33ff384 Use new test framework in explorer to reduce per-test overhead (#2811)
Isolating test execution time (no build time included):

- Linux, `lit` test-per-file: Elapsed time: 28.214s, Critical Path: 13.97s
- Linux, `cc_test`-per-file: Elapsed time: 11.534s, Critical Path: 6.05s
- Linux, merged `cc_test` with 50 shards: Elapsed time: 11.677s, Critical Path: 11.17s
- Mac, `lit` test-per-file: Elapsed time: 295.686s, Critical Path: 20.00s
- Mac, `cc_test`-per-file: Elapsed time: 55.788s, Critical Path: 3.81s
- Mac, merged `cc_test` with 50 shards: Elapsed time: 16.269s, Critical Path: 7.54s

In GH actions:

- [Before](https://github.com/carbon-language/carbon-lang/actions/runs/4866602695/jobs/8678306144?pr=2799):
  - test / test (ubuntu-22.04, fastbuild) (pull_request_target) Successful in 20m
  - test / test (ubuntu-22.04, opt) (pull_request_target) Successful in 15m
  - test / test (macos-12, fastbuild) (pull_request_target) Successful in 36m
  - test / test (macos-12, opt) (pull_request_target) Successful in 21m
- [After](https://github.com/carbon-language/carbon-lang/actions/runs/4875154751/jobs/8697004066?pr=2811):
  - test / test (ubuntu-22.04, fastbuild) (pull_request_target) Successful in 10m
  - test / test (ubuntu-22.04, opt) (pull_request_target) Successful in 9m
  - test / test (macos-12, fastbuild) (pull_request_target) Successful in 12m
  - test / test (macos-12, opt) (pull_request_target) Successful in 9m

I'm still leaving a handful of `lit` tests to test end-to-end binary execution. This is why testdata directories are split (`lit` tests next to the `explorer` binary, the `cc_test`s next to `ParseAndExecute`).
2023-05-15 16:23:59 -07:00
Richard Smith c8141b59d9 Remove ExpectType and some calls to IsImplicitlyConvertible. (#2647)
These functions are dangerous, as they check whether conversions are possible without actually performing the conversions. In each case where they were used, explorer would crash in some cases if a user-defined conversion is required.

This change moves us more towards implicit conversions being handled by a regular function call on an interface and away from them being magical builtins. Unfortunately, this exposes a pre-existing bug that a call of the form `x.(ImplicitAs(T).Convert)()` compiles even if `x` only has an explicit conversion to `T`. That's worked around here for now, but will need a proper fix later.
2023-03-02 14:04:44 -08:00