Skip to content

Removal of the lang feature gate tests whitelist #39059

Description

@est31

PR #38914 has added a tidy check for gate tests in compile-fail for all unstable lang features, helping ensure that they are actually unstable. See also issue #22820.

To be recognized as gate test for a specific feature, tests either need to follow a naming scheme feature-gate-NAME-OF-THE-FEAT.rs or include a // gate-test-NAME-OF-THE-FEAT comment. For most of the currently present features, I could easily find matching tests in the test suite. Sadly, there is still a whitelist of currently 20 features for which it tolerates that it can't detect any gate tests.

The goal is to eliminate that whitelist, which this issue is tracking.

The features on the whitelist fall into the following categories:

Has already tests, they just need to be marked (found this out only on a second look):

Used nowhere in the codebase. Remove?

got all removed by PR #39071

  • safe_suggestion
  • pushpop_unsafe

Needs a test (or I just haven't found a suiting test to mark, even on second look):

Don't know what to do with this one. Any ideas?

The "Needs a test" section is a good place for beginners to help out!

You basically need to:

  1. if you haven't already, read CONTRIBUTING.md and COMPILER_TESTS.md
  2. search in the src/test/run-pass suite for tests of that feature
  3. copy one of those tests over to the compile-fail suite
  4. rename it appropriately (feature-gate-FEAT-NAME.rs) and remove the #![feature(...)] line
  5. remove the feature from the whitelist
  6. test locally (./x.py test src/tools/tidy and ./x.py test src/test/compile-fail --test-args feature-gate-FEAT-NAME)
  7. submit a PR!

It would also be very good if you searched the compile-fail testsuite for already existing gate tests and mark those instead. A good place to look is the PR that introduced that feature, they usually also add gate tests.

You can help out in the "Has already tests" section as well. Here, contributing is even easier!

You'll need to:

  1. read CONTRIBUTING.md and COMPILER_TESTS.md (second one is not strictly required, but it never harms :D)
  2. add a line with // gate-test-FEATURE_NAME to the files that were mentioned above
  3. remove the feature from the whitelist
  4. test locally (./x.py test src/tools/tidy, since you only added comments)
  5. submit a PR!

If you need help, ask in this thread. Also, its best to prevent duplicate work, so it would be nice if you could announce that you work on some of the items. Thanks in advance!

Activity

  1. added 2 commits that reference this issue on Jan 15, 2017
  2. added
    E-help-wantedCall for participation: Help is requested to fix this issue.
    on Jan 17, 2017
  3. brson commented on Jan 18, 2017

    @brson
    Contributor

    Nice idea.

  4. added
    E-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
    on Jan 18, 2017
  5. alanhoff commented on Jan 21, 2017

    @alanhoff

    Hello folks, I'm just announcing that I'll try to do the Need a test section today

  6. cseale commented on Jan 22, 2017

    @cseale
    Contributor

    Guess I will do the already has tests section today!

  7. est31 commented on Jan 22, 2017

    @est31
    MemberAuthor

    @alanhoff @cseale wonderful! Ping me if you need any help or when you open your PR.

  8. 54 remaining items

  9. added a commit that references this issue on Mar 2, 2017
  10. topecongiro commented on Mar 3, 2017

    @topecongiro
    Contributor

    Is stmt_expr_attributes still unstable? src/rust/run-pass/cfg_stmt_expr.rs compiles without an error after removing #![feature(stmt_expr_attributes)].

  11. est31 commented on Mar 3, 2017

    @est31
    MemberAuthor

    @topecongiro I think its partly stable, partly not. See this comment: #15701 (comment)

    Relevant for us is the status in src/libsyntax/feature_gate.rs and that says its still unstable. About that test file, I think the #![feature(...)] should be removed from it (and all other test files that still compile with #![feature(...)] included). There are other files that have stmt_expr_attributes, maybe one of them will fail to compile?

  12. topecongiro commented on Mar 3, 2017

    @topecongiro
    Contributor

    @est31 There are three files that have stmt_expr_attribues under src/test/run-pass, but all of them compile successfully without #![feature(...)].

    Maybe a test file like the following is required to test stmt_expr_attributes on expression?

    #![feature(stmt_expr_attributes)]
    fn main() {
        let x = #[allow(dead_code)] 8;
    }
  13. added a commit that references this issue on Mar 3, 2017
  14. est31 commented on Mar 4, 2017

    @est31
    MemberAuthor

    Maybe a test file like the following is required to test stmt_expr_attributes on expression?

    Does it fail when you remove the #![feature(...)]? Then it can be used as gate test. If it doesn't fail then its probably a bug of the code that checks the attributes.

  15. topecongiro commented on Mar 4, 2017

    @topecongiro
    Contributor

    It does fail after removing the #![feature(...)]. I will create a PR for this.

  16. added a commit that references this issue on Mar 5, 2017
  17. gibfahn commented on Mar 5, 2017

    @gibfahn
    Contributor

    I took the last two, unwind_attributes and cfg_target_thread_local, and removed the whitelist. I've never contributed to rust before but I think this is right: #40279

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    E-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.E-help-wantedCall for participation: Help is requested to fix this issue.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions