I meant to double check the work in https://github.com/rust-lang/rust/issues/29429, but due to Mozlando, forgot. Here are two small fixes.
r? @brson I would like to get this backported to beta as well, sorry :( I don't generally want doc backports, but feel this is exceptional and worth it.
With this commit, metadata encoding and decoding can make use of thread-local encoding and decoding contexts. These allow implementers of `serialize::Encodable` and `Decodable` to access information and
datastructures that would otherwise not be available to them. For example, we can automatically translate def-id and span information during decoding because the decoding context knows which crate the data is decoded from. Or it allows to make `ty::Ty` decodable because the context has access to the `ty::ctxt` that is needed for creating `ty::Ty` instances.
Some notes:
- `tls::with_encoding_context()` and `tls::with_decoding_context()` (as opposed to their unsafe versions) try to prevent the TLS data getting out-of-sync by making sure that the encoder/decoder passed in is actually the same as the one stored in the context. This should prevent accidentally reading from the wrong decoder.
- There are no real tests in this PR. I had a unit tests for some of the core aspects of the TLS implementation but it was kind of brittle, a lot of code for mocking `ty::ctxt`, `crate_metadata`, etc and did actually test not so much. The code will soon be tested by the first incremental compilation auto-tests that rely on MIR being properly serialized. However, if people think that some tests should be added before this can land, I'll try to provide some that make sense.
r? @nikomatsakis
With this commit, metadata encoding and decoding can make use of
thread-local encoding and decoding contexts. These allow implementers
of serialize::Encodable and Decodable to access information and
datastructures that would otherwise not be available to them. For
example, we can automatically translate def-id and span information
during decoding because the decoding context knows which crate the
data is decoded from. Or it allows to make ty::Ty decodable because
the context has access to the ty::ctxt that is needed for creating
ty::Ty instances.
The `rsbegin.o` and `rsend.o` build products should not be generated
on non WinGnu platforms.
This is another path to resolving #30063 for non win-gnu targets.
(And it won't require a snapshot, unlike PR #30208.)
r? @alexcrichton
Fixes#26403
This adjusts the pointer, if needed, to the correct alignment by using the alignment information in the vtable.
Handling zero might not be necessary, as it shouldn't actually occur. I've left it as it's own commit so it can be removed fairly easily if people don't think it's worth doing. The way it's handled though means that there shouldn't be much impact on performance.
When given `rustc -C codegen-units=4 --emit=obj`, reset units back to 1.
Fix#30063
Note: while this code is careful to handle the case of mutliple emit types (e.g. `--emit=asm,obj`) by reporting all the emit types that conflict with codegen units in its warnings, an invocation with multiple emit types *and* `-o PATH` will continue to ignore the requested target path (with a warning), as it already does today, since the code that checks for that is further downstream. (Multiple emit types without `-o PATH` will "work", though it will downgrade codegen-units to 1 just like all the other cases.)
r? @alexcrichton
Instead of `ast::Ident`, bindings, paths and labels in HIR now keep a new structure called `hir::Ident` containing mtwt-renamed `name` and the original not-renamed `unhygienic_name`. `name` is supposed to be used by default, `unhygienic_name` is rarely used.
This is not ideal, but better than the status quo for two reasons:
- MTWT tables can be cleared immediately after lowering to HIR
- This is less bug-prone, because it is impossible now to forget applying `mtwt::resolve` to a name. It is still possible to use `name` instead of `unhygienic_name` by mistake, but `unhygienic_name`s are used only in few very special circumstances, so it shouldn't be a problem.
Besides name resolution `unhygienic_name` is used in some lints and debuginfo. `unhygienic_name` can be very well approximated by "reverse renaming" `token::intern(name.as_str())` or even plain string `name.as_str()`, except that it would break gensyms like `iter` in desugared `for` loops. This approximation is likely good enough for lints and debuginfo, but not for name resolution, unfortunately (see https://github.com/rust-lang/rust/issues/27639), so `unhygienic_name` has to be kept.
cc https://github.com/rust-lang/rust/issues/29782
r? @nrc
The `rsbegin.o` and `rsend.o` build products should not be generated
on non WinGnu platforms.
This is another path to resolving #30063 for non win-gnu targets.
(And it won't require a snapshot, unlike PR #30208.)
Fix#30063
Note: while this code is careful to handle the case of mutliple emit
types (e.g. `--emit=asm,obj`) by reporting all the emit types that
conflict with codegen units in its warnings, an invocation with
multiple emit types *and* `-o PATH` will continue to ignore the
requested target path (with a warning), as it already does today,
since the code that checks for that is further downstream.
The presence of the drop flag caused the offset calculation to be
incorrect, leading to the pointer being incorrect. This has been fixed
by calculating the offset based on the field index (and not assuming
that the field is always the last one).
However, I've also stopped the drop flag from being added to the end of
unsized structs to begin with. Since it's not actually accessed for
unsized structs, and isn't actually where we would say it is, this made
more sense.
