<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">This is a very good idea as documenting these limits will be very helpful for anyone who is using Clang within a MISRA coding environment, where these limits need to be known when configuring static analysis tools.</div><div class=""><br class=""><div class="">
<span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-variant-ligatures: normal; font-variant-east-asian: normal; font-variant-position: normal; line-height: normal; border-spacing: 0px; -webkit-text-decorations-in-effect: none;"><div class="">Chris Tapp, MISRA C++ Chairman</div><div class=""><br class=""></div></span></div><div><blockquote type="cite" class=""><div class="">On 1 Jan 2020, at 16:16, Mark de Wever via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">This RFC asks the community for its interest in centralizing Clang's<br class="">implementation limits and how you feel about the proposed approach.<br class=""><br class="">Abstract<br class="">========<br class=""><br class="">At the moment the implementation limits of the Clang compiler are hidden<br class="">in magic numbers in the code. These numbers sometimes differ between the<br class="">frontend and the backend. They are not always properly guarded by compiler<br class="">warnings, instead they trigger assertion failures.<br class=""><br class="">This proposal suggests a TableGen based solution to better maintain these<br class="">limits. This solution will be able to generate a header and documentation<br class="">of these limits. The latter is required by the C++ standard [implimits].<br class=""><br class=""><br class="">The problem<br class="">===========<br class=""><br class="">The proposal tries to solve 2 issues:<br class="">* Implementation limits are not always clear and duplicated in the source.<br class="">* Document C++ Implementation quantities is required by the C++ standard<br class=""> [implimits].<br class=""><br class=""><br class="">Unclear limits<br class="">--------------<br class=""><br class="">The compiler has several limitations often 'hidden' as the width of a<br class="">bit-field in a structure. This makes it hard to find these limits. Not<br class="">only for our users but also for developers. While looking at a proper<br class="">limit for the maximum width of a bit-field in the frontend I discovered<br class="">it didn't matter what the frontend picked, the backend already had a<br class="">limit [D71142]. To fix this issue the frontend and backend should have<br class="">the same limit. To avoid duplicating the value it should be in a header<br class="">available to the frontend and backend.<br class=""><br class="">Since the values are often stored in a bit-field there is no standard way<br class="">to get the maximum value. This means the limit needs a small helper<br class="">function to get the value, for example [D63975] uses<br class="">`getMaxFunctionScopeDepth()`.<br class=""><br class=""><br class="">Standard conformance<br class="">--------------------<br class=""><br class="">This is rather simple the C++ standard Annex B states:<br class=""> Because computers are finite, C++ implementations are inevitably<br class=""> limited in the size of the programs they can successfully process.<br class=""> Every implementation shall document those limitations where known.<br class=""><br class="">Currently this documentation is not available.<br class=""><br class=""><br class="">The proposed solution<br class="">=====================<br class=""><br class="">In order to solve this issue I created a proof-of-concept solution<br class="">[D72053]. It contains a new file<br class="">clang/include/clang/Basic/ImplementationQuantities.td with two TableGen<br class="">generators which create:<br class="">* An inc file with a set of constants containing the limits. This file<br class=""> $BUILD_DIR/tools/clang/include/clang/Basic/ImplementationQuantities.inc<br class=""> is included in the header<br class=""> clang/include/clang/Basic/ImplementationQuantities.h.<br class="">* The document clang/docs/ImplementationQuantities.rst<br class=""> This document documents the limits of Clang. These limits include, but<br class=""> are not limited to the quantities in [implimits].<br class=""><br class="">The quantity limit has the following possible types:<br class="">* The quantity is limited by the number of bits in a bit-field. TableGen<br class=""> generates two constants:<br class=""> * FieldNameBits, the number of bits in the bit-field.<br class=""> * MaxFieldName, the maximum value of the bit-field. (This assumes all<br class=""> bit-fields can be stored in an unsigned.)<br class="">* The quantity is limited by a value. TableGen generates one constant:<br class=""> * MaxFieldName, the maximum value of the field.<br class="">* The quantity's limit is determined by a compiler flag. TableGen<br class=""> generates one constant:<br class=""> * FieldNameDefault, the default value of the compiler flag.<br class="">* The quantity's limit cannot be expressed in a number. For example it<br class=""> depends on the stack size or available memory of the system. In this<br class=""> case TableGen generates no constant, only documentation.<br class=""><br class="">For all types documentation is generated. The documentation shows the<br class="">description of the limit and the limit implemented in Clang. If the<br class="">recommended value is not 0 it is a value described in the C++ Standard. In<br class="">this case the recommended value is shown in the documentation.<br class=""><br class=""><br class="">Questions<br class="">=========<br class=""><br class="">* If this proposal is accepted how to we make sure the document is updated<br class=""> before releasing a new version of clang?<br class="">* The compiler flag limits are also documented in the UserManual. This means<br class=""> these limits are still duplicated. Do we want to let the UserManual also be<br class=""> generated and use the values here or just keep the duplication?<br class=""><br class=""><br class="">Bikeshed<br class="">========<br class=""><br class="">I picked IQ for the namespace of the quantities since it's short and not<br class="">often used in the codebase so it's easy greppable.<br class=""><br class=""><br class="">[implimits] <a href="http://eel.is/c++draft/implimits" class="">http://eel.is/c++draft/implimits</a><br class="">[D63975] <a href="https://reviews.llvm.org/D63975" class="">https://reviews.llvm.org/D63975</a><br class="">[D71142] <a href="https://reviews.llvm.org/D71142" class="">https://reviews.llvm.org/D71142</a><br class="">[D72053] <a href="https://reviews.llvm.org/D72053" class="">https://reviews.llvm.org/D72053</a><br class=""><br class=""><br class="">Kind regards,<br class="">Mark de Wever<br class="">_______________________________________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a><br class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev<br class=""></div></div></blockquote></div><br class=""></div></body></html>