merge `as_local_hir_id` with `local_def_id_to_hir_id`
`as_local_hir_id` was defined as just calling `local_def_id_to_hir_id` and I think that having two different ways to call the same method is somewhat confusing.
Don't really care about which of these 2 methods we want to keep.
Does this require an MCP, considering that these methods are fairly frequently used?
Set CMAKE_SYSTEM_NAME when cross-compiling
Configure CMAKE_SYSTEM_NAME when cross-compiling in `configure_cmake`,
to tell CMake about target system. Previously this was done only for
LLVM step and now applies more generally to steps using cmake.
Helps with #74576.
Remove most specialization use in serialization
Switching from specialization to min_specialization in the compiler made the unsoundness of how we used these traits pretty clear. This changes how the `Encodable` and `Decodable` traits work to be more friendly for types need a `TyCtxt` to deserialize.
The alternative design of having both `Encodable` and `TyEncodable` traits was considered, but doesn't really work because the following impls would conflict:
```
impl<E: Ecodable> TyEncodable for Encodable
impl<E: TyEcodable> TyEncodable for [E]
```
## How-to guide
- `Rustc(De|En)codable` is now spelled `Ty(De|En)coable` in `rustc_middle`, `Metadata(En|De)codable` in `rustc_metadata` where needed, and `(De|En)codable` everywhere else.
- Manual implementations of `(De|En)codable` shouldn't be much different.
- If you're adding a new interned type that needs to be en/decodable then the simplest thing way to handle this is:
- Have the type be a wrapper around a reference to the interned data (i.e. do what `ty::Predicate` does, and not what all of the other interned types do)
- Derive `Ty(En|De)codable` on the inner type
- Implement `Encodable<impl TyEncoder>` by forwarding to the inner type.
- Implement `Decodable<impl TyDecoder>` by decoding the inner type and then creating the wrapper around that (using the `tcx` from the decoder as needed).
cc @rust-lang/compiler for opinions on this change
r? @oli-obk
The match branch simplification is applied when target blocks contain
statements that are either equal or perform a const bool assignment with
different values to the same place.
Previously, when constructing new statements, only statements from a
single block had been examined. This lead to a misoptimization when
statements are equal because the assign the *same* const bool value to
the same place.
Fix the issue by examining statements from both blocks when deciding on
replacement.
Rollup of 17 pull requests
Successful merges:
- #73943 (Document the unsafe keyword)
- #74062 (deny(unsafe_op_in_unsafe_fn) in libstd/ffi/c_str.rs)
- #74185 (Remove liballoc unneeded explicit link)
- #74192 (Improve documentation on process::Child.std* fields)
- #74409 (Change Debug impl of SocketAddr and IpAddr to match their Display output)
- #75195 (BTreeMap: purge innocent use of into_kv_mut)
- #75214 (Use intra-doc links in `mem::manually_drop` & `mem::maybe_uninit`)
- #75432 (Switch to intra-doc links in `std::process`)
- #75482 (Clean up E0752 explanation)
- #75501 (Move to intra doc links in std::ffi)
- #75509 (Tweak suggestion for `this` -> `self`)
- #75511 (Do not emit E0228 when it is implied by E0106)
- #75515 (Bump std's libc version to 0.2.74)
- #75517 (Promotion and const interning comments)
- #75519 (BTreeMap: refactor splitpoint and move testing over to unit test)
- #75530 (Switch to intra-doc links in os/raw/*.md)
- #75531 (Migrate unit tests of btree collections to their native breeding ground)
Failed merges:
r? @ghost
This commit adjusts polymorphization's handling of predicates so that
after ensuring that `T` is used in `I: Foo<T>` if `I` is used, it now
ensures that `I` is used if `T` is used in `I: Foo<T>`. This is
necessary to mark generic parameters that only exist in impl parameters
as used - thereby avoiding symbol clashes when using the new mangling
scheme.
Signed-off-by: David Wood <david@davidtw.co>
Migrate unit tests of btree collections to their native breeding ground
There's one BTreeSet test case that I couldn't easily convince to come along, maybe because it truly is an integration test. But leaving it in place would mean git wouldn't see the move so I also moved it to a new file.
r? @Mark-Simulacrum
Do not emit E0228 when it is implied by E0106
Emit E0288 (lifetime bound for trait object cannot be deduced) only on bare trait objects. When the trait object is in the form of `&dyn Trait`, E0106 (missing lifetime specifier) will have been emitted, making the former redundant.
BTreeMap: purge innocent use of into_kv_mut
Replace the use of `into_kv_mut` into more precise calls. This makes more sense if you know that the single remaining use of `into_kv_mut` is in fact evil and can be trialled in court (#75200) and sent to a correction facility (#73971).
No real performance difference reported (but functions that might benefit a tiny constant bit like `BTreeMap::get_mut` aren't benchmarked):
```
benchcmp old new --threshold 5
name old ns/iter new ns/iter diff ns/iter diff % speedup
btree::map::clone_fat_100 63,073 59,256 -3,817 -6.05% x 1.06
btree::map::iter_100 3,514 3,235 -279 -7.94% x 1.09
```
Change Debug impl of SocketAddr and IpAddr to match their Display output
This has already been done for `SocketAddrV4`, `SocketAddrV6`, `IpAddrV4` and `IpAddrV6`. I don't see a point to keep the rather bad to read derived impl, especially so when pretty printing:
V4(
127.0.0.1
)
From the `Display`, one can easily and unambiguously see if it's V4 or V6. Two examples:
```
127.0.0.1:443
[2001:db8:85a3::8a2e:370:7334]:443
```
Luckily the docs explicitly state that `Debug` output is not stable and that it may be changed at any time.
Using `Display` as `Debug` is very convenient for configuration structs (e.g. for webservers) that often just have a `derive(Debug)` and are printed that way to the one starting the server.
Improve documentation on process::Child.std* fields
As a relative beginner, it took a while for me to figure out I could just steal the references to avoid partially moving the child and thus retain ability to call functions on it (and store it in structs etc).
Document the unsafe keyword
Partial fix of #34601 (just one more and it will be done 😄).
I tried to be concise and redirect as much as possible on other, longer resources, exposing only the strict necessary.
I also used `SAFETY:` comments to promote good documentation.
I would like a thorough review to ensure I did not introduce mistakes that would confuse people or worse, lead them to write unsound code.
@rustbot modify labels: T-doc,C-enhancement
Edit: this is now the last PR for the original issue: fixes#34601.
- Move the type parameter from `encode` and `decode` methods to
the trait.
- Remove `UseSpecialized(En|De)codable` traits.
- Remove blanket impls for references.
- Add `RefDecodable` trait to allow deserializing to arena-allocated
references safely.
- Remove ability to (de)serialize HIR.
- Create proc-macros `(Ty)?(En|De)codable` to help implement these new
traits.
LLVM IR coverage encoding aligns closer to Clang's
I found some areas for improvement while attempting to debug the
SegFault issue when running rust programs compiled using MSVC, with
coverage instrumentation.
I discovered that LLVM's coverage writer was generating incomplete
function name variable names (that's not a typo: the name of the
variable that holds a function name).
The existing implementation used one-up numbers to distinguish
variables, and correcting the names did not fix the MSVC coverage bug,
but the fix in this PR makes the names and resulting LLVM IR easier to
follow and more consistent with Clang's implementation.
I also changed the way the `-Zinstrument-coverage` option is supported in
symbol_export.rs. The original implementation was incorrect, and the
corrected version matches the handling for `-Zprofile-generate`, as it
turns out.
(An argument could be made that maybe `-Zinstrument-coverage` should
automatically enable `-Cprofile-generate`. In fact, if
`-Cprofile-generate` is analagous to Clang's `-fprofile-generate`, as
some documentation implies, Clang always requires this flag for its
implementation of source-based code coverage. This would require a
little more validation, and if implemented, would probably require
updating some of the user-facing messages related to
`-Cprofile-generate` to not be so specific to the PGO use case.)
None of these changes fixed the MSVC coverage problems, but they should
still be welcome improvements.
Lastly, I added some additional FIXME comments in instrument_coverage.rs
describing issues I found with the generated LLVM IR that would be
resolved if the coverage instrumentation is injected with a `Statement`
instead of as a new `BasicBlock`. I describe seven advantages of this
change, but it requires some discussion before making a change like
this.
r? @tmandry
