Introduce a way for entries generated by tests to be associated with their related function declaration #3509
Conversation
kayagokalp
added
compiler: ir
kayagokalp
force-pushed
the
kayagokalp/3508
branch
from
8c8c8f0 to
bd989e8
Compare
There was a problem hiding this comment.
I ended up collecting declaration ids only for test functions, so I added an optional test decl id field to FinalizedEntry. With this PR, I can retrieve DeclarationId for a specific test function from forc-test which makes it possible for later PRs to get the TyFunctionDeclaration from the declaration engine.
|
|
|
Two things:
|
|
cc @mohammadfawaz Of course, moved to PR description. I am looking for how to (and where to) add a test for this 👍 |
Excellent, thank you! Just wanted to see this description in the Description field for this PR for future reference. |
It should just work, since the metadata are supposed to be opaque to the IR in general, but having a file with test functions and the |
|
Thanks for the comments @otrho! I added a |
There was a problem hiding this comment.
Great, thanks! Thanks for adding the test.. it just makes it clear what you're adding in this change and also prevents regression in case someone makes a change that causes the metadata to drop.
It seems that this metadata is attached to the top level test function so there is no risk of it being lost since those functions are never changed (never inlined for example). This is good!
@otrho it would be nice to have a place where all the metadata types are explained along with their legal use cases, like LLVM: https://llvm.org/docs/LangRef.html#dicompileunit
…ld revert (#3490) ## Summary This PR adds `#[test(should_revert)]` tests to forc-test, enabling users to write reverting cases in their unit tests. Example: ```rust script; fn main() {} fn my_func() {} #[test(should_revert)] fn my_test_func() { my_func(); revert(0) } ``` ## Implementation Details Since #3509 is merged, this PR only adds the required section to `forc-test` so that it can detect if the given entry point's corresponding function declarations has `#[test(should_revert)]` attribute. If that is the case the passing condition is selected as `TestPassCondition::ShouldRevert` otherwise it defaults to `TestPassCondition::ShouldNotRevert`. I also added a safety check for erroneous declarations such as `#[test(foo)]`. Since we just have `should revert` tests right now, I am checking if there is an argument provided with the test attirbute. If there is none, test is considered to be `TestPassCondition::ShouldNotRevert`, tl-dr; default is non reverting tests. If there is an argument and it is `should_revert`, test is considered to be `TestPassCondition::ShouldRevert` and finally if there is an argument but it is not `should_revert` an error is produced. A simple should revert test with `revert(0)` added to unit tests as well.
…their related function declaration (#3509) closes #3508. To continue with improving in-language testing (like the linked issues), we need to have a way of getting the original function declaration for the test that we are running from `forc-test`. Currently `forc-test` only works on `FinalizedEntry`s generated by the tests and we cannot get the function declaration from the entry point. Here I am introducing an optional field to the `FinalizedEntry` for tests. If the `FinalizedEntry` is generated from a test function, corresponding `FinalizedEntry`'s declaration id is populated and can be retrieved. To pass this declaration id information I needed to preserve it in the IR generation step to do that I added a metadata for it and populate it for the test function declarations. So for test function declarations we are inserting their declaration index to the metadata. I did not insert the `DeclarationId` since it does not implement `Hash`, and we are already inserting the span for the function declaration. Since `DeclarationId` is basically the index + span, storing only the index was enough. After the IR generation before creating an entry point I construct the `DeclarationId` from index and span (which comes from the metadata) and pass that to `FinalizedEntry`. This way in the IR generation step we are not losing the declaration index + span (and thus, the declaration id) and can retrieve the test function's declaration later on. unblocks #3490. unblocks #3266.
…ld revert (#3490) ## Summary This PR adds `#[test(should_revert)]` tests to forc-test, enabling users to write reverting cases in their unit tests. Example: ```rust script; fn main() {} fn my_func() {} #[test(should_revert)] fn my_test_func() { my_func(); revert(0) } ``` ## Implementation Details Since #3509 is merged, this PR only adds the required section to `forc-test` so that it can detect if the given entry point's corresponding function declarations has `#[test(should_revert)]` attribute. If that is the case the passing condition is selected as `TestPassCondition::ShouldRevert` otherwise it defaults to `TestPassCondition::ShouldNotRevert`. I also added a safety check for erroneous declarations such as `#[test(foo)]`. Since we just have `should revert` tests right now, I am checking if there is an argument provided with the test attirbute. If there is none, test is considered to be `TestPassCondition::ShouldNotRevert`, tl-dr; default is non reverting tests. If there is an argument and it is `should_revert`, test is considered to be `TestPassCondition::ShouldRevert` and finally if there is an argument but it is not `should_revert` an error is produced. A simple should revert test with `revert(0)` added to unit tests as well.
closes #3508.
To continue with improving in-language testing (like the linked issues), we need to have a way of getting the original function declaration for the test that we are running from
forc-test. Currentlyforc-testonly works onFinalizedEntrys generated by the tests and we cannot get the function declaration from the entry point. Here I am introducing an optional field to theFinalizedEntryfor tests. If theFinalizedEntryis generated from a test function, correspondingFinalizedEntry's declaration id is populated and can be retrieved. To pass this declaration id information I needed to preserve it in the IR generation step to do that I added a metadata for it and populate it for the test function declarations. So for test function declarations we are inserting their declaration index to the metadata. I did not insert theDeclarationIdsince it does not implementHash, and we are already inserting the span for the function declaration. SinceDeclarationIdis basically the index + span, storing only the index was enough. After the IR generation before creating an entry point I construct theDeclarationIdfrom index and span (which comes from the metadata) and pass that toFinalizedEntry. This way in the IR generation step we are not losing the declaration index + span (and thus, the declaration id) and can retrieve the test function's declaration later on.unblocks #3490.
unblocks #3266.