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

Removal of the lang feature gate tests whitelist #39059

Closed
20 tasks done
est31 opened this issue Jan 14, 2017 · 24 comments
Closed
20 tasks done

Removal of the lang feature gate tests whitelist #39059

est31 opened this issue Jan 14, 2017 · 24 comments
Labels
E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. E-help-wanted Call for participation: Help is requested to fix this issue.

Comments

@est31
Copy link
Member

est31 commented Jan 14, 2017

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!

est31 added a commit to est31/rust that referenced this issue Jan 15, 2017
This removes the safe_suggestion feature from feature_gate.rs.
It was added in commit 164f010
and then removed again in commit c11fe55 .

As the removal was in the same PR rust-lang#38099 as the addition, we don't move it to
the "removed" section.

Removes an element from the whitelist of non gate tested unstable lang features (issue rust-lang#39059).
est31 added a commit to est31/rust that referenced this issue Jan 15, 2017
This marks the pushpop_unsafe feature as removed inside the feature_gate.
It was added in commit 1829fa5 and then
removed again in commit d399098 .
Seems that the second commit forgot to mark it as removed in feature_gate.rs.

This enables us to remove another element from the whitelist of non gate
tested unstable lang features (issue rust-lang#39059).
bors added a commit that referenced this issue Jan 15, 2017
Mark safe_suggestion and pushpop_unsafe as removed in feature_gate.rs

This removes two features from feature_gate.rs: `safe_suggestion` and `pushpop_unsafe`. Both had been removed in other places already, but were forgotten to be removed from feature_gate.rs.

* `safe_suggestion` was added in commit 164f010 and then removed again in commit c11fe55 both in the same PR #38099.

* `pushpop_unsafe` was added in commit 1829fa5 and removed again in commit d399098

Removes two elements from the whitelist of non gate tested unstable lang features (issue #39059).
bors added a commit that referenced this issue Jan 16, 2017
Mark safe_suggestion and pushpop_unsafe as removed in feature_gate.rs

This removes two features from feature_gate.rs: `safe_suggestion` and `pushpop_unsafe`. Both had been removed in other places already, but were forgotten to be removed from feature_gate.rs.

* `safe_suggestion` was added in commit 164f010 and then removed again in commit c11fe55 both in the same PR #38099.

* `pushpop_unsafe` was added in commit 1829fa5 and removed again in commit d399098

Removes two elements from the whitelist of non gate tested unstable lang features (issue #39059).
@retep998 retep998 added the E-help-wanted Call for participation: Help is requested to fix this issue. label Jan 17, 2017
@brson
Copy link
Contributor

brson commented Jan 18, 2017

Nice idea.

@brson brson added the E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. label Jan 18, 2017
@alanhoff
Copy link

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

@cseale
Copy link
Contributor

cseale commented Jan 22, 2017

Guess I will do the already has tests section today!

@est31
Copy link
Member Author

est31 commented Jan 22, 2017

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

@cseale
Copy link
Contributor

cseale commented Jan 22, 2017

@est31 for example, in struct-path-self-feature-gate.rs it's just as straight forward as

// gate-test-more_struct_aliases
struct S;

trait Tr {
    type A;
}

fn f<T: Tr<A = S>>() {
    let _ = T::A {};
    //~^ ERROR `Self` and associated types in struct expressions and patterns are unstable
}

impl S {
    fn f() {
        let _ = Self {};
        //~^ ERROR `Self` and associated types in struct expressions and patterns are unstable
    }
}

fn main() {}

Where in the codebase is the build actually looking at these comments to detect if they should run or not? I'm used to annotations or functions declaring test groups in code (junit in java or jasmine in javascript). I am new to rust, is this a rust standard?

@cseale
Copy link
Contributor

cseale commented Jan 22, 2017

@est31 When I run the tidy check, everything run ok, but the following command produces an error:

$ ./x.py test src/test/compile-fail --test-args feature-gate-more_struct_aliases

Finished debug [unoptimized] target(s) in 0.0 secs
Synchronizing submodule url for 'src/compiler-rt'
Synchronizing submodule url for 'src/jemalloc'
Synchronizing submodule url for 'src/liblibc'
Synchronizing submodule url for 'src/llvm'
Synchronizing submodule url for 'src/rt/hoedown'
Synchronizing submodule url for 'src/rust-installer'
HEAD is now at a8fc4c1 Merge pull request #28 from xen0n/preprocessor-firefighting
HEAD is now at e058ca6 Change how the default zone is found
HEAD is now at e49e9bb Auto merge of #478 - jackpot51:patch-1, r=alexcrichton
HEAD is now at ceb177e Merge pull request #60 from japaric/gh38406
HEAD is now at a3736a0 Merge pull request #6 from intelfx/patch-1
HEAD is now at 4f99485 Merge pull request #54 from brson/docdir
Building stage0 std artifacts (x86_64-apple-darwin -> x86_64-apple-darwin)
warning: /Library/Developer/CommandLineTools/usr/bin/ranlib: file: /Users/user/projects/rust/build/x86_64-apple-darwin/stage0-std/x86_64-apple-darwin/release/build/compiler_builtins-0511dd5445a3a209/out/libcompiler-rt.a(addtf3.o) has no symbols
warning: /Library/Developer/CommandLineTools/usr/bin/ranlib: file: /Users/user/projects/rust/build/x86_64-apple-darwin/stage0-std/x86_64-apple-darwin/release/build/compiler_builtins-0511dd5445a3a209/out/libcompiler-rt.a(divtf3.o) has no symbols
warning: /Library/Developer/CommandLineTools/usr/bin/ranlib: file: /Users/user/projects/rust/build/x86_64-apple-darwin/stage0-std/x86_64-apple-darwin/release/build/compiler_builtins-0511dd5445a3a209/out/libcompiler-rt.a(multf3.o) has no symbols
warning: /Library/Developer/CommandLineTools/usr/bin/ranlib: file: /Users/user/projects/rust/build/x86_64-apple-darwin/stage0-std/x86_64-apple-darwin/release/build/compiler_builtins-0511dd5445a3a209/out/libcompiler-rt.a(powitf2.o) has no symbols
warning: /Library/Developer/CommandLineTools/usr/bin/ranlib: file: /Users/user/projects/rust/build/x86_64-apple-darwin/stage0-std/x86_64-apple-darwin/release/build/compiler_builtins-0511dd5445a3a209/out/libcompiler-rt.a(subtf3.o) has no symbols
warning: /Library/Developer/CommandLineTools/usr/bin/ranlib: file: /Users/user/projects/rust/build/x86_64-apple-darwin/stage0-std/x86_64-apple-darwin/release/build/compiler_builtins-0511dd5445a3a209/out/libcompiler-rt.a(trampoline_setup.o) has no symbols
    Finished release [optimized] target(s) in 0.0 secs
Copying stage0 std from stage0 (x86_64-apple-darwin -> x86_64-apple-darwin / x86_64-apple-darwin)
Building stage0 test artifacts (x86_64-apple-darwin -> x86_64-apple-darwin)
    Finished release [optimized] target(s) in 0.0 secs
Copying stage0 test from stage0 (x86_64-apple-darwin -> x86_64-apple-darwin / x86_64-apple-darwin)
Building stage0 compiler artifacts (x86_64-apple-darwin -> x86_64-apple-darwin)
warning: ../rustllvm/RustWrapper.cpp:151:3: warning: default label in switch which covers all enumeration values [-Wcovered-switch-default]
warning:   default:
warning:   ^
warning: ../rustllvm/RustWrapper.cpp:1235:3: warning: default label in switch which covers all enumeration values [-Wcovered-switch-default]
warning:   default:
warning:   ^
warning: ../rustllvm/RustWrapper.cpp:1268:3: warning: default label in switch which covers all enumeration values [-Wcovered-switch-default]
warning:   default:
warning:   ^
warning: ../rustllvm/RustWrapper.cpp:1282:3: warning: default label in switch which covers all enumeration values [-Wcovered-switch-default]
warning:   default:
warning:   ^
warning: 4 warnings generated.
    Finished release [optimized] target(s) in 0.2 secs
Copying stage0 rustc from stage0 (x86_64-apple-darwin -> x86_64-apple-darwin / x86_64-apple-darwin)
Copying stage1 compiler (x86_64-apple-darwin)
thread 'main' panicked at 'failed to copy `/Users/user/projects/rust/build/x86_64-apple-darwin/stage0-sysroot/lib/rustlib/x86_64-apple-darwin/lib/libflate-89345601b107c0b9.dylib` to `/Users/user/projects/rust/build/x86_64-apple-darwin/stage1/lib/libflate-89345601b107c0b9.dylib`: Permission denied (os error 13)', src/bootstrap/util.rs:53
note: Run with `RUST_BACKTRACE=1` for a backtrace.

@est31
Copy link
Member Author

est31 commented Jan 22, 2017

@cseale

Where in the codebase is the build actually looking at these comments to detect if they should run or not? I am new to rust, is this a rust standard?

No, this notation is actually internal to the rust compiler codebase. Its not used in normal rust codebases. The standard way of doing tests in rust is to use an attribute. The compiler however has special needs, and part of the information usually passed via attributes (like whether it should panic or not) is encoded in the path (run-pass vs compile-fail etc.) the test is inside. Also, the checking is done in an executable separate from the compiler, which doesn't have access to the parser. Doing it via comments makes this check simpler to implement. The specific check is implemented here: https://github.com/rust-lang/rust/blob/master/src/tools/tidy/src/features.rs#L118-L164

About your errors: don't know what the problem is. Did you do a clean clone? Running ./x.py test should not be very important for work in the "already has tests" section though, so if the tidy check is successful, you can open a PR :)

@cseale
Copy link
Contributor

cseale commented Jan 22, 2017

@est31 I think it's something to do with the sudo make install. I ran the build from source script when I first cloned rust, but I think it is causing issues when I try and run other build commands? How do I uninstall rust?

@est31
Copy link
Member Author

est31 commented Jan 22, 2017

@cseale I'm not sure, maybe there is a script at /usr/local/lib/rustlib/uninstall.sh? In theory it should not interfere though. Maybe try to remove the build/stage* directories?

cseale added a commit to cseale/rust that referenced this issue Jan 22, 2017
Removal of the lang feature gate tests whitelist rust-lang#39059

r? @est31
bors added a commit that referenced this issue Jan 22, 2017
[Gate Tests] - marking feature tests

Removal of the lang feature gate tests whitelist #39059

r? @est31
@est31
Copy link
Member Author

est31 commented Jan 22, 2017

Okay, found two further gate tests, so I moved "quote" and "macro_reexport" to the section of features that need only marking. Note that their marking won't be effective until #39247 gets merged.

@est31
Copy link
Member Author

est31 commented Feb 26, 2017

@danobi no, the cfg_target_thread_local feature is distinct from thread_local. They both share tracking issue #29594, but are about distinct things. thread_local is about the #[thread_local] attribute, while cfg_target_thread_local is about the target_thread_local cfg feature. In src/test/run-pass/auxiliary/thread-local-extern-static.rs you can see how both of the features are tested. It should be easy to make that only checks for target_thread_local. If you need any help, just ask!

frewsxcv added a commit to frewsxcv/rust that referenced this issue Feb 28, 2017
Add compile fail test for unboxed_closures feature

Hello, this is my first contribution to rust.
Issue rust-lang#39059.
frewsxcv added a commit to frewsxcv/rust that referenced this issue Feb 28, 2017
Add compile fail test for unboxed_closures feature

Hello, this is my first contribution to rust.
Issue rust-lang#39059.
eddyb added a commit to eddyb/rust that referenced this issue Feb 28, 2017
Add compile fail test for unboxed_closures feature

Hello, this is my first contribution to rust.
Issue rust-lang#39059.
frewsxcv added a commit to frewsxcv/rust that referenced this issue Feb 28, 2017
Add compile fail test for unboxed_closures feature

Hello, this is my first contribution to rust.
Issue rust-lang#39059.
steveklabnik added a commit to steveklabnik/rust that referenced this issue Feb 28, 2017
…arget-has-atomic, r=alexcrichton

Add compile test for cfg_target_has_atomic

Issue rust-lang#39059.
I am concerned about whether the test is excessive.
steveklabnik added a commit to steveklabnik/rust that referenced this issue Feb 28, 2017
…arget-has-atomic, r=alexcrichton

Add compile test for cfg_target_has_atomic

Issue rust-lang#39059.
I am concerned about whether the test is excessive.
@topecongiro
Copy link
Contributor

Hello. I am working on adding compile fail test for cfg_target_has_atomic(PR #40150) and abi_ptx(will create PR after #40150 got merged).

GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this issue Mar 2, 2017
…tx, r=petrochenkov

Add compile fail test for abi_ptx

Issue rust-lang#39059.
@topecongiro
Copy link
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)].

@est31
Copy link
Member Author

est31 commented Mar 3, 2017

@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?

@topecongiro
Copy link
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;
}

bors added a commit that referenced this issue Mar 3, 2017
Add compile fail test for SIMD

This completes the missing SIMD test task for issue #39059.
@est31
Copy link
Member Author

est31 commented Mar 4, 2017

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.

@topecongiro
Copy link
Contributor

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

bors added a commit that referenced this issue Mar 5, 2017
…=petrochenkov

Add compile fail test for stmt_expr_attributes

Adds a missing feature gate test for `stmt_expr_attributes`. Issue #39059.
@gibfahn
Copy link
Contributor

gibfahn commented Mar 5, 2017

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

gibfahn added a commit to gibfahn/rust that referenced this issue Mar 5, 2017
Test copied from src/test/codegen/extern-functions.rs.

Refs: rust-lang#39059
gibfahn added a commit to gibfahn/rust that referenced this issue Mar 5, 2017
Test copied from src/test/run-pass/thread-local-extern-static.rs.

Refs: rust-lang#39059
@bors bors closed this as completed in 7c88d9e Mar 9, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. E-help-wanted Call for participation: Help is requested to fix this issue.
Projects
None yet
Development

No branches or pull requests

10 participants