Change:
PR has a tidy check for gate tests in compile-fail for all unstable lang features, helping ensure that they are actually unstable. See also issue . To be recognized as gate test for a specific feature, tests either need to follow a naming scheme or include a comment. For most of the currently present features, I could easily find matching tests in the test suite. Sadly, 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): [x] → marked by PR [x] → marked by PR [x] → marked by PR [x] → marked by PR [x] → marked by PR [x] → marked by PR [x] → marked by PR Used nowhere in the codebase. Remove? got all removed by PR [x] [x] Needs a test (or I just haven't found a suiting test to mark, even on second look): [x] → got a test by [x] → got a test by [x] → got a test by [x] → got a test by PR [x] → got a test by PR [x] → got a test by PR [x] → got a test by PR [x] → got a test by PR [x] → got a test by PR [x] → got a test by PR Don't know what to do with this one. Any ideas? [x] → removed by PR The "Needs a test" section is a good place for beginners to help out! You basically need to: you haven't already, read and in the suite for tests of that feature one of those tests over to the compile-fail suite it appropriately () and remove the line the feature from the whitelist locally ( and ) a PR! It would also be very good if you searched the 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: and (second one is not strictly required, but it never harms :D) a line with to the files that were mentioned above the feature from the whitelist locally (, since you only comments) 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!
Nice idea.
Hello folks, I'm just announcing that I'll try to do the section today
Guess I will do the already has tests section today!
wonderful! Ping me if you need any help or when you open your PR.
for example, in it's just as straight forward as 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?
When I run the tidy check, everything run ok, but the following command produces an error:
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 . 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: About your errors: don't know what the problem is. Did you do a clean clone? Running 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 :)
I think it's something to do with the . 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?
I'm not sure, maybe there is a script at ? In theory it should not interfere though. Maybe try to remove the directories?
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 gets merged.
any progress on the tests? Need some help?
any questions? Or do you want more time? Still interested to work on the tests?
I'd happily give the tests a go if we were satisfied that an extra hand might be needed. Can start bottom up to give a chance to respond and minimise the chance of overlapping work
Hello folks. and can you guys take over my task? I actually forgot about it and won't have time to finish it this weekend -- I'm sorry if I caused any trouble.
Hi, this is my first attempt to contribute to Rust. Never used Github before, so bear with me. Let me know if something doesn't make sense.
Correct me if I'm wrong, but I believe is already tested in via the header command.
no, the feature is distinct from . They both share tracking issue , but are about distinct things. is about the attribute, while is about the cfg feature. In you can see how both of the features are tested. It should be easy to make that only checks for . If you need any help, just ask!
Hello. I am working on adding compile fail test for (PR ) and (will create PR after got merged).
Is still unstable? compiles without an error after removing .
I think its partly stable, partly not. See this comment: Relevant for us is the status in and that says its still unstable. About that test file, I think the should be removed from it (and all other test files that still compile with included). There are other files that have , maybe one of them will fail to compile?
There are three files that have under , but all of them compile successfully without . Maybe a test file like the following is required to test on expression?
Does it fail when you remove the ? 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.
It does fail after removing the . I will create a PR for this.
I took the last two, and , and removed the whitelist. I've never contributed to rust before but I think this is right:

Discussion:
fn enable_trace_macros = trace_macros, fn enable_allow_internal_unstable = allow_internal_unstable, fn enable_custom_derive = custom_derive, <del> fn enable_pushpop_unsafe = pushpop_unsafe, </del> } }

(active, reflect, "1.0.0", Some(27749)), (active, unboxed_closures, "1.0.0", Some(29625)), <del> // rustc internal. (active, pushpop_unsafe, "1.2.0", None), </del> (active, allocator, "1.0.0", Some(27389)), (active, fundamental, "1.0.0", Some(29635)), (active, main, "1.0.0", Some(29634)),

// Allows #[target_feature(...)] (active, target_feature, "1.15.0", None), <del> // Allow safe suggestions for potential type conversions. (active, safe_suggestion, "1.0.0", Some(37384)), </del> // `extern "ptx-*" fn()` (active, abi_ptx, "1.15.0", None),

// Allows using items which are missing stability attributes // rustc internal (removed, unmarked_api, "1.0.0", None), <ins> (removed, pushpop_unsafe, "1.2.0", None), </ins> ); declare_features! (

// FIXME get this whitelist empty. let whitelist = vec![ <del> "abi_ptx", "simd", "safe_suggestion", "macro_reexport", </del> <ins> "abi_ptx", "simd", "macro_reexport", </ins> "more_struct_aliases", "static_recursion", "reflect", "quote", "cfg_target_has_atomic", "custom_attribute", <del> "default_type_parameter_fallback", "pushpop_unsafe", </del> <ins> "default_type_parameter_fallback", </ins> "use_extern_macros", "staged_api", "const_indexing", "unboxed_closures", "stmt_expr_attributes", "cfg_target_thread_local", "unwind_attributes",