Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add wildcard support for UI tests #42434

Closed
estebank opened this issue Jun 4, 2017 · 8 comments
Closed

Add wildcard support for UI tests #42434

estebank opened this issue Jun 4, 2017 · 8 comments
Labels
A-testsuite Area: The testsuite used to check the correctness of rustc

Comments

@estebank
Copy link
Contributor

estebank commented Jun 4, 2017

Some diagnostics have different output in different architectures, which makes it harder to write arch agnostic UI tests. This has cropped up multiple times. Personally I've either reworked the test or changed it to a compile-fail test, but given that we'd like to consolidate on UI tests exclusively, UI tests should have a way to avoid this problem.

@Mark-Simulacrum Mark-Simulacrum added the A-testsuite Area: The testsuite used to check the correctness of rustc label Jun 4, 2017
@nikomatsakis
Copy link
Contributor

cc @petrochenkov @cengizio @kennytm -- all of whom have shown an interest in our testing infrastructure

@nikomatsakis
Copy link
Contributor

I agree, we need to fix this, but I'm not sure the best way.

I'm a bit reluctant to just add random wildcards into the output, since then you can't run the "regenerate reference" script and have it work.

One thought I had was to permit multiple references, one per architecture, but that does seem to have the same problem.

Another thought I had was to permit you to add a custom file that indicates other search-and-replace pairs specific to a particular test.

I guess it really depends on how often it comes up -- maybe it's ok to have to regenerate some reference files by hand, but it seems like a drag.

@Mark-Simulacrum
Copy link
Member

I think maybe the right way to fix this is to have an easy way to not run UI tests on more than one platform; most UI tests don't really need this I think. That is, we're primarily testing spans, not so much the error itself. Perhaps that's not the right way to think about them, though.

@kennytm
Copy link
Member

kennytm commented Jun 7, 2017

Instead of a custom file, I think the *.rs could specify headers for TestCx::normalize_output to teach it further normalization rules, e.g. for #42304

// normalize-stderr-x86: s/fn\(\)(>?) \(32 bits\)/fn()$1 (64 bits)/g
// normalize-stderr-arm: s/fn\(\)(>?) \(32 bits\)/fn()$1 (64 bits)/g
// normalize-stderr-emscripten: s/fn\(\)(>?) \(32 bits\)/fn()$1 (64 bits)/g

If regex is too heavy, we could use simple literals instead:

// normalize-stderr-x86: "fn() (32 bits)" -> "fn() (64 bits)"
// normalize-stderr-x86: "fn()> (32 bits)" -> "fn()> (64 bits)"
// normalize-stderr-arm: "fn() (32 bits)" -> "fn() (64 bits)"
// normalize-stderr-arm: "fn()> (32 bits)" -> "fn()> (64 bits)"
// normalize-stderr-emscripten: "fn() (32 bits)" -> "fn() (64 bits)"
// normalize-stderr-emscripten: "fn()> (32 bits)" -> "fn()> (64 bits)"

BTW there should be ignore-32bit / ignore-64bit / normalize-std???-32bit / normalize-std???-64bit so you don't need to write everything three times.

@nikomatsakis
Copy link
Contributor

@kennytm yes, that sounds fine too. We'd have to make the "update references" script rather smarter (so it can parse those things out).

@nikomatsakis
Copy link
Contributor

Maybe rewrite it in Rust :)

@kennytm
Copy link
Member

kennytm commented Jun 8, 2017

@nikomatsakis since the files generated by compile-test is already normalized, the "update references" script shouldn't need to be changed.

@nikomatsakis
Copy link
Contributor

@kennytm oh right, good point :)

bors added a commit that referenced this issue Jul 9, 2017
… r=nikomatsakis

compilertest (UI test): Support custom normalization.

Closes #42434.

Adds this header for UI tests:

```rust
// normalize-stderr-32bit: "fn() (32 bits)" -> "fn() ($PTR bits)"
```

It will normalize the `stderr` output on 32-bit platforms, by replacing all instances of `fn() (32 bits)` by `fn() ($PTR bits)`.

Extends the UI tests in #42304 and #41968 to 32-bit targets.

r? @nikomatsakis
bors added a commit that referenced this issue Jul 11, 2017
… r=nikomatsakis

compilertest (UI test): Support custom normalization.

Closes #42434.

Adds this header for UI tests:

```rust
// normalize-stderr-32bit: "fn() (32 bits)" -> "fn() ($PTR bits)"
```

It will normalize the `stderr` output on 32-bit platforms, by replacing all instances of `fn() (32 bits)` by `fn() ($PTR bits)`.

Extends the UI tests in #42304 and #41968 to 32-bit targets.

r? @nikomatsakis
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-testsuite Area: The testsuite used to check the correctness of rustc
Projects
None yet
Development

No branches or pull requests

4 participants