Instead of manually specifying the oldstable version in all our CI
scripts, it is now pulled from the `Cargo.toml` which simplifies the
update process.
The contributing guide has also been updated to not include the explicit
version and its wording has been loosened a bit to correctly represent
current maintenance practices.
The glutin 0.30.0 update decouples glutin from winit which
provides us with basis for a multithreaded renderer. This
also improves robustness of our configuration picking,
context creation, and surface handling.
As an example we're now able to start on systems without a vsync,
we don't try to build lots of contexts to check if some config works,
and so on.
That also brings us possibility to handle context losses, but that's
a future work.
Fixes#1268.
The patch 9e7655e introduced some changes which improved rendering with
very dense grids, but the automatic benchmarks indicated a slight
performance difference in the `dense_cells` benchmark.
Caching the terminal lock between iterations rather than always calling
`try_lock` resolves that issue.
While breaking early in the `WouldBlock` case with `unprocessed != 0`
does also help resolve these issues, it shows some more significant
fluctuations. Combining both fixes does not help.
Additionally on Windows receiving `Ok(0)` from the PTY will also occur
instead of a `WouldBlock` error, so handling that fixes freezing on
Windows.
Fixes#5305.
Since not all suggested clippy lints by stable clippy are supported on
the MSRV of Alacritty, this commit moves the clippy checks to the MSRV.
Unfortunately this will mean that our lints might be significantly
behind, however it ensures our CI never blocks any code that should be
valid.
Developers themselves of course can still run the latest clippy to
follow the up to date recommendations.
This removes all CI builds from travis-ci, due to their recent changes
in policy and harsh limitations on builds. With build times over 2
hours, it was a significant hindrance to development.
Instead of Travis CI, the CI is now split on Sourcehut and GitHub. Since
Sourcehut only supports Linux/BSD, all builds on those operating systems
are executed there. The GitHub Actions CI is used to build for
Windows/macOS, which are not available on Sourcehut.
Since asset deployment for releases requires builds on all platforms,
this is also done on GitHub actions. Though the new `upload_asset.sh`
script makes sure that migration in the future is fairly simple and we
do not tie ourselves to the overly complicated GitHub Actions ecosystem.
Christian Duerr