There are a number of things I dislike about `CrateMetadataRef`.
- It contains two fields `cstore` and `cdata`. The latter points to data
within the former. It's like having an `Elem` type that has a
reference to a vec element and also a reference to the vec itself.
Weird.
- The `cdata` field gets a lot of use, and the `Deref` impl just derefs
that field. The `cstore` field is rarely used.
- `CrateMetadataRef` is not a good name.
- Variables named `cdata` sometimes refer to values of this type and
sometimes to values of type `CrateMetadata`, which is confusing.
The good news is that `CrateMetadataRef` is not necessary and can be
replaced with `&CrateMetadata`. Why? Everywhere that `CrateMetadataRef`
is used, a `TyCtxt` is also present, and the `CStore` is accessible from
the `TyCtxt` with `CStore::from_tcx`.
So this commit removes `CrateMetadataRef` and replaces all its uses with
`&CrateMetadata`. Notes:
- This requires adding only two uses of `CStore::from_tcx`, which shows
how rarely the `cstore` field was used.
- `get_crate_data` now matches `get_crate_data_mut` more closely.
- A few variables are renamed for consistency, e.g. `data`/`cmeta` ->
`cdata`.
- An unnecessary local variable (`local_cdata`) in `decode_expn_id` is
removed.
- All the `CrateMetadataRef` methods become `CrateMetadata` methods, and
their receiver changes from `self` to `&self`.
- `RawDefId::decode_from_cdata` is inlined and removed, because it has a
single call site.
Streamline `CrateMetadataRef` construction in `provide_one!`.
`cstore.get_crate_data()` creates a `CrateMetadataRef`, which is exactly what we need. The current code is very confused and does several unnecessary things: mapping the `FreezeReadGuard` and calling `CStore::from_tcx` a second time to construct a second `CrateMetadataRef`.
This is a small perf win.
r? @mu001999
It's currently an impl for `(CrateMetadataRef, TyCtxt)`, but (a) the
`TyCtxt` is not used, and (b) the `CrateMetadataRef` can be simplified
to a `CrateMetadata` because `CStore` access isn't required. This
require changing `blob` to take `&self`, which is no big deal, and it
simplifies many `get` calls.
`Metadata` has two methods, `blob` and `decoder`, which are not used
together. Splitting the trait in two will allow some cleanups in
subsequent commits.
`cstore.get_crate_data()` creates a `CrateMetadataRef`, which is exactly
what we need. The current code is very confused and does several
unnecessary things: mapping the `FreezeReadGuard` and calling
`CStore::from_tcx` a second time to construct a second
`CrateMetadataRef`.
This is a small perf win.
Most diagnostic types are only used within their own crate, and so have
a `pub(crate)` visibility. We have some diagnostic types that are
unnecessarily `pub`. This is bad because (a) information hiding, and (b)
if a `pub(crate)` type becomes unused the compiler will warn but it
won't warn for a `pub` type.
This commit eliminates unnecessary `pub` visibilities for some
diagnostic types, and also some related things due to knock-on effects.
(I found these types with some ad hoc use of `grep`.)
Remove dead diagnostic structs.
One of these has a "FIXME(autodiff): I should get used somewhere" comment, but I figure YAGNI applies and it's so small that reinstating it if necessary would be trivial.
r? @Kivooeo
One of these has a "FIXME(autodiff): I should get used somewhere"
comment, but I figure YAGNI applies and it's so small that reinstating
it if necessary would be trivial.
Post-attribute ports cleanup pt. 1 (again)
This is a re-implementation of most (but not all) of https://github.com/rust-lang/rust/pull/154808
The code is the same as in that PR, other than a few changes, I'll leave comments where I changed things.
I did re-implement most of the commits rather than cherry-picking, so it's probably good to check the entire diff regardless
r? @jdonszelmann
Implement `-Z allow-partial-mitigations` (RFC 3855)
This implements `-Z allow-partial-mitigations` as an unstable option, currently with support for control-flow-guard and stack-protector.
As a difference from the RFC, we have `-Z allow-partial-mitigations=!foo` rather than `-Z deny-partial-mitigations=foo`, since I couldn't find an easy way to have an allow/deny pair of flags where the latter flag wins.
To allow for stabilization, this is only enabled starting from the next edition. Maybe a better policy is possible (bikeshed).
r? @rcvalle
Use closures more consistently in `dep_graph.rs`.
This file has several methods that take a `FnOnce() -> R` closure:
- `DepGraph::with_ignore`
- `DepGraph::with_query_deserialization`
- `DepGraph::with_anon_task`
- `DepGraphData::with_anon_task_inner`
It also has two methods that take a faux closure via an `A` argument and a `fn(TyCtxt<'tcx>, A) -> R` argument:
- DepGraph::with_task
- DepGraphData::with_task
The rationale is that the faux closure exercises tight control over what state they have access to. This seems silly when (a) they are passed a `TyCtxt`, and (b) when similar nearby functions take real closures. And they are more awkward to use, e.g. requiring multiple arguments to be gathered into a tuple. This commit changes the faux closures to real closures.
r? @Zalathar
Deprioritize doc(hidden) re-exports in diagnostic paths
Fixesrust-lang/rust#153477.
This is the other half of rust-lang/rust#99698, which fixed the case where the *parent module* is `#[doc(hidden)]` but left the case where the re-export itself is `#[doc(hidden)]` as a FIXME (with a tracking test in `dont-suggest-doc-hidden-variant-for-enum/hidden-child.rs`).
The problem: when a crate does `#[doc(hidden)] pub use core::error::Error`, diagnostics pick up the hidden re-export path instead of the canonical one. For example, `snafu::Error` instead of `std::error::Error`.
Two changes:
In `visible_parent_map`, the `add_child` closure now checks whether the re-export itself is `#[doc(hidden)]` via `reexport_chain` and sends it to `fallback_map`, same treatment as doc-hidden parents and underscore re-exports.
`should_encode_attrs` now returns `true` for `DefKind::Use`. Without this, `#[doc(hidden)]` on `use` items was never written to crate metadata, so `is_doc_hidden` always returned `false` cross-crate. This was the actual root cause, the check in `visible_parent_map` alone isn't enough if the attribute isn't in the metadata.
The existing FIXME test now serves as the regression test. The `.stderr` goes from suggesting `hidden_child::__private::Some(1i32)` to just `Some(1i32)`.
cc @eggyal
Post-attribute ports cleanup pt. 1
r? @jdonszelmann
This cleans up some checks I could find were for non-parsed attributes, and works towards removing BUILTIN_ATTRIBUTES
All commits do one thing and every commit passes tests, so best reviewed commit by commit
This implements `-Z allow-partial-mitigations` as an unstable option,
currently with support for control-flow-guard and stack-protector.
As a difference from the RFC, we have `-Z allow-partial-mitigations=!foo`
rather than `-Z deny-partial-mitigations=foo`, since I couldn't find an easy
way to have an allow/deny pair of flags where the latter flag wins.
To allow for stabilization, this is only enabled starting from the next edition. Maybe a
better policy is possible (bikeshed).
This file has several methods that take a `FnOnce() -> R` closure:
- `DepGraph::with_ignore`
- `DepGraph::with_query_deserialization`
- `DepGraph::with_anon_task`
- `DepGraphData::with_anon_task_inner`
It also has two methods that take a faux closure via an `A` argument and
a `fn(TyCtxt<'tcx>, A) -> R` argument:
- DepGraph::with_task
- DepGraphData::with_task
The rationale is that the faux closure exercises tight control over what
state they have access to. This seems silly when (a) they are passed a
`TyCtxt`, and (b) when similar nearby functions take real closures. And
they are more awkward to use, e.g. requiring multiple arguments to be
gathered into a tuple. This commit changes the faux closures to real
closures.
Link LLVM dynamically on aarch64-apple-darwin
Follow-up to rust-lang/rust#152768.
* Link LLVM dynamically on MacOS
* Fix a macOS LLVM dylib name mismatch
Rename `target.abi` to `target.cfg_abi` and enum-ify llvm_abiname
See [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/De-spaghettifying.20ABI.20controls/with/578893542) for more context. Discussed a bit in https://github.com/rust-lang/rust/pull/153769#discussion_r2934399038 too.
This renames `target.abi` to `target.cfg_abi` to make it less likely that someone will use it to determine things about the actual ccABI, i.e. the calling convention used on the target. `target.abi` does not control that calling convention, it just *sometimes* informs the user about that calling convention (and also about other aspects of the ABI).
Also turn llvm_abiname into an enum to make it more natural to match on.
Cc @workingjubilee @madsmtm
Nicholas Nethercote