[clang] 5e10cd7 - Remove known-stale projects from the open projects page

Aaron Ballman via cfe-commits cfe-commits at lists.llvm.org
Mon Apr 24 05:59:05 PDT 2023


Author: Aaron Ballman
Date: 2023-04-24T08:58:56-04:00
New Revision: 5e10cd78780891ee6777ff6268cd727f1785d373

URL: https://github.com/llvm/llvm-project/commit/5e10cd78780891ee6777ff6268cd727f1785d373
DIFF: https://github.com/llvm/llvm-project/commit/5e10cd78780891ee6777ff6268cd727f1785d373.diff

LOG: Remove known-stale projects from the open projects page

This removes or modifies:

Undefined behavior checking -- we've got UBSan and it's well-known
enough that we don't need to call it out specifically as a need.

Improve target support -- this is largely already complete.

Use clang libraries to extend Ragel with a JIT -- this wasn't really
related to improving Clang.

C++1y feature work -- now talks about C++20, C++2b, and C2x instead.

Universal driver -- the bug report linked to by the UniversalDriver
web page has been closed since 2017.

XML representation of the AST -- we removed this functionality in 2013
and replaced it with a JSON representation a few years later. That is a
best-effort project.

Added: 
    

Modified: 
    clang/www/OpenProjects.html

Removed: 
    clang/www/UniversalDriver.html


################################################################################
diff  --git a/clang/www/OpenProjects.html b/clang/www/OpenProjects.html
index 07d7140643df..fb3bd1b5edec 100755
--- a/clang/www/OpenProjects.html
+++ b/clang/www/OpenProjects.html
@@ -22,16 +22,6 @@ <h1>Open Clang Projects</h1>
 or to verify that one of these isn't already completed.</p>
 
 <ul>
-<li><b>Undefined behavior checking</b>:
-Improve and extend the runtime checks for undefined behavior which CodeGen
-inserts for the various <tt>-fsanitize=</tt> modes. A lot of issues can already
-be caught, but there is more to do here.</li>
-
-<li><b>Improve target support</b>: The current target interfaces are heavily
-stubbed out and need to be implemented fully.  See the FIXME's in TargetInfo.
-Additionally, the actual target implementations (instances of TargetInfoImpl)
-also need to be completed.</li>
-
 <li><b>Implement an tool to generate code documentation</b>: Clang's
 library-based design allows it to be used by a variety of tools that reason
 about source code. One great application of Clang would be to build an
@@ -56,12 +46,6 @@ <h1>Open Clang Projects</h1>
 href="https://llvm.org/docs/CodingStandards.html#use-early-exits-and-continue-to-simplify-code">the LLVM coding
 standards</a>.</li>
 
-<li><b>Use clang libraries to extend Ragel with a JIT</b>: <a
-href="https://www.colm.net/open-source/ragel/">Ragel</a> is a state
-machine compiler that lets you embed C code into state machines and generate
-C code.  It would be relatively easy to turn this into a JIT compiler using
-LLVM.</li>
-
 <li><b>Self-testing using clang</b>: There are several neat ways to
 improve the quality of clang by self-testing. Some examples:
 <ul>
@@ -77,30 +61,17 @@ <h1>Open Clang Projects</h1>
 </ul>
 </li>
 
-<li><b>Continue work on C++1y support</b>:
-  C++98 and C++11 are feature-complete, but there are still several C++1y features to
-  implement.  Please see the <a href="cxx_status.html">C++ status report
-  page</a> to find out what is missing.</li>
+<li><b>Continue work on C++20, C++2b, and C2x support</b>:
+  There are still several C++20 features to complete, and work has begun on
+  supporting the latest language standards. Please see the
+  <a href="cxx_status.html">C++ status report page</a> to find out what is
+  missing.</li>
 
 <li><b>StringRef'ize APIs</b>: A thankless but incredibly useful project is
 StringRef'izing (converting to use <tt>llvm::StringRef</tt> instead of <tt>const
 char *</tt> or <tt>std::string</tt>) various clang interfaces. This generally
 simplifies the code and makes it more efficient.</li>
 
-<li><b>Universal Driver</b>: Clang is inherently a cross compiler. We would like
-to define a new model for cross compilation which provides a great user
-experience -- it should be easy to cross compile applications, install support
-for new architectures, access 
diff erent compilers and tools, and be consistent
-across 
diff erent platforms. See the <a href="UniversalDriver.html">Universal
-Driver</a> web page for more information.</li>
-
-<li><b>XML Representation of ASTs</b>: Clang maintains a rich Abstract Syntax Tree that describes the program. Clang could emit an XML document that describes the program, which others tools could consume rather than being tied directly to the Clang binary.The XML representation needs to meet several requirements:
-  <ul>
-    <li><i>General</i>, so that it's able to represent C/C++/Objective-C abstractly, and isn't tied to the specific internal ASTs that Clang uses.</li>
-    <li><i>Documented</i>, with appropriate Schema against which the output of Clang's XML formatter can be verified.</li>
-    <li><i>Stable</i> across Clang versions.</li>
-  </ul></li>
-
 <li><b>Configuration Manager</b>: Clang/LLVM works on a large number of
 architectures and operating systems and can cross-compile to a similarly large
 number of configurations, but the pitfalls of choosing the command-line

diff  --git a/clang/www/UniversalDriver.html b/clang/www/UniversalDriver.html
deleted file mode 100755
index a6759f0aa34c..000000000000
--- a/clang/www/UniversalDriver.html
+++ /dev/null
@@ -1,87 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
-          "http://www.w3.org/TR/html4/strict.dtd">
-<html>
-<head>
-  <META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-  <title>Clang - Universal Driver</title>
-  <link type="text/css" rel="stylesheet" href="menu.css">
-  <link type="text/css" rel="stylesheet" href="content.css">
-</head>
-<body>
-
-<!--#include virtual="menu.html.incl"-->
-
-<div id="content">
-
-<h1>The Clang Universal Driver Project</h1>
-
-<p>Clang is inherently a cross compiler, in that it is always capable of
-building code for targets which are a 
diff erent architecture or even operating
-system from the one running the compiler. However, actually cross compiling in
-practice involves much more than just generating the right assembly code for a
-target, it also requires having an appropriate tool chain (assemblers, linkers),
-access to header files and libraries for the target, and many other details (for
-example, the calling convention or whether software floating point is in
-use). Traditionally, compilers and development environments provide little
-assistance with this process, so users do not have easy access to the powerful
-underlying cross-compilation abilities of clang.</p>
-
-<p>We would like to solve this problem by defining a new model for how cross
-compilation is done, based on the idea of a <i>universal driver</i>. The key
-point of this model is that the user would always access the compiler through a
-single entry point (e.g., <tt>/usr/bin/cc</tt>) and provide an argument
-specifying the <i>configuration</i> they would like to target. Under the hood
-this entry point (the universal driver) would have access to all the information
-that the driver, compiler, and other tools need to build applications for that
-target.</p>
-
-<p>This is a large and open-ended project. It's eventual success depends not
-just on implementing the model, but also on getting buy-in from compiler
-developers, operating system distribution vendors and the development community
-at large. Our plan is to begin by defining a clear list of the problems we want
-to solve and a proposed implementation (from the user perspective).</p>
-
-<p>This project is in the very early (i.e., thought experiment) stages of
-development. Stay tuned for more information, and of course, patches
-welcome!</p>
-
-<p>See also <a href="https://llvm.org/PR4127">PR4127</a>.</p>
-
-<h2>Existing Solutions and Related Work</h2>
-
-<ul>
-  <li>gcc's command line arguments <tt>-V</tt>, <tt>-B</tt>, <tt>-b</tt> are
-    generic but limited solutions to related problems. Similarly, <tt>-m32</tt>
-    and <tt>-m64</tt> solve a small subset of the problem for specific
-    architectures.</li>
-
-  <li>gcc's <a href="https://www.airs.com/ian/configure/configure_8.html">multilibs</a>
-    solve the part of the problem that relates to finding appropriate libraries
-    and include files based on particular feature support (soft float,
-    etc.).</li>
-
-  <li>Apple's "driver driver" supported by gcc and clang solve a subset of the
-    problem by supporting <tt>-arch</tt>. Apple also provides a tool chain which
-    supports <a href="https://en.wikipedia.org/wiki/Universal_binary">universal
-    binaries</a> and object files which may include data for multiple
-    architectures. See <a href="https://developer.apple.com/library/archive/technotes/tn2005/tn2137.html">TN2137</a>
-    for an example of how this is used.</li>
-
-  <li>Many operating systems and environments solve the problem by installing
-    complete development environments (including the IDE, tools, header files,
-    and libraries) for a single tool chain. This is cumbersome for users and
-    does not match well with tools which are inherently capable of cross
-    compiling.</li>
-
-  <li>The Debian <a href="https://wiki.debian.org/ArmEabiPort">ArmEabiPort</a>
-    wiki page for their work to support the ARM EABI provide an interesting
-    glimpse into how related issues impact the operating system distribution.</li>
-
-  <li><a href="https://icculus.org/fatelf/">FatELF</a> is a proposal for bringing
-    Mac OS X like "Universal Binary" support to ELF based platforms.</li>
-
-</ul>
-
-</div>
-</body>
-</html>


        


More information about the cfe-commits mailing list