All CLA requirements met.

Hey @AdamBucior, some of the Checks aren't successful. Is it something that I have to fix it ??

Hey @AdamBucior, some of the Checks aren't successful. Is it something that I have to fix it ??

Looks like some tests which are testing whether sto* are throwing correct exceptions are discarding the return value. If you click details on one of the "Build and Test" checks, then click "View more details on Azure Pipelines", you will see a console with information on what % of tests passed. If you click on that you will see a more detailed panel with every test that failed. I might seem like a lot but that's because they are different configurations of the same tests. Unfortunately some of them are libcxx tests which means that they are not part of this repo and need to be skipped. But before you go to fix all of them I would advise you to wait for a maintainer to make sure that we want to make sto* functions nodiscard.

Hey @AdamBucior, some of the Checks aren't successful. Is it something that I have to fix it ??

Looks like some tests which are testing whether sto* are throwing correct exceptions are discarding the return value. If you click details on one of the "Build and Test" checks, then click "View more details on Azure Pipelines", you will see a console with information on what % of tests passed. If you click on that you will see a more detailed panel with every test that failed. I might seem like a lot but that's because they are different configurations of the same tests. Unfortunately some of them are libcxx tests which means that they are not part of this repo and need to be skipped. But before you go to fix all of them I would advise you to wait for a maintainer to make sure that we want to make sto* functions nodiscard.

Ok , I will Wait for the maintainer to reply then . Thanks for the quick reply

Hey @sam20908 , I recently made one more commit to this PR . Pls can you review it and tell me if it's OK 😊

Besides unwrapped lines as the CI pointed out, the rest looks good.

Besides unwrapped lines as the CI pointed out, the rest looks good.

Thanks for that, I still couldn't figure out the code format validation. A little help would make my day.

Besides unwrapped lines as the CI pointed out, the rest looks good.

Thanks for that, I still couldn't figure out the code format validation. A little help would make my day.

Output from https://dev.azure.com/vclibs/STL/_build/results?buildId=7568&view=logs&jobId=ce9c9df7-f6fa-59cf-0934-3339753bfc56&j=ce9c9df7-f6fa-59cf-0934-3339753bfc56&t=3711bd6d-b1de-5d1c-63bc-c5c83dcf4759

-    _NODISCARD string_type transform(const _Elem* _First, const _Elem* _Last) const { // transform [_First, _Last) to key string
+    _NODISCARD string_type transform(
+        const _Elem* _First, const _Elem* _Last) const { // transform [_First, _Last) to key string
         return do_transform(_First, _Last);
     }

The - line of the line of code you currently have (that is unwrapped), and the +s are the lines that would be formatted, in this case it means the parameters are supposed to be moved to the next line to avoid long lines.

Same with this:

-    _NODISCARD virtual int __CLR_OR_THIS_CALL do_compare(const _Elem* _First1, const _Elem* _Last1, const _Elem* _First2,
+    _NODISCARD virtual int __CLR_OR_THIS_CALL do_compare(const _Elem* _First1, const _Elem* _Last1,
+        const _Elem* _First2,
         const _Elem* _Last2) const { // compare [_First1, _Last1) to [_First2, _Last2)
         _Adl_verify_range(_First1, _Last1);
         _Adl_verify_range(_First2, _Last2);

Hopefully, that helps you a bit!

Thanks @sam20908 . Well I have Passed the code format test but other one still failed. I believe this is not in my hands for the other one or I have to fix them?? If yes, can you please tell me how??

Thanks @sam20908 . Well I have Passed the code format test but other one still failed. I believe this is not in my hands for the other one or I have to fix them?? If yes, can you please tell me how??

You can view the tests that have failed in https://dev.azure.com/vclibs/STL/_build/results?buildId=7577&view=ms.vss-test-web.build-test-results-tab and there were warnings that turned into errors because the values were discarded.

For example, one of the test.compile.pass.cpp has a stack trace message of the following (truncated just for example):

test.compile.pass.cpp

C:\a\1\s\tests\std\tests\VSO_0000000_instantiate_iterators_misc\test.compile.pass.cpp(816): error C2220: the following warning is treated as an error

C:\a\1\s\tests\std\tests\VSO_0000000_instantiate_iterators_misc\test.compile.pass.cpp(816): warning C4834: discarding return value of function with 'nodiscard' attribute

and line number of 816 in test.compile.pass.cpp, which is in tests/std/tests/VSO_0000000_instantiate_iterators_misc points to the following code:

There are other locations that needs to be fixed according to the stack trace message 👍

When I created my _NODISCARD PR and encountered the same errors, the maintainers said that we can cast to (void) to avoid the warning, which I think would be applicable here as well.

This may seem a lot, but you can ask questions 😄 .

I also note that there are some merge conflicts: the content of tests/libcxx/expected_results.txt and [...]/skipped_tests.txt has changed since you forked this branch and git can't figure out how to apply your changes cleanly. You'll need merge origin/main into your branch and resolve the resulting conflicts.

I also note that there are some merge conflicts: the content of tests/libcxx/expected_results.txt and [...]/skipped_tests.txt has changed since you forked this branch and git can't figure out how to apply your changes cleanly. You'll need merge origin/main into your branch and resolve the resulting conflicts.

If I will merge the origin/main into the current branch , would it will delete those lines I have written?

It won't delete the lines you've written - instead, it'll add "merge conflict markers" which you'll need to manually edit. See "How Conflicts Are Presented" in the git merge documentation: https://git-scm.com/docs/git-merge#_how_conflicts_are_presented

The documentation mentions:

An alternative style can be used by setting the "merge.conflictStyle" configuration variable to "diff3".

I highly recommend this setting (which shows the original code, how your branch changed it, and how "their" branch being merged changed it) - it's so useful, I can't believe it isn't the default. To enable this, run one of the following:

• Enabled for just the STL repo (must be within the repo when you run this): git config merge.conflictstyle diff3
• Enabled globally for your git installation: git config --global merge.conflictstyle diff3

Without this setting, you can still resolve merge conflicts, but you'll only be shown "your" code and "their" code, not the original code, which I find way more confusing.

Thanks for adding more occurrences of the world's best attribute and helping find bugs in user code! 🎉 🪲 🔍 😸