Add #[rustc_test_entrypoint_marker]#158854
Conversation
|
Some changes occurred in compiler/rustc_hir/src/attrs Some changes occurred in compiler/rustc_attr_parsing Some changes occurred in compiler/rustc_passes/src/check_attr.rs |
|
|
26da690 to
1e795a9
Compare
This comment has been minimized.
This comment has been minimized.
|
(this might take me a few days to get to, should have time to take a look on friday) |
…nathanBrouwer Add `#[rustc_test_entrypoint_marker]` r? @JonathanBrouwer cc: @Nadrieril @N1ark @aDotInTheVoid Some context: a bunch of tooling around rustc likes to find entry points. This is easy for `main`, it's a lang item. But tests aren't as easy. There is already a similar marker for the data structure associated with tests, but if you want to do for example dynamic analysis, you want just the defid of the function you can call to start the tests. This is that marker. There's a test using a rustc driver that the attr indeed shows up and marks the test functions. @Nadrieril and @N1ark asked for this kind of behavior. I talked to @aDotInTheVoid about whether we should do things like this where we cannot really guarantee the stability or even use it inside rustc. The thing is, we don't provide staboility guarantees, it's just a useful little thing to have for as long as its there and it doesn't bother anyone either. It's up to tool authors to deal with breakage we may introduce.
…uwer Rollup of 7 pull requests Successful merges: - #157690 (codegen_ssa: pack small const aggregates into immediate stores) - #159005 (Use `as_lang_item` instead of repeatedly matching) - #156735 (Move NativeLib::filename to the rmeta-link archive member) - #158732 (Apply MCP 1003 and move diagnostics.rs into its own module) - #158854 (Add `#[rustc_test_entrypoint_marker]`) - #158965 (Add codegen test for Result is_ok unwrap) - #159050 (assert only opaques with sub unified hidden infer are non-rigid)
|
💔 I suspect this PR failed tests as part of a rollup After fixing the problem, consider running a try job for the failed job before re-approving. Link to failure: #159068 (comment) |
|
This pull request was unapproved. This PR was contained in a rollup (#159068), which was unapproved. |
| path.to_string(), | ||
| ]; | ||
| rustc_driver::catch_fatal_errors(|| -> interface::Result<()> { | ||
| rustc_driver::run_compiler(&args, &mut TestAttr { expected_tests }); |
There was a problem hiding this comment.
I wonder if we can run this twice. There's a test that ensures that running interface::run_compiler twice works, but that's a different entrypoint
There was a problem hiding this comment.
That's the only thing I can see, otherwise the test looks like the other rustc_driver tests
r? @JonathanBrouwer
cc: @Nadrieril @N1ark @aDotInTheVoid
Some context: a bunch of tooling around rustc likes to find entry points. This is easy for
main, it's a lang item. But tests aren't as easy. There is already a similar marker for the data structure associated with tests, but if you want to do for example dynamic analysis, you want just the defid of the function you can call to start the tests. This is that marker. There's a test using a rustc driver that the attr indeed shows up and marks the test functions.@Nadrieril and @N1ark asked for this kind of behavior. I talked to @aDotInTheVoid about whether we should do things like this where we cannot really guarantee the stability or even use it inside rustc. The thing is, we don't provide staboility guarantees, it's just a useful little thing to have for as long as its there and it doesn't bother anyone either. It's up to tool authors to deal with breakage we may introduce.