[PATCH] D56819: Document toolchain update policy

JF Bastien via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jan 17 16:17:44 PST 2019


jfb marked 3 inline comments as done.
jfb added inline comments.


================
Comment at: docs/DeveloperPolicy.rst:677
+  * Update the :doc:`coding standards<CodingStandards>` to explicitly allow the
+    new features we've now unlocked.
+
----------------
hubert.reinterpretcast wrote:
> jfb wrote:
> > hubert.reinterpretcast wrote:
> > > The suggested wording implies that consensus for updating version requirements for some generic toolchains is consensus to update the set of language features to "whatever falls out of the support provided by those toolchain versions". I think that this step in the proposed process should instead be to identify the features that are now available by the minimum versions of the popular toolchains, and begin a discussion on what features we will start using.
> > An earlier point says:
> > 
> > > * An RFC is sent to the `llvm-dev mailing list <http://lists.llvm.org/mailman/listinfo/llvm-dev>`_
> > >
> > >    - Detail upsides of the version increase (e.g. allow LLVM to use newer C++
> > >      language or library features; avoid miscompiles in particular compiler
> > >      versions, etc).
> > >    - Detail downsides on important platforms (e.g. Ubuntu LTS status).
> > 
> > If you think that wording is unclear, please provide concrete alternatives.
> Motivations for a version increase should not be confused with the results of a version increase. If a non-motivating feature is "unlocked" by the version increase, for example, that feature would not necessarily have been mentioned prior to reaching this step. I do not see why such a feature then automatically becomes "fair game".
> 
> An explicit discussion of the language support necessary allows users of compilers other than the "popular toolchains" to evaluate the requirements and communicate with their vendors.
That's a pretty adversarial reading of the policy... I've clarified the wording to avoid that pitfall.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56819/new/

https://reviews.llvm.org/D56819





More information about the llvm-commits mailing list