Remove in-tree regex/base64 support #21458
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
r? @pcwalton (rust_highfive has picked a reviewer for you, use r? to override) |
|
|
|
Most of |
alexcrichton
force-pushed
the
remove-some-code
branch
from
7c03fbf to
69eef0a
Compare
|
Ack I knew I forgot something! Thanks @pczarn for pointing that out, I've ported it over now. |
alexcrichton
force-pushed
the
remove-some-code
branch
from
69eef0a to
1c17d4f
Compare
|
@bors: r+ 1c17d4f |
|
⌛ Testing commit 1c17d4f with merge e0cfc25... |
|
💔 Test failed - auto-mac-64-nopt-t |
alexcrichton
force-pushed
the
remove-some-code
branch
from
1c17d4f to
a4fbe08
Compare
|
@bors: r=brson a4fbe08 |
|
Needs a rebase |
This is not used in-tree and is available out-of-tree
The regex library was largely used for non-critical aspects of the compiler and various external tooling. The library at this point is duplicated with its out-of-tree counterpart and as such imposes a bit of a maintenance overhead as well as compile time hit for the compiler itself. The last major user of the regex library is the libtest library, using regexes for filters when running tests. This removal means that the filtering has gone back to substring matching rather than using regexes.
alexcrichton
force-pushed
the
remove-some-code
branch
from
a4fbe08 to
6c29708
Compare
bors
added a commit
that referenced
this pull request
Jan 24, 2015
The base64 support can be trivially removed (there are no in-tree users) and the regex support is a whopping 4k lines of code to maintain for a few non-critical uses in-tree. This commit migrates all current users in-tree away from regexes to custom matching code. The most critical application affected by this migration is that the testing framework no longer considers filter arguments as regexes, but rather just a substring matching. It is expected that more featureful testing frameworks can evolve outside of the in-tree libtest version over time which can properly depend on libregex from crates.io. [breaking-change]
This was referenced Jan 25, 2015
Closed
ghost
mentioned this pull request
nelsonjchen
added a commit
to nelsonjchen/pulldown-cmark
that referenced
this pull request
Sep 18, 2017
While the main executable can also run tests, keeping the standard `cargo test` function useful is also helpful. * Add end character to generated tests to work with substring only matching of tests cases. Regex test matching was removed in early 2015 in: rust-lang/rust#21458 You can only filter tests by substring. What if you wanted to run `spec_test_6`? You would run `spec_test_64` too. Adding the character, `_` to the end allows a workaround of specifying `spec_test_6_` as the match to run if you wanted to only run `spec_test_6_`. E.g. `cargo test spec_test_6_` * Tests are modified to generate tests with spec names in the tests Previously, all tests were generated with `spec_test_#_` as their name, even if they were not generated from `spec.txt`. The `tables.txt` spec would also generate a `spec_test_#_`. This is an issue if you wanted to test `spec_test_6_` and only wanted to run the one from `spec.txt` and not `tables.txt`'s `spec_test_6_`'. While you could build the test executables and only run the specific test executable with the `spec_test_#_` you want, it's kind of annoying. This change derives the test names from the spec filename. For example, `spec.txt` will generate `spec_test_6_` while `tables.txt` and `footnotes.txt` will generate `tables_test_6_` and `footnotes_test_6_` respectively. Future optional specifications that might be added will utilize the same rule. This allows testing of example 6 from the `footnotes.txt` spec by simply doing: `cargo test footnotes_test_6_`
nelsonjchen
added a commit
to nelsonjchen/pulldown-cmark
that referenced
this pull request
Sep 18, 2017
While the main executable can also run tests, keeping the standard `cargo test` function useful is also helpful. * * * Add end character to generated tests to work with substring only matching of tests cases. Regex test matching was removed in early 2015 in: rust-lang/rust#21458 You can only filter tests by substring. What if you wanted to run `spec_test_6`? You would run `spec_test_64` too. Adding the character, `_` to the end allows a workaround of specifying `spec_test_6_` as the match to run if you wanted to only run `spec_test_6_`. E.g. `cargo test spec_test_6_` * * * Tests are modified to generate tests with spec names in the tests Previously, all tests were generated with `spec_test_#_` as their name, even if they were not generated from `spec.txt`. The `tables.txt` spec would also generate a `spec_test_#_`. This is an issue if you wanted to test `spec_test_6_` and only wanted to run the one from `spec.txt` and not `tables.txt`'s `spec_test_6_`'. While you could build the test executables and only run the specific test executable with the `spec_test_#_` you want, it's kind of annoying. This change derives the test names from the spec filename. For example, `spec.txt` will generate `spec_test_6_` while `tables.txt` and `footnotes.txt` will generate `tables_test_6_` and `footnotes_test_6_` respectively. Future optional specifications that might be added will utilize the same rule. This allows testing of example 6 from the `footnotes.txt` spec by simply doing: `cargo test footnotes_test_6_`
nelsonjchen
added a commit
to nelsonjchen/pulldown-cmark
that referenced
this pull request
Sep 18, 2017
While the main executable can also run tests, keeping the standard `cargo test` function useful is also helpful. * * * Add end character to generated tests to work with substring only matching of tests cases. Regex test matching was removed in early 2015 in: rust-lang/rust#21458 You can only filter tests by substring. What if you wanted to run `spec_test_6`? You would run `spec_test_64` too. Adding the character, `_` to the end allows a workaround of specifying `spec_test_6_` as the match to run if you wanted to only run `spec_test_6_`. E.g. `cargo test spec_test_6_` * * * Tests are modified to generate tests with spec names in the tests Previously, all tests were generated with `spec_test_#_` as their name, even if they were not generated from `spec.txt`. The `tables.txt` spec would also generate a `spec_test_#_`. This is an issue if you wanted to test `spec_test_6_` and only wanted to run the one from `spec.txt` and not `tables.txt`'s `spec_test_6_`. While you could build the test executables and only run the specific test executable with the `spec_test_#_` you want, it's kind of annoying. This change derives the test names from the spec filename. For example, `spec.txt` will generate `spec_test_6_` while `tables.txt` and `footnotes.txt` will generate `tables_test_6_` and `footnotes_test_6_` respectively. Future optional specifications that might be added will utilize the same rule. This allows testing of example 6 from the `footnotes.txt` spec by simply doing: `cargo test footnotes_test_6_`
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The base64 support can be trivially removed (there are no in-tree users) and the regex support is a whopping 4k lines of code to maintain for a few non-critical uses in-tree. This commit migrates all current users in-tree away from regexes to custom matching code.
The most critical application affected by this migration is that the testing framework no longer considers filter arguments as regexes, but rather just a substring matching. It is expected that more featureful testing frameworks can evolve outside of the in-tree libtest version over time which can properly depend on libregex from crates.io.
[breaking-change]