This flag is used to make the execution order around `+=` operators
pessimistic. Failure to save/restore the flag was causing independent
async blocks to effect one another, leading to strange ICEs and failed
assumptions.
Add GitHub Actions configuration
This PR adds the GitHub Actions configuration to the rust-lang/rust repository. The configuration will be run in parallel with Azure Pipelines until the evaluation finishes: the infrastructure team will then decide whether to switch.
Since GitHub Actions doesn't currently have any way to include pieces of configuration, this also adds the `src/tools/expand-yaml-anchors` tool, which serves as a sort of templating system. Otherwise the configuration is a mostly straight port from the Azure Pipelines configuration (thanks to all the PRs opened in the past).
There are still a few small things I need to fix before we can land this, but it's mostly complete and ready for an initial review.
r? @Mark-Simulacrum
The /mnt mount point has 53GB of free disk space at the time of writing
this commit, so this moves the build there to avoid running out of disk
space during builds.
On Azure Pipeliones, the C: filesystem is huge with a lot of free space,
while D: is small. By default builds happened in D:, so we added a
script to symlink the big directories to C:, granting us more space.
Filesystem Size Used Avail Use%
C: 256G 143G 114G 56%
D: 14G 2.0G 13G 15%
On GitHub Actions instead C: is almost full, and we have a lot of free
space on D:, where the build happens.
Filesystem Size Used Avail Use%
C: 128G 114G 15G 89%
D: 56G 4.8G 52G 9%
This commit stops creating the symlink on GitHub Actions, fixing the out
of disk space errors we were seeing on some Windows builders.
Prepare for LLVM 10 upgrade
This is #67759 minus the submodule update.
* Fix two compatibility issues in the rustllvm wrapper.
* Update data layout strings in tests.
* Fix LLVM version comparison (this become a problem because the major version has two digits now).
r? @cuviper
Rollup of 8 pull requests
Successful merges:
- #68884 (Make the `type_of` return a generic type for generators)
- #69788 (Fix sequence of Type and Trait in optin-builtin-traits in Unstable Book)
- #70074 (Expand: nix all fatal errors)
- #70077 (Store idents for `DefPathData` into crate metadata)
- #70213 (traits/fulfill: allow `stalled_on` to track `ty::Const::Infer(_)` (unused yet).)
- #70259 (Use Reveal::All in MIR optimizations)
- #70284 (correctly handle const params in type_of)
- #70289 (Refactor `codegen`)
Failed merges:
r? @ghost
Refactor `codegen`
`codegen` in `src/librustc_codegen_llvm/back/write.rs` is long and has complex control flow. These commits refactor it and make it easier to understand.
traits/fulfill: allow `stalled_on` to track `ty::Const::Infer(_)` (unused yet).
This PR addresses the representation side of #70180, but only *actually collects* `ty::Infer`s via `Ty::walk` into `stalled_on` (collecting `ty::ConstKind::Infer`s requires #70164).
However, it should be enough to handle #70107's needs (WF obligations are stalled only on the outermost type/const being an inference variable, no `walk`-ing is involved).
This is my second attempt, see #70181 for the previous one, which unacceptably regressed perf.
r? @nikomatsakis cc @nnethercote
Store idents for `DefPathData` into crate metadata
Previously, we threw away the `Span` associated with a definition's
identifier when we encoded crate metadata, causing us to lose location
and hygiene information.
We now store the identifier's `Span` in a side table, which gets encoded
into the crate metadata. When we decode items from the metadata, we
combine the name and span back into an `Ident`.
This improves the output of several tests, which previously had messages
suppressed due to dummy spans.
This is a prerequisite for #68686, since throwing away a `Span` means
that we lose hygiene information.
Expand: nix all fatal errors
Basically, we go after all `.span_fatal` / `FatalError.raise()` and similar things and remove them one by one until there are no fatal errors left.
r? @petrochenkov
Fix sequence of Type and Trait in optin-builtin-traits in Unstable Book
A simple fix in docs - the sequence of words in basic example of negative trait implementation was reversed.
Rollup of 11 pull requests
Successful merges:
- #67761 (Move the dep_graph construction to a dedicated crate.)
- #69740 (Replace some desc logic in librustc_lint with article_and_desc)
- #69981 (Evaluate repeat expression lengths as late as possible)
- #70087 (Remove const eval loop detector)
- #70242 (Improve E0308 error message wording)
- #70264 (Fix invalid suggestion on `&mut` iterators yielding `&` references)
- #70267 (get rid of ConstPropUnsupported; use ZST marker structs instead)
- #70277 (Remove `ReClosureBound`)
- #70283 (Add regression test for #70155.)
- #70294 (Account for bad placeholder types in where clauses)
- #70309 (Clean up E0452 explanation)
Failed merges:
r? @ghost
Add regression test for #70155.
With #70166 merged, `RangeInclusive` now derives `PartialEq` and `Eq`, implementing structural equality and as a side effect the range is now usable with const generics, closing #70155.
As per [#70166 (comment)](https://github.com/rust-lang/rust/pull/70166#issuecomment-601872201) a test is added to avoid a change to the private fields or the equality implementation of the range from subtly reverting #70155.
Fix invalid suggestion on `&mut` iterators yielding `&` references
Fixes#69789.
rustc suggested an invalid code when `&` reference from `&mut` iterator is mutated. The compiler knew we're mutating a value behind `&` reference, but as the assignment RHS is from desugaring, it could only see the iterator expression from source and inserted `mut` there.
r? @estebank
Improve E0308 error message wording
Hi folks,
I made [a post on Reddit](https://old.reddit.com/r/rust/comments/fmi11x/consider_linting_rusts_documentationerror_text/) about how (IMO) the docs/error messages can be a bit intimidating, one thing led to another, and I was encouraged to submit a Pull Request if I felt I could re-phrase the error message that I used as an example.
So that's this Pull Request. Open to any feedback or style changes, and I understand this is subjective.
(On another note: I am happy to see [this message was recently improved](https://github.com/rust-lang/rust/pull/69139) in `master`, so it's already better than it is in stable Rust 1.42.0.)
Ideally the last sentence could be split into at least two: [sentence explaining the inferred type.] [Sentence explaining explicit type.] [Sentence that summarizes that "this is bad," and why.]
But I'm not sure how to do so; I'm wary of writing something that turns out to be technically incorrect.
