This does a global rename from `flang-new` to `flang`. I also
removed/changed any TODOs that I found related to making this change.
---------
Co-authored-by: H. Vetinari <h.vetinari@gmx.com>
Co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com>
This is instead of pushing directly. Creating a pull request is slightly
more work for the release manager, but it is more secure as we no longer
need a secret with write access to the www-releases repo.
The actions/checkout step will clear the current directory, so we need
to checkout the sources first so that the downloaded artifacts won't be
deleted.
This removes the need for macOS nodes in Buildkite. It also moves to the
proper way of testing backdeployment, which is to actually run on the
target OS itself, instead of using packaged dylibs from previous OS
versions and trying to emulate backdeployment with DYLD_LIBRARY_PATH.
As a drive-by change, also fix a few back-deployment annotations that
were incorrect and add support for minor versions in the Lit feature
determining availability from the target triple.
This gets us the full list of users with commit access to
llvm/llvm-project rather than the list of people in the llvm-committers
team. This will ensure we are able everyone to track everyone with
commit access in case they receive access some other way.
When bringing up a new cross compiler from scratch, we build
libunwind/libcxx in a setup where the toolchain is incomplete and unable
to perform the normal linker checks; this requires a few special cases
in the CMake files.
We simulate that scenario by removing the libc++ headers, libunwind and
libc++ libraries from the installed toolchain.
We need to set CMAKE_CXX_COMPILER_WORKS since CMake fails to probe the
compiler. We need to set CMAKE_CXX_COMPILER_TARGET, since LLVM's
heuristics fail when CMake hasn't been able to probe the environment
properly. (This is normal; one has to set those options when setting up
such a toolchain from scratch.)
This adds CI coverage for these build scenarios, which otherwise seldom
are tested by some build flow (but are essential when setting up a cross
compiler from scratch).
This patch sets the timeout of the code formatting job to 30 minutes.
The job is currently failing in specific circumstances and needs to be
reworked, but as a temp hack, change the timeout to 30 minutes so that
we can catch these jobs before they hit the Github Actions timeout limit
of six hours.
Somewhat (hackily) alleviates #79661 slightly.
Flang for Windows depends on compiler-rt, so we need to enable it for
the stage1 builds. This also fixes failures building the flang tests on
macOS.
Fixes#100202.
This patch decouples macOS CI testing from BuildKite, which makes the
maintenance of macOS CI easier and more accessible to all contributors.
Right now, the macOS CI is running entirely on machines owned by the
LLVM Foundation with only a small set of contributors having direct
access to them. In particular, updating these machines is currently
a very time-consuming manual process that requires taking the machines
offline, and using Github-provided instances makes that an order of
magnitude easier.
The story for performing back-deployment testing still needs to be
figured out, so for now we are retaining some jobs under BuildKite.
This workflow produces a list of users that should be moved to the LLVM
Triagers team. An admin will review the list and then manually move
people to the LLVM Triagers Team.
I've also added some documentation to the Developer Policy about the
Triage Role.
See
https://discourse.llvm.org/t/rfc2-new-criteria-for-commit-access/77110
for more details.
Currently the formatter only runs for the main branch, which prevents
the formatter from running for stacked PRs, which have to target user
branches instead of main.
This patch bumps the CI container LLVM version to 18.1.8. This should've
been bumped a while ago, but I just noticed that it was out of date.
This also allows us to drop a patch that we manually had to add as it is
by default included in v18.
Previously, #77219 added a `python_version` parameter for the Github
Actions CI Ninja-based build tests. This is necessary to run component
tests on different Python versions, as is currently done by the only
user of this parameter, the [Libclang Python bindings
test](https://github.com/llvm/llvm-project/blob/main/.github/workflows/libclang-python-tests.yml).
The parameter is missing from the concurrency group of the
workflow, meaning that starting the workflow with two different Python
versions immediately cancels one of them, as pointed out by
https://github.com/llvm/llvm-project/pull/77219#issuecomment-1937105822.
This change fixes that problem by making the Python version part of the
concurrency group key, and removes the superfluous concurrency group
from the calling workflow.
For reusable workflows, the called workflow cannot upgrade it's
permissions, and since the default permission is none, we need to
explicitly declare 'contents: read' when calling the release-sources
workflow.
Fixes the error:
The workflow is requesting 'contents: read', but is only allowed
'contents: none'.
We need a different attestation for each supported architecture, so
there artifacts all need to have a different name.
The upload step is run on a Linux runner, so no matter which
architecture's binary is being uploaded the runner.os and runner.arch
variables would always be 'Linux' and 'X64' and so we can't use them for
naming the artifact.
python3 wasn't able to see modules installed by pip, so we need to use
the setup-python action to ensure that the default pip and python3 both
use the same prefix.
See https://github.com/actions/runner-images/issues/10385
The old version in the llvm/actions repo stopped working after the
version variables were moved out of llvm/CMakeLists.txt. Composite
actions are more simple and don't require javascript, which is why I
reimplemented it as a composite action.
This will fix the failing abi checks on the release branch.
The old out-of-tree build configuration stopped working and in tree
builds are supported now, so we should use the in tree configuration.
The only downside is we can't run the tests any more, but at least we
will be able to test the build again.
If we pull from the release tag, then if there is a bug in one of the
actions on the release tag, then we can never do a build for that tag.
Pulling from main will allows us to fix bugs in the actions we use to
build the releases.
This adds release binary builds for the 4 platforms currently supported
by the free GitHub Action runners:
* Linux x86_64
* Windows x86_64
* Mac x86_64
* Mac AArch64
The test stages for these are known to fail, but the creating and
upoading of the release binaries should pass.
This checks to ensure that uploads are only made by 'approved'
uploaders, which is just everyone who has uploaded a release asset in
the past.
We could do more, but this is just a simple implementation so we can put
something in place and see how it works.
For more discussion see:
https://discourse.llvm.org/t/rfc-improve-binary-security/78121
This patch makes the issue write workflow only run after success or
failure of the workflow invoking it, preventing it from running where
the original workflow was skipped.
Fixes#97294
This job uses the new artifact attestations:
https://github.blog/2024-05-02-introducing-artifact-attestations-now-in-public-beta/
This will allow users to verify that the sources came from a specific
workflow run in the llvm-project repository. Currently, this job does
not automatically upload sources to the release page, but rather it
attaches them the workflow run as artifacts. The release manager is
expected to download, verify, and sign the sources before uploading them
to the release page.
We may be able to automatically upload them in the future once we have a
process for signing the binaries within the github workflow.
Technically, though, the binaries are being signed as part of the
attestation process, but the only way to verify the signatures is using
the gh command line tool, and I don't think it is best to rely on that,
since the tool may not be easily available on all systems.
Since clang-format 18.1.4, there have been a number of commits that
fixed various kinds of issues:
- Bug
3ceccbdb1995
- Regression
6dbaa89433f7
51ff7f38b633
35fea1032741
7699b341b763
768118d1ad38
8c0fe0d65ed8
- Crash
f1491c7460e7
- Invalid code generation
0abb89a80f5c
We currently receive a warning on all Github Actions workflows that use
`setup-python`, since they all use v4 of the action, which uses the
deprecated Node.js 16. This PR upgrades the action in all places to v5,
which uses Node.js 20 (see [setup-python release
page](https://github.com/actions/setup-python/releases/tag/v5.0.0))
Pick the latest version available in Chocolatey (18.1.6) and llvm-mingw
(20240606, which includes LLVM 18.1.7).
Also add the flag "--allow-downgrade" when installing a specific version
of LLVM. If the preinstalled version is higher than the requested one,
Chocolatey would otherwise error out when requesting installing a lower
version. This will avoid errors in the future, if the runner image comes
preinstalled with a newer version of LLVM.
(This currently seems to happen with a recent version of the GitHub
Actions runner image, version 20240610.1.0 has LLVM 18.1.6 already
preinstalled, and will error out when trying to install the 17.0.6
version that we previously requested.)
