The README contains a block property that's set, but the semantics on the @property are default to strong instead of copy, so the block will never be copied off the stack onto the heap, unless I'm missing something. Either change the @property ownership to copy or call copy manually when assigning the block.

Having a comment like this in an Objective-C source file makes ROADAttributesCodeGenerator crash. The asterisk appears to trigger the bug. I've tested with version 1.3.6.

//*rect = CGRectZero;

Stacktrace:

2017-06-23 15:58:19.475 ROADAttributesCodeGenerator[89599:25827246] *** Terminating app due to uncaught exception 'NSRangeException', reason: '-[__NSCFString replaceCharactersInRange:withString:]: Range or index out of bounds'
*** First throw call stack:
(
	0   CoreFoundation                      0x00007fffaf5ab37b __exceptionPreprocess + 171
	1   libobjc.A.dylib                     0x00007fffc439f48d objc_exception_throw + 48
	2   CoreFoundation                      0x00007fffaf629c3d +[NSException raise:format:] + 205
	3   CoreFoundation                      0x00007fffaf5db3a5 mutateError + 261
	4   ROADAttributesCodeGenerator         0x000000010521ffd5 +[RFSourceCodePreprocessor removeMultiLineComments:] + 165
	5   ROADAttributesCodeGenerator         0x000000010521f864 +[RFSourceCodePreprocessor removeComments:] + 84
	6   ROADAttributesCodeGenerator         0x000000010521da82 +[RFSourceCodePreprocessor prepareCodeForParsingWithImports:useDefines:] + 258
	7   ROADAttributesCodeGenerator         0x000000010521a329 +[RFHeaderSectionParser parseSourceCode:forFileName:intoClass:intoProtocol:skipImports:useDefines:] + 409
	8   ROADAttributesCodeGenerator         0x000000010522b230 +[RFSourceFilesProcessor gatherClassInfoFromFile:intoClass:intoProtocol:skipImports:useDefines:] + 352
	9   ROADAttributesCodeGenerator         0x000000010522ae18 +[RFSourceFilesProcessor gatherClassesInfoFromSourceCodePath:intoClass:intoProtocol:useDefines:excludePaths:] + 2120
	10  ROADAttributesCodeGenerator         0x000000010522a424 +[RFSourceFilesProcessor generateAttributeFactoriesIntoPath:fromSourceCodePaths:useDefines:excludePaths:] + 580
	11  ROADAttributesCodeGenerator         0x00000001052129db main + 363
	12  libdyld.dylib                       0x00007fffc4c84235 start + 1
)
libc++abi.dylib: terminating with uncaught exception of type NSException

2014-07-09 11:16:15.850 ROADAttributesCodeGenerator[4122:507] * Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '* -[NSPlaceholderMutableString initWithString:]: nil argument'
*** First throw call stack:
(
0 CoreFoundation 0x00007fff8a4f225c __exceptionPreprocess + 172
1 libobjc.A.dylib 0x00007fff88144e75 objc_exception_throw + 43
2 CoreFoundation 0x00007fff8a4f210c +[NSException raise:format:] + 204
3 Foundation 0x00007fff8f347347 -[NSPlaceholderMutableString initWithString:] + 90
4 Foundation 0x00007fff8f3472d4 +[NSString stringWithString:] + 43
5 ROADAttributesCodeGenerator 0x000000010fad7cb4 +[RFMethodParser onlyParameterNamesFrom:] + 68
6 ROADAttributesCodeGenerator 0x000000010fad7bfc +[RFMethodParser extractMethodParametersFromBuffer:] + 188
7 ROADAttributesCodeGenerator 0x000000010fad78ec +[RFMethodParser parseFrom:forKeyWord:] + 284
8 ROADAttributesCodeGenerator 0x000000010fad6a57 +[RFHeaderSectionParser processMethodWithCodeParseState:andKeyword:] + 103
9 ROADAttributesCodeGenerator 0x000000010fad5d42 +[RFHeaderSectionParser processKeyWord:withCodeParseState:] + 722
10 ROADAttributesCodeGenerator 0x000000010fad56d6 +[RFHeaderSectionParser parseSourceCode:forFileName:intoClass:intoProtocol:skipImports:useDefines:] + 934
11 ROADAttributesCodeGenerator 0x000000010fae6290 +[RFSourceFilesProcessor gatherClassInfoFromFile:intoClass:intoProtocol:skipImports:useDefines:] + 352
12 ROADAttributesCodeGenerator 0x000000010fae5e78 +[RFSourceFilesProcessor gatherClassesInfoFromSourceCodePath:intoClass:intoProtocol:useDefines:excludePaths:] + 2120
13 ROADAttributesCodeGenerator 0x000000010fae5484 +[RFSourceFilesProcessor generateAttributeFactoriesIntoPath:fromSourceCodePaths:useDefines:excludePaths:] + 580
14 ROADAttributesCodeGenerator 0x000000010facdcbb main + 363
15 libdyld.dylib 0x00007fff8dcc15fd start + 1
)
libc++abi.dylib: terminating with uncaught exception of type NSException

Is there anything preventing us from supporting OSX ?
If not could you update podspec to include that platform?

Sample of extension proposal: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1370.pdf

It will allow to remove duplicated attribute generation build phases from pods and internal sub-projects.

@nikita-leonov : That is a common situation for generated headers:

import <Spark/SparkServices.h>

import "SFLogger.h"

import <Foundation/Foundation.h>

import "SFService.h"

import <Spark/SparkServices.h>

import "SFLogger.h"

import <Foundation/Foundation.h>

import "SFService.h"

import <Spark/SparkServices.h>

import "SFLogger.h"

import <Foundation/Foundation.h>

import "SFService.h"

import "SFServiceProvider.h"

import <objc/runtime.h>

import <Spark/SparkReflection.h>

I Unit Tests
We need to measure code coverage.
Add unit test for SFEncodingMapper to test all the possible type encoding conversion options.
SFIvarInfoTest.m
We need to add unit test for ivarsOfClass method.
SFMethodInfoTest.m
We need to add tests for all methods and properties.

II Code

SparkReflection.h
Order imports alphabetically.
SFEncodingMapper.h
I think SFTypeEncoder or SFTypeNameConverter or SFTypeEncodingConverter better reflect what this class does.
SFEncodingMapper class is used internally by SparkReflection component, so we are not importing it's header in SparkReflection.h. Do you think it might make sense to also put such classes into separate folder, say "Private"? This will make it easier to understand this component for its users.
SFEncodingMapper.m
There should be one blank line between the #import of class own header and the rest of the #import-s.
What does the "k" prefix mean, for instance in kSFEncodingMapFile? It means that this is a constant? What is the full list of possible prefixes?
SFIvarInfo.h
Is there a reason why variableTypeName is marked as assign instead of copy?
All the properties of this class should be marked as readonly in the header file and then overridden as readwrite in implementation file. See Use Class Extensions to Hide Private Information.
There is no need to explicitly specify __unsafe_unretained for Class parameter it will be implicitly implied. And since we do not explicitly specify ownership qualifiers for other types of parameters, I vote for removing it here too.
I think it worth documenting that any instance variables declared by superclasses are not included for ivarsOfClass method.
We need to document what will happen if a user passes a name of unexisting property to ivarNamed:ofClass: method.
SFIvarInfo.m
Wrong order of imports: own header import is the first followed by system framework imports, all other imports are separated by a newline and grouped together.
We should avoid to create local variable without assignment in the same line. We need to move SFIvarInfo *descriptor; inside for loop: SFIvarInfo *descriptor = [self infoFromIvar:ivarList[index]];
It is better to create variable closer to the place where we use this variable. In infoFromIvar method, encoding variable is not used on the next line from where it is created. I suggest moving "info.variableTypeName = …" one line higher.
There should be symbolic constant for the next literal @"@". Or better move the next line "![encoding hasPrefix:@"@"];" to a separate method in SFEncodingMapper class where we have the rest of similar constants defined.
I think it would be better to pass Class to infoFromIvar the same way as we did in methodInfo:forClass: for consistency and to avoid code duplication.
SFMethodInfo.h
All the properties of this class should be marked as readonly in the header file and then overridden as readwrite in implementation file. See Use Class Extensions to Hide Private Information.
I think we need to document that any instance methods implemented by superclasses are not included for methodsOfClass method.
We need to document what will happen if a user passes a name of unexacting method to instanceMethodNamed or classMethodNamed method.
SFMethodInfo.m
We should avoid using the same variable for different purposes. In methodsOfClass method it is better to create 2 variables (instanceMethods and classMethods) instead of one methods variable. The same applies for numberOfMethods.
aMethod can be marked as const in instanceMethodNamed or classMethodNamed methods.
What rule do we use for "a" prefix? For instance why don't we call aMethod just method?
methodInfoList method – we should not manually format method params, we should write everything in one line and take advantage of Xcode wrapping.
methodInfoList method – excessive blank line at the beginning.
The name of mapArgumentTypeEncodingForMethod sounds unusual to me. The "map" prefix implies that this is a procedure w/o return value that does some mapping. I would recommend to rename this method to something like argumentTypesForMethod or argumentTypeNamesForMethod.
Why do we need description method for SFMethodInfo but not for SFIvarInfo?
It might be better to populate argumentTypes lazily – when a user requests a particular type with typeOfArgumentAtIndex method.
We should prefer to declare private properties in implementation file instead of working with raw ivars, for instance argumentTypes.
SFPropertyInfo.h
Naming consistency: SFPropertyInfo has attributeClassName property, and SFIvarInfo has variableTypeName property. It would be better to use either word "type" or "class" in both cases for consistency. Similar situation with isPrimitive and isObject properties.
I think it is better to explicitly specify assign for properties.
SFPropertyInfo.m
attributeValue variable in property:containsSpecifier: method can be marked as const.
We should create symbolic constants for all the literals like "D", "W", etc.
NSCharacterSet+EncodingCharacterSet.h
isPrefixInString is never used with shouldTrimWhitespace set to YES, I think we should just eliminate this parameter.
I think we should eliminate NSCharacterSet+EncodingCharacterSet category and put all it's functionality in SFEncodingMapper class as private methods. It looks like this category causes us more inconvenience than benefit. Instead of a bunch of public methods that return NSCharacterSet we should have a bunch of private methods that convert from a particular encoding type (object, value, pointer, etc) or return nil in case of failure. Benefits of such approach: 1) it will improve cohesion 2) it will reduce code duplicated code snippets in nameFromTypeEncoding method 2) the related constants from SFEncodingMapper and EncodingCharacterSet will sit close instead of in separate files.
Consider the possibility to add another plist file with type encoding character set string as a key and type name format string as a value, similar to what we have in SFEncoding.plist.
NSObject+MemberVariableReflection.h
Methods documentation is misleading, I think it is copy-paste issue. For instance the next method "+ (NSArray *)ivars;" is documented like this "Returns all info objects corresponding to the instance variable of the given name", but there is no given name – this method does not get any parameter.
Adding category to NSObject class can be dangerous. We should at least and SF prefixes to the method names, especially for short method names like ivars.
Naming consistency: MemberVariableReflection has ivarNamed: method and MethodReflection has method classMethodForName. We should either use "For" suffix or use "-ed" ending but we should stay consistent across classes.

@sunnycows : Implementation Reflection assumes that user may need properties declared on the level of the queried class. Inherited properties are not taken into account.

Add support for #define so we can specify -def_file argument for attribute generator and with defines that will be preprocessed with attribute generator
Idea by @krzysztofzablocki

It allows to reduce attribute generation time and exclude third-party files that Attribute Generator can't parse because some reasons.

Implement performance efficient way to get declarations of attributes for complete class hierarchy, properties, ivars and methods.
Real-life example is to find some attribute like DependencyInjection declared like following RF_ATTRIBUTE(DependencyInjection, name=@"something") for class all over the hierarchy to process if further in dependency container method inject,

@nikita-leonov: As a user that runs generator with --verbose flag, I should see an output from a generator with a list of a files processed with each of important steps of parsing for each of the steps. Something like following:
File: EPAppDelegate.m
Operations:
Exclude one-line comments from parsing [v]
Exclude multi-line comments from parsing [v]
Parse list of properties [v]
Parse list of ivars [v]
Parse list of methods [v]

generator should also scan @implementation blocks in .m otherwise stuff like private / subclassing /IBActions methods won't be supported, requirement to pre-declare those methods is long gone in objc2.

SparkAttributesSupport.h
I think it would be better to rename this header file to match the component name: SparkAttribute.h.
Fix comment in the second line of this file – it should say SparkAttributesSupport.h instead of Header.h.
Add documentation for SF_ATTRIBUTE, to explain why do we need this empty macro, document parameters, etc.
Will it be better to move SF_ATTRIBUTE declaration to NSObject+SFAttributes.h?
NSObject+SFAttributes.h
There is no need to import Foundation.h since w have it in pre-compiled header file.
There is no need to import SFPropertyInfo.h, SFMethodInfo.h and SFIvarInfo.h in this header – we should move them into implementation file.
We should not import each individual header from another component, we should import the main header file of another component. So instead of us having 3 imports of SFPropertyInfo.h, SFMethodInfo.h and SFIvarInfo.h, we should instead import SparkReflection.h (and also put this import into pre-compiled header).
Adding category to NSObject can be dangerous, we should add "SF" prefix to each method name.
We need to document the category and every interface method.
Is there a reason why we need a bunch of lastAttributeFor… methods. I mean we do not have a bunch of firstAttributeFor… methods, why do we need special case methods for the last attribute? I also have not found these lastAttributeFor… methods used anywhere.
I would also consider the need for a bunch of hasAttributesFor… methods, since we already have a bunch of attributesFor… that return nil or empty array if no attributes were found.
NSObject+SFAttributes.m
In modern Objective-C there is no need to declare methods in class extension before you define those methods. So you can safely remove the next block @interface NSObject (). But you still need to add "SF" prefixes even to these methods.
I would suggest adding at least one more #pragma mark to separate private and public methods.
We need to add comments to assert statements. It is probably better to use NSAssert for consistency. This assertion should be documented as pre-condition for this method in the interface file.
Instead of if (attributeCreatorsDictionary == nil) use if (!attributeCreatorsDictionary) for consistency.
We can safely remove if (attributeCreatorsDictionary == nil) {return nil;} since the second if statement covert both cases.
We should create instance variables closer to the place where we use them. I think it would be better to create result variable after the next line [attributeCreatorValueInvocation invoke];.
It is surprising that "using of weak references decreases performance 40 times". So you have tried __weak, have you also tried insafeunretained?
We should not split several sentences of comments among several lines of code, rather we should have a comment paragraph that explains several lines of code below. So do not document CFBridgingRetain separately, put this comment line together with the comment for getReturnValue.
I think that the name result is inappropriate for this variable, since you do not return this variable.
I would suggest removing the next if statement: if ([attributes count] == 1 && [[attributes lastObject] isKindOfClass:requiredClassOfAttribute], because if attributes count is 1 but the object is not of the required type, we just add more work.
NSObject+SFAttributesInternal.h
I think that this category should not really exist. Lets see what we have in this category: 4 attributesFactories… methods with dummy implementation and 2 utility methods marked as (internal API). I think we should get rid of this category and create 1 protocol and 1 utility class even put utility methods as private methods of some of the existing class.
Why do we call this class internal if there will be subclasses from other components?
We need to document the category and every interface method.

@nikita-leonov : ROADConfigurator moved to resources, not Attribute Generator. This one still need to be done.

It is not easy and leads to unexpected consequences if a new developer adds a library dependency with CocoaPods. Usual patterns do not work here and newcomer waste a lot of time gussing what happens. Post install hook should be fixed.

Scenarios like following currently works well, but not verified in test cases:
@"very
long
string"

When I have some class A with RFSerializable attribute and this class inherits from NSObject - everything works just fine.
But when I decided to inherit class A from another class B and move a property with RFSerializable attribute from A to B - it has stopped working.

2014-08-07 04:07:08.166 ROADAttributesCodeGenerator[15314:168379] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[__NSSetM addObject:]: object cannot be nil'
*** First throw call stack:
(
    0   CoreFoundation                      0x00007fff874c7f3c __exceptionPreprocess + 172
    1   libobjc.A.dylib                     0x00007fff84f9f6de objc_exception_throw + 43
    2   CoreFoundation                      0x00007fff873d5579 -[__NSSetM addObject:] + 329
    3   ROADAttributesCodeGenerator         0x00000001047ad75d +[RFHeaderSectionParser processImportWithCodeParseState:] + 797
    4   ROADAttributesCodeGenerator         0x00000001047abde4 +[RFHeaderSectionParser processKeyWord:withCodeParseState:] + 884
    5   ROADAttributesCodeGenerator         0x00000001047ab6d6 +[RFHeaderSectionParser parseSourceCode:forFileName:intoClass:intoProtocol:skipImports:useDefines:] + 934
    6   ROADAttributesCodeGenerator         0x00000001047bc290 +[RFSourceFilesProcessor gatherClassInfoFromFile:intoClass:intoProtocol:skipImports:useDefines:] + 352
    7   ROADAttributesCodeGenerator         0x00000001047bbe78 +[RFSourceFilesProcessor gatherClassesInfoFromSourceCodePath:intoClass:intoProtocol:useDefines:excludePaths:] + 2120
    8   ROADAttributesCodeGenerator         0x00000001047bb484 +[RFSourceFilesProcessor generateAttributeFactoriesIntoPath:fromSourceCodePaths:useDefines:excludePaths:] + 580
    9   ROADAttributesCodeGenerator         0x00000001047a3cbb main + 363
    10  libdyld.dylib                       0x00007fff8eb655c9 start + 1
    11  ???                                 0x0000000000000004 0x0 + 4
)
libc++abi.dylib: terminating with uncaught exception of type NSException
Start source code processing
Source code directories:(
    "/Volumes/Macintosh HD/Projects/Swift-Rest-Client/objc/Maidan/Maidan",
    "/Volumes/Macintosh HD/Projects/Swift-Rest-Client/objc/Maidan/Pods"
)
Directory for generated code:/Volumes/Macintosh HD/Projects/Swift-Rest-Client/objc/Maidan/Maidan/ROADGeneratedAttributes/

/Users/alikiran/Library/Developer/Xcode/DerivedData/Maidan-bethsgplpbfneuenmkmjxejzpssz/Build/Intermediates/Maidan.build/Debug-iphonesimulator/Maidan.build/Script-C93A8D95F92D42658BD1D96D.sh: line 2: 15314 Abort trap: 6           "${PODS_ROOT}/libObjCAttr/tools/binaries/ROADAttributesCodeGenerator" -src="${SRCROOT}/${TARGET_NAME}" -src="${PODS_ROOT}" -dst="${SRCROOT}/${TARGET_NAME}/ROADGeneratedAttributes/"
Command /bin/sh failed with exit code 134

if i remove -src="${PODS_ROOT}" parameters it works nicely

@nikita-leonov Moved from ROAD iOS Framework

Hey,
New version adds scanning pods for generation, that makes my whole xcode hang unfortunately, it works fine if I remove pods scanning.

Did you notice that?