ceedling 0.28.2 → 0.28.3

data/vendor/unity/docs/ThrowTheSwitchCodingStandard.md

@@ -1,4 +1,4 @@
-# ThrowTheSwitch.org Coding Standard
+# ThrowTheSwitch.org Coding Standard
 
 Hi. Welcome to the coding standard for ThrowTheSwitch.org. For the most part,
 we try to follow these standards to unify our contributors' code into a cohesive
@@ -11,7 +11,7 @@ and we'll try to be polite when we notice yours.
 
 ## Why Have A Coding Standard?
 
-Being consistent makes code easier to understand. We've made an attempt to keep
+Being consistent makes code easier to understand. We've tried to keep
 our standard simple because we also believe that we can only expect someone to
 follow something that is understandable. Please do your best.
 
@@ -51,11 +51,11 @@ much as they can, but give the user the power to override it when it's wrong.
 
 Let's talk about naming things. Programming is all about naming things. We name
 files, functions, variables, and so much more. While we're not always going to
-find the best name for something, we actually put quite a bit of effort into
+find the best name for something, we actually put a bit of effort into
 finding *What Something WANTS to be Called*™.
 
-When naming things, we more or less follow this hierarchy, the first being the
-most important to us (but we do all four whenever possible):
+When naming things, we follow this hierarchy, the first being the
+most important to us (but we do all four when possible):
 1. Readable
 2. Descriptive
 3. Consistent
@@ -74,7 +74,7 @@ abbreviations (sticking to ones we feel are common).
 We like descriptive names for things, especially functions and variables.
 Finding the right name for something is an important endeavor. You might notice
 from poking around our code that this often results in names that are a little
-longer than the average. Guilty. We're okay with a tiny bit more typing if it
+longer than the average. Guilty. We're okay with a bit more typing if it
 means our code is easier to understand.
 
 There are two exceptions to this rule that we also stick to as religiously as
@@ -82,8 +82,7 @@ possible:
 
 First, while we realize hungarian notation (and similar systems for encoding
 type information into variable names) is providing a more descriptive name, we
-feel that (for the average developer) it takes away from readability and
-therefore is to be avoided.
+feel that (for the average developer) it takes away from readability and is to be avoided.
 
 Second, loop counters and other local throw-away variables often have a purpose
 which is obvious. There's no need, therefore, to get carried away with complex
@@ -128,7 +127,7 @@ the same. It will only hurt a little. We promise.
 #### Whitespace
 
 Our C-style is to use spaces and to use 4 of them per indent level. It's a nice
-power-of-2 number that looks decent on a wide screen. We have no more reason
+power-of-2 number that looks decent on a wide-screen. We have no more reason
 than that. We break that rule when we have lines that wrap (macros or function
 arguments or whatnot). When that happens, we like to indent further to line
 things up in nice tidy columns.
@@ -200,7 +199,7 @@ that happens, we like to indent further to line things up in nice tidy columns.
 
 ## Documentation
 
-Egad. Really? We use markdown and we like pdf files because they can be made to
+Egad. Really? We use mark down and we like pdf files because they can be made to
 look nice while still being portable. Good enough?
 
 

data/vendor/unity/docs/UnityAssertionsReference.md

@@ -80,7 +80,7 @@ marked as an optional parameter because some assertions only need a single
 "actual" parameter (e.g. null check).
 "Size/count" refers to string lengths, number of array elements, etc.
 
-Many of Unity's assertions are apparent duplications in that the same data type
+Many of Unity's assertions are clear duplications in that the same data type
 is handled by several assertions. The differences among these are in how failure
 messages are presented. For instance, a `_HEX` variant of an assertion prints
 the expected and actual values of that assertion formatted as hexadecimal.
@@ -104,6 +104,15 @@ becomes messageified like thus...
 
     TEST_ASSERT_X_MESSAGE( {modifiers}, {expected}, actual, {size/count}, message )
 
+Notes:
+- The `_MESSAGE` variants intentionally do not support `printf` style formatting 
+  since many embedded projects don't support or avoid `printf` for various reasons.
+  It is possible to use `sprintf` before the assertion to assemble a complex fail
+  message, if necessary.
+- If you want to output a counter value within an assertion fail message (e.g. from 
+  a loop) , building up an array of results and then using one of the `_ARRAY` 
+  assertions (see below) might be a handy alternative to `sprintf`.
+
 
 #### TEST_ASSERT_X_ARRAY Variants
 
@@ -694,7 +703,7 @@ point value.
 
 So what happens when it's zero? Zero - even more than other floating point
 values - can be represented many different ways. It doesn't matter if you have
-0 x 20or 0 x 263.It's still zero, right? Luckily, if you
+0 x 20 or 0 x 263.It's still zero, right? Luckily, if you
 subtract these values from each other, they will always produce a difference of
 zero, which will still fall between 0 plus or minus a delta of 0. So it still
 works!

data/vendor/unity/docs/UnityConfigurationGuide.md

@@ -1,4 +1,4 @@
-# Unity Configuration Guide
+# Unity Configuration Guide
 
 ## C Standards, Compilers and Microcontrollers
 
@@ -19,7 +19,7 @@ definitions. A couple are macros with arguments. They live inside the
 unity_internals.h header file. We don't necessarily recommend opening that file
 unless you really need to. That file is proof that a cross-platform library is
 challenging to build. From a more positive perspective, it is also proof that a
-great deal of complexity can be centralized primarily to one place in order to
+great deal of complexity can be centralized primarily to one place to
 provide a more consistent and simple experience elsewhere.
 
 
@@ -58,7 +58,7 @@ sizes. It starts off by trying to do it automatically.
 ##### `UNITY_EXCLUDE_STDINT_H`
 
 The first thing that Unity does to guess your types is check `stdint.h`.
-This file includes defines like `UINT_MAX` that Unity can make use of to
+This file includes defines like `UINT_MAX` that Unity can use to
 learn a lot about your system. It's possible you don't want it to do this
 (um. why not?) or (more likely) it's possible that your system doesn't
 support `stdint.h`. If that's the case, you're going to want to define this.
@@ -79,18 +79,7 @@ _Example:_
         #define UNITY_EXCLUDE_LIMITS_H
 
 
-##### `UNITY_EXCLUDE_SIZEOF`
-
-The third and final attempt to guess your types is to use the `sizeof()`
-operator. Even if the first two options don't work, this one covers most cases.
-There _is_ a rare compiler or two out there that doesn't support sizeof() in the
-preprocessing stage, though. For these, you have the ability to disable this
-feature as well.
-
-_Example:_
-        #define UNITY_EXCLUDE_SIZEOF
-
-If you've disabled all of the automatic options above, you're going to have to
+If you've disabled both of the automatic options above, you're going to have to
 do the configuration yourself. Don't worry. Even this isn't too bad... there are
 just a handful of defines that you are going to specify if you don't like the
 defaults.
@@ -127,7 +116,7 @@ _Example:_
         #define UNITY_POINTER_WIDTH 64
 
 
-##### `UNITY_INCLUDE_64`
+##### `UNITY_SUPPORT_64`
 
 Unity will automatically include 64-bit support if it auto-detects it, or if
 your `int`, `long`, or pointer widths are greater than 32-bits. Define this to
@@ -136,7 +125,7 @@ can be a significant size and speed impact to enabling 64-bit support on small
 targets, so don't define it if you don't need it.
 
 _Example:_
-        #define UNITY_INCLUDE_64
+        #define UNITY_SUPPORT_64
 
 
 ### Floating Point Types
@@ -170,24 +159,20 @@ _Example:_
         #define UNITY_INCLUDE_DOUBLE
 
 
-##### `UNITY_FLOAT_VERBOSE`
-
-##### `UNITY_DOUBLE_VERBOSE`
+##### `UNITY_EXCLUDE_FLOAT_PRINT`
 
 Unity aims for as small of a footprint as possible and avoids most standard
-library calls (some embedded platforms don't have a standard library!). Because
+library calls (some embedded platforms don’t have a standard library!). Because
 of this, its routines for printing integer values are minimalist and hand-coded.
-To keep Unity universal, though, we chose to _not_ develop our own floating
-point print routines. Instead, the display of floating point values during a
-failure are optional. By default, Unity will not print the actual results of
-floating point assertion failure. So a failed assertion will produce a message
-like `"Values Not Within Delta"`. If you would like verbose failure messages for
-floating point assertions, use these options to give more explicit failure
-messages (e.g. `"Expected 4.56 Was 4.68"`). Note that this feature requires the
-use of `sprintf` so might not be desirable in all cases.
+Therefore, the display of floating point values during a failure are optional.
+By default, Unity will print the actual results of floating point assertion
+failure (e.g. ”Expected 4.56 Was 4.68”). To not include this extra support, you
+can use this define to instead respond to a failed assertion with a message like
+”Values Not Within Delta”. If you would like verbose failure messages for floating
+point assertions, use these options to give more explicit failure messages.
 
 _Example:_
-        #define UNITY_DOUBLE_VERBOSE
+        #define UNITY_EXCLUDE_FLOAT_PRINT
 
 
 ##### `UNITY_FLOAT_TYPE`
@@ -237,7 +222,7 @@ In addition to the options listed above, there are a number of other options
 which will come in handy to customize Unity's behavior for your specific
 toolchain. It is possible that you may not need to touch any of these... but
 certain platforms, particularly those running in simulators, may need to jump
-through extra hoops to operate properly. These macros will help in those
+through extra hoops to run properly. These macros will help in those
 situations.
 
 
@@ -263,7 +248,8 @@ _Example:_
 Say you are forced to run your test suite on an embedded processor with no
 `stdout` option. You decide to route your test result output to a custom serial
 `RS232_putc()` function you wrote like thus:
-
+        #include "RS232_header.h"
+        ...
         #define UNITY_OUTPUT_CHAR(a) RS232_putc(a)
         #define UNITY_OUTPUT_START() RS232_config(115200,1,8,0)
         #define UNITY_OUTPUT_FLUSH() RS232_flush()
@@ -271,31 +257,35 @@ Say you are forced to run your test suite on an embedded processor with no
 
 _Note:_
 `UNITY_OUTPUT_FLUSH()` can be set to the standard out flush function simply by
-specifying `UNITY_USE_FLUSH_STDOUT`. No other defines are required. If you
-specify a custom flush function instead with `UNITY_OUTPUT_FLUSH` directly, it
-will declare an instance of your function by default. If you want to disable
-this behavior, add `UNITY_OMIT_OUTPUT_FLUSH_HEADER_DECLARATION`.
-
-
-##### `UNITY_SUPPORT_WEAK`
-
-For some targets, Unity can make the otherwise required `setUp()` and
-`tearDown()` functions optional. This is a nice convenience for test writers
-since `setUp` and `tearDown` don't often actually _do_ anything. If you're using
-gcc or clang, this option is automatically defined for you. Other compilers can
-also support this behavior, if they support a C feature called weak functions. A
-weak function is a function that is compiled into your executable _unless_ a
-non-weak version of the same function is defined elsewhere. If a non-weak
-version is found, the weak version is ignored as if it never existed. If your
-compiler supports this feature, you can let Unity know by defining
-`UNITY_SUPPORT_WEAK` as the function attributes that would need to be applied to
-identify a function as weak. If your compiler lacks support for weak functions,
-you will always need to define `setUp` and `tearDown` functions (though they can
-be and often will be just empty). The most common options for this feature are:
+specifying `UNITY_USE_FLUSH_STDOUT`. No other defines are required.
+
+
+##### `UNITY_WEAK_ATTRIBUTE`
+
+##### `UNITY_WEAK_PRAGMA`
+
+##### `UNITY_NO_WEAK`
+
+For some targets, Unity can make the otherwise required setUp() and tearDown()
+functions optional. This is a nice convenience for test writers since setUp and
+tearDown don’t often actually do anything. If you’re using gcc or clang, this
+option is automatically defined for you. Other compilers can also support this
+behavior, if they support a C feature called weak functions. A weak function is
+a function that is compiled into your executable unless a non-weak version of
+the same function is defined elsewhere. If a non-weak version is found, the weak
+version is ignored as if it never existed. If your compiler supports this feature,
+you can let Unity know by defining UNITY_WEAK_ATTRIBUTE or UNITY_WEAK_PRAGMA as
+the function attributes that would need to be applied to identify a function as
+weak. If your compiler lacks support for weak functions, you will always need to
+define setUp and tearDown functions (though they can be and often will be just
+empty). You can also force Unity to NOT use weak functions by defining
+UNITY_NO_WEAK. The most common options for this feature are:
 
 _Example:_
-        #define UNITY_SUPPORT_WEAK weak
-        #define UNITY_SUPPORT_WEAK __attribute__((weak))
+        #define UNITY_WEAK_ATTRIBUTE weak
+        #define UNITY_WEAK_ATTRIBUTE __attribute__((weak))
+        #define UNITY_WEAK_PRAGMA
+        #define UNITY_NO_WEAK
 
 
 ##### `UNITY_PTR_ATTRIBUTE`
@@ -309,6 +299,51 @@ _Example:_
         #define UNITY_PTR_ATTRIBUTE near
 
 
+##### `UNITY_PRINT_EOL`
+
+By default, Unity outputs \n at the end of each line of output. This is easy
+to parse by the scripts, by Ceedling, etc, but it might not be ideal for YOUR
+system. Feel free to override this and to make it whatever you wish.
+
+_Example:_
+        #define UNITY_PRINT_EOL { UNITY_OUTPUT_CHAR('\r'); UNITY_OUTPUT_CHAR('\n') }
+
+
+
+##### `UNITY_EXCLUDE_DETAILS`
+
+This is an option for if you absolutely must squeeze every byte of memory out of
+your system. Unity stores a set of internal scratchpads which are used to pass
+extra detail information around. It's used by systems like CMock in order to
+report which function or argument flagged an error. If you're not using CMock and
+you're not using these details for other things, then you can exclude them.
+
+_Example:_
+        #define UNITY_EXCLUDE_DETAILS
+
+
+
+##### `UNITY_EXCLUDE_SETJMP`
+
+If your embedded system doesn't support the standard library setjmp, you can
+exclude Unity's reliance on this by using this define. This dropped dependence
+comes at a price, though. You will be unable to use custom helper functions for
+your tests, and you will be unable to use tools like CMock. Very likely, if your
+compiler doesn't support setjmp, you wouldn't have had the memory space for those
+things anyway, though... so this option exists for those situations.
+
+_Example:_
+        #define UNITY_EXCLUDE_SETJMP
+
+##### `UNITY_OUTPUT_COLOR`
+
+If you want to add color using ANSI escape codes you can use this define.
+t
+_Example:_
+        #define UNITY_OUTPUT_COLOR
+
+
+
 ## Getting Into The Guts
 
 There will be cases where the options above aren't quite going to get everything

data/vendor/unity/docs/UnityGettingStartedGuide.md

@@ -11,7 +11,7 @@ functional. The core Unity test framework is three files: a single C file and a
 couple header files. These team up to provide functions and macros to make
 testing easier.
 
-Unity was designed to be cross platform. It works hard to stick with C standards
+Unity was designed to be cross-platform. It works hard to stick with C standards
 while still providing support for the many embedded C compilers that bend the
 rules. Unity has been used with many compilers, including GCC, IAR, Clang,
 Green Hills, Microchip, and MS Visual Studio. It's not much work to get it to
@@ -100,10 +100,11 @@ find setUp or tearDown when it links, you'll know you need to at least include
 an empty function for these.
 
 The majority of the file will be a series of test functions. Test functions
-follow the convention of starting with the word "test" or "spec". You don't HAVE
+follow the convention of starting with the word "test_" or "spec_". You don't HAVE
 to name them this way, but it makes it clear what functions are tests for other
-developers.  Test functions take no arguments and return nothing. All test
-accounting is handled internally in Unity.
+developers.  Also, the automated scripts that come with Unity or Ceedling will default
+to looking for test functions to be prefixed this way. Test functions take no arguments 
+and return nothing. All test accounting is handled internally in Unity.
 
 Finally, at the bottom of your test file, you will write a `main()` function.
 This function will call `UNITY_BEGIN()`, then `RUN_TEST` for each test, and
@@ -148,7 +149,7 @@ int main(void) {
 }
 ```
 
-It's possible that you will require more customization than this, eventually.
+It's possible that you will need more customization than this, eventually.
 For that sort of thing, you're going to want to look at the configuration guide.
 This should be enough to get you going, though.
 

data/vendor/unity/docs/UnityHelperScriptsGuide.md

@@ -3,7 +3,7 @@
 ## With a Little Help From Our Friends
 
 Sometimes what it takes to be a really efficient C programmer is a little non-C.
-The Unity project includes a couple Ruby scripts for making your life just a tad
+The Unity project includes a couple of Ruby scripts for making your life just a tad
 easier. They are completely optional. If you choose to use them, you'll need a
 copy of Ruby, of course. Just install whatever the latest version is, and it is
 likely to work. You can find Ruby at [ruby-lang.org](https://ruby-labg.org/).
@@ -105,7 +105,7 @@ UnityTestRunnerGenerator.new.run(testfile, runner_name, options)
 
 If you have multiple files to generate in a build script (such as a Rakefile),
 you might want to instantiate a generator object with your options and call it
-to generate each runner thereafter. Like thus:
+to generate each runner afterwards. Like thus:
 
 ```Ruby
 gen = UnityTestRunnerGenerator.new(options)
@@ -124,7 +124,7 @@ demonstrates using a Ruby hash.
 
 ##### `:includes`
 
-This option specifies an array of file names to be ?#include?'d at the top of
+This option specifies an array of file names to be `#include`'d at the top of
 your runner C file. You might use it to reference custom types or anything else
 universally needed in your generated runners.
 
@@ -133,11 +133,23 @@ universally needed in your generated runners.
 
 Define this option with C code to be executed _before any_ test cases are run.
 
+Alternatively, if your C compiler supports weak symbols, you can leave this
+option unset and instead provide a `void suiteSetUp(void)` function in your test
+suite.  The linker will look for this symbol and fall back to a Unity-provided
+stub if it is not found.
+
 
 ##### `:suite_teardown`
 
-Define this option with C code to be executed ?after all?test cases have
-finished.
+Define this option with C code to be executed _after all_ test cases have
+finished.  An integer variable `num_failures` is available for diagnostics.
+The code should end with a `return` statement; the value returned will become
+the exit code of `main`.  You can normally just return `num_failures`.
+
+Alternatively, if your C compiler supports weak symbols, you can leave this
+option unset and instead provide a `int suiteTearDown(int num_failures)`
+function in your test suite.  The linker will look for this symbol and fall
+back to a Unity-provided stub if it is not found.
 
 
 ##### `:enforce_strict_ordering`
@@ -147,6 +159,12 @@ CMock (see CMock documentation). This generates extra variables required for
 everything to run smoothly. If you provide the same YAML to the generator as
 used in CMock's configuration, you've already configured the generator properly.
 
+##### `:mock_prefix` and `:mock_suffix`
+
+Unity automatically generates calls to Init, Verify and Destroy for every file
+included in the main test file that starts with the given mock prefix and ends
+with the given mock suffix, file extension not included. By default, Unity
+assumes a `Mock` prefix and no suffix.
 
 ##### `:plugins`
 

data/vendor/unity/examples/unity_config.h

@@ -236,4 +236,12 @@
 /* #define UNITY_PTR_ATTRIBUTE __attribute__((far)) */
 /* #define UNITY_PTR_ATTRIBUTE near */
 
+/* Print execution time of each test when executed in verbose mode
+ *
+ * Example:
+ *
+ * TEST - PASS (10 ms)
+ */
+/* #define UNITY_INCLUDE_EXEC_TIME */
+
 #endif /* UNITY_CONFIG_H */

data/vendor/unity/extras/fixture/src/unity_fixture.c

@@ -93,6 +93,8 @@ void UnityTestRunner(unityfunction* setup,
         UnityMalloc_StartTest();
         UnityPointer_Init();
 
+        UNITY_EXEC_TIME_START();
+
         if (TEST_PROTECT())
         {
             setup();
@@ -418,6 +420,8 @@ void UnityConcludeFixtureTest(void)
         if (UnityFixture.Verbose)
         {
             UnityPrint(" PASS");
+            UNITY_EXEC_TIME_STOP();
+            UNITY_PRINT_EXEC_TIME();
             UNITY_PRINT_EOL();
         }
     }

data/vendor/unity/extras/fixture/src/unity_fixture.h

@@ -78,6 +78,6 @@ int UnityMain(int argc, const char* argv[], void (*runAllTests)(void));
 #endif
 
 /* You must compile with malloc replacement, as defined in unity_fixture_malloc_overrides.h */
-void UnityMalloc_MakeMallocFailAfterCount(int count);
+void UnityMalloc_MakeMallocFailAfterCount(int countdown);
 
 #endif /* UNITY_FIXTURE_H_ */