Convert built-in targets to JSON
Convert the built-in targets to JSON to ensure that the JSON parser is always fully featured. This follows on #32988 and #32847. The PR includes a number of extra commits that are just intermediate changes necessary for bisectibility and the ability to prove correctness of the change.
Enable reuse of `.o` files if nothing has changed
This PR completes a first "spike" for incremental compilation by enabling us to reuse `.o` files when nothing has changed. When in incr. mode, we will save `.o` files into the temporary directory, then copy them back out again if they are still valid. The code is still a bit rough but it does seem to work. =)
r? @michaelwoerister
Fixes#34036Fixes#34037Fixes#34038
Escape fewer Unicode codepoints in `Debug` impl of `str`
Use the same procedure as Python to determine whether a character is
printable, described in [PEP 3138]. In particular, this means that the
following character classes are escaped:
- Cc (Other, Control)
- Cf (Other, Format)
- Cs (Other, Surrogate), even though they can't appear in Rust strings
- Co (Other, Private Use)
- Cn (Other, Not Assigned)
- Zl (Separator, Line)
- Zp (Separator, Paragraph)
- Zs (Separator, Space), except for the ASCII space `' '` `0x20`
This allows for user-friendly inspection of strings that are not
English (e.g. compare `"\u{e9}\u{e8}\u{ea}"` to `"éèê"`).
Fixes#34318.
CC #34422.
[PEP 3138]: https://www.python.org/dev/peps/pep-3138/
In the older version, a `.o` and ` .bc` file were separate
work-products. This newer version keeps, for each codegen-unit, a set
of files of different kinds. We assume that if any kinds are available
then all the kinds we need are available, since the precise set of
switches will depend on attributes and command-line switches.
Should probably test this: the effect of changing attributes in
particular might not be successfully tracked?
This checks the `previous_work_products` data from the dep-graph and
tries to simply copy a `.o` file if possible. We also add new
work-products into the dep-graph, and create edges to/from the dep-node
for a work-product.
We used to use `Name`, but the session outlives the tokenizer, which
means that attempts to read this field after trans has complete
otherwise panic. All reads want an `InternedString` anyhow.
A work product right now is just a `.o` file. In the future it probably
includes other kinds of files, such as `.bc` files saving the
unoptimized LLVM IR.
However, because WorkProductIds must be independent of DefIds, so that
they don't need translation, this system may not be suitable *as is* for
storing fine-grained information (such as the MIR for individual defs),
as it was originally intended. We will want to refactor some for that.
Make vec::Drain and binary_heap::Drain covariant
I removed all mutable pointers/references, and added covariance tests similar to the ones in #32635. It builds and passes the tests, but I noticed that there weren't any tests of Drain's behaviour (at least not in libcollectionstest), so I'm not sure if my changes accidently broke Drain's behaviour. Should I add some tests for that (and if so, what should the tests include)?
Make vec::Drain and binary_heap::Drain covariant
I removed all mutable pointers/references, and added covariance tests similar to the ones in #32635. It builds and passes the tests, but I noticed that there weren't any tests of Drain's behaviour (at least not in libcollectionstest), so I'm not sure if my changes accidently broke Drain's behaviour. Should I add some tests for that (and if so, what should the tests include)?
std: Fix usage of SOCK_CLOEXEC
This code path was intended to only get executed on Linux, but unfortunately the
`cfg!` was malformed so it actually never got executed.
Centralize and clean type error reporting
Refactors the code that handles type errors to be cleaner and fixes various edge cases.
This made the already-bad "type mismatch resolving" error message somewhat uglier. I want to fix that in another commit before this PR is merged.
Fixes#31173
r? @jonathandturner, cc @nikomatsakis
Since we can know which targets are instantiable on a particular host,
it does not make sense to list invalid targets in the target print code.
Filter the list of targets to only include the targets that can be
instantiated.
Expand the supported_targets!() macro to also generate a set of
JSON encode/decode tests to verify that the parser will encode
and decode all of the fields needed for all of the builtin targets.
Additionally, add PartialEq to Target and TargetOptions in support
of the tests.
Change all the target generation functions to return a Result<Target,
String> so that targets that are unable to be instantiated can be
expressed as an Err instead of a panic!(). This should improve #33497 as
well.
Target's can already be built up from JSON files as well as built into
librustc_back so this adds the ability to convert any Target back into
JSON.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
Not all TargetOptions are exposed via the JSON interface to create
different targets. This exposes all the missing items and reorders them
to match the structure so that it is easier in the future to identify
missing items.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
Avoid reseting the thread local interner at the beginning of `phase_1_parse_input`
The thread local interner is used before `phase_1_parse_input` to create `InternedString`s, which currently wrap `Rc<String>`s. Once `InternedString` is refactored to be an interned string id (like `Name`), resetting will invalidate everything that was interned before `phase_1_parse_input`.
The resets were only useful for the `rusti` project, which can now use `driver::reset_thread_local_state`.
r? @nrc
fix built-in target detection
previously the logic was accepting wrong triples (like
`x86_64_unknown-linux-musl`) as valid ones (like `x86_64-unknown-linux-musl`) if
they contained an underscore instead of a dash.
fixes#33329
---
r? @brson
I wanted to use a compile-fail test at first. But, you can't pass an extra `--target` flag to `rustc` for those because they already call `rustc --target $HOST` so you get a `error: Option 'target' given more than once.`. The run-make test used here works fine though.
DoubleEndedIterator for Args
This PR implements the DoubleEndedIterator trait for the `std::env::Args[Os]` structure, as well
as the internal implementations.
It is primarily motivated by me, as I happened to implement a simple `reversor` program many times
now, which so far had to use code like this:
```Rust
for arg in std::env::args().skip(1).collect::<Vec<_>>().iter().rev() {}
```
... even though I would have loved to do this instead:
```Rust
for arg in std::env::args().skip(1).rev() {}
```
The latter is more natural, and I did not find a reason for not implementing it.
After all, on every system, the number of arguments passed to the program are known
at runtime.
To my mind, it follows KISS, and does not try to be smart at all. Also, there are no unit-tests,
primarily as I did not find any existing tests for the `Args` struct either.
The windows implementation is basically a copy-pasted variant of the `next()` method implementation,
and I could imagine sharing most of the code instead. Actually I would be happy if the reviewer would
ask for it.
