languages and cstd support

reference/conanfile/attributes.rst

@@ -237,9 +237,9 @@ extension_properties
 The ``extensions_properties`` attribute is a dictionary intended to define and pass information from the
 recipes to the Conan extensions.
 
-At the moment, the only defined property is ``compatibility_cppstd``, that allows disabling the behavior
+At the moment, the only defined properties are ``compatibility_cppstd`` and ``compatibility_cstd``, that allows disabling the behavior
 of :ref:`the default compatibility.py extension <reference_extensions_binary_compatibility>`, that considers 
-binaries built with different ``compiler.cppstd`` values ABI-compatible among them. 
+binaries built with different ``compiler.cppstd`` and ``compiler.cstd`` values ABI-compatible among them. 
 To disable this behavior for the current package, it is possible to do it with:
 
 .. code-block:: python

reference/conanfile/attributes/binary_model.inc

@@ -331,6 +331,33 @@ For example:
             "option2": "Describe the purpose and functionality of 'option2'. ",
         }
 
+languages
+---------
+
+.. include:: ../../common/experimental_warning.inc
+
+
+From Conan 2.4, the ``conanfile.py`` recipe attribute ``languages`` can be used to define the programming languages 
+involved in this package. At the moment the ``C`` and ``C++`` languages are the possible values. For example a
+pure C package would define something as:
+
+.. code-block:: python
+
+    class ZLib(ConanFile):
+        languages = "C"
+
+
+It is possible to define more than one language, for example ``languages = "C", "C++"`` is the correct definition when
+a package is built from both C and C++ sources.
+
+Regarding ``languages`` definition, the following will happen:
+
+- If no ``languages`` is defined or ``C`` is not a declared language, ``compiler.cstd`` subsetting will be automatically removed 
+  at package ``configure()`` time (to achieve backward compatibility).
+- If ``languages`` is defined, but it doesn't contain ``C++``, ``compiler.cppstd`` and ``compiler.libcxx`` subsettings will be
+  automatically removed at package ``configure()`` time.
+
+
 info
 ----
 

reference/conanfile/methods/configure.rst

@@ -29,6 +29,12 @@ recipe to remove them so they are not used in the recipe:
         # No need to delete those settings here, they were already deleted
         pass
 
+.. note::
+
+    From Conan 2.4, the above ``configure()`` is not necessary if defined ``languages = "C"`` recipe
+    attribute (experimental).
+
+
 For packages where you want to remove every subsetting of a setting, you can use the ``rm_safe`` method
 with a wildcard:
 

reference/extensions/binary_compatibility.rst

@@ -24,8 +24,8 @@ The following would be valid syntax (but not an useful or working one, as it wil
 
 
 Conan provides a default ``compatibility.py`` implementation that implements binary compatibility for
-different ``compiler.cppstd`` values. That is, by default it assumes that binaries built with different ``cppstd``
-values (for the same compiler and compiler version) are binary compatible, and can be linked together
+different ``compiler.cppstd`` and ``compiler.cstd`` values. That is, by default it assumes that binaries built with different ``cppstd``
+and ``cstd`` values (for the same compiler and compiler version) are binary compatible, and can be linked together
 without issues.
 
 The ``compiler.cppstd`` must be defined in profiles in most C++ scenarios. If a binary for a given
@@ -35,6 +35,9 @@ It is possible to disable this behavior for any specific package, adding to the
 recipe the ``extension_properties = {"compatibility_cppstd": False}`` attribute, read the 
 :ref:`extension_properties docs<conan_conanfile_attributes_extension_properties>`.
 
+From Conan 2.4, the ``compiler.cstd`` setting is available. It will only be taken into account in the computation of
+packages ``package_id`` when their recipes explicitly declare the ``languages = "C"`` attribute.
+
 Some important rules:
 
 - The built-in ``compatibility.py`` is subject to changes in future releases. To avoid being updated

reference/extensions/profile_plugin.rst

@@ -14,6 +14,8 @@ This ``profile.py`` contains a default implementation that does:
   That allow users to let it undefined in profiles, and switch it conveniently in command line just with ``-s build_type=Debug``
 - Will check the ``compiler.cppstd`` value if defined to validate if the current compiler version has support for it. For example, if a developer
   tries to use ``-s compiler=gcc -s compiler.version=5 -s compiler.cppstd=20``, it will raise an error.
+- Even though the ``profile.py`` plugin has some provision to handle ``compiler.cstd`` checks, they are not implemented yet, so the plugin will be permissive
+  regarding definition errors, please make sure the ``compiler.cstd`` is actually supported by your compiler version.
 
 
 

reference/tools/build.rst

@@ -96,3 +96,52 @@ conan.tools.build.cppstd_flag()
 .. currentmodule:: conan.tools.build.flags
 
 .. autofunction:: cppstd_flag
+
+
+cstd
+^^^^
+
+.. include:: ../../common/experimental_warning.inc
+
+.. _conan_tools_build_check_min_cstd:
+
+conan.tools.build.check_min_cstd()
+""""""""""""""""""""""""""""""""""""
+
+.. currentmodule:: conan.tools.build.cstd
+
+.. autofunction:: check_min_cstd
+
+
+.. _conan_tools_build_check_max_cstd:
+
+conan.tools.build.check_max_cstd()
+""""""""""""""""""""""""""""""""""""
+
+.. currentmodule:: conan.tools.build.cstd
+
+.. autofunction:: check_max_cstd
+
+
+conan.tools.build.valid_min_cstd()
+""""""""""""""""""""""""""""""""""""
+
+.. currentmodule:: conan.tools.build.cstd
+
+.. autofunction:: valid_min_cstd
+
+
+conan.tools.build.valid_max_cstd()
+""""""""""""""""""""""""""""""""""""
+
+.. currentmodule:: conan.tools.build.cstd
+
+.. autofunction:: valid_max_cstd
+
+
+conan.tools.build.supported_cstd()
+""""""""""""""""""""""""""""""""""""
+
+.. currentmodule:: conan.tools.build.cstd
+
+.. autofunction:: supported_cstd