Improve diagnostics when constant pattern is too generic
This PR is a follow-up to PR #74538 and issue #73976
When constants queries Layout, TypeId or type_name of a generic parameter, instead of emitting `could not evaluate constant pattern`, we will instead emit a more detailed message `constant pattern depends on a generic parameter`.
rustc: Ignore fs::canonicalize errors in metadata
This commit updates the metadata location logic to ignore errors when
calling `fs::canonicalize`. Canonicalization was added historically so
multiple `-L` paths to the same directory don't print errors about
multiple candidates (since rustc can deduplicate same-named paths), but
canonicalization doesn't work on all filesystems. Cargo, for example,
always uses this sort of fallback where it will opportunitistically try
to canonicalize but fall back to using the input path if it otherwise
doesn't work.
If rustc is run on a filesystem that doesn't support canonicalization
then the effect of this change will be that `-L` paths which logically
point to the same directory will cause errors, but that's a rare enough
occurrence it shouldn't cause much issue in practice. Otherwise rustc
doesn't work at all today on those sorts of filesystem where
canonicalization isn't supported!
Enable docs on dist-x86_64-musl
Add the `rust-docs` component to toolchain `x86_64-unknown-linux-musl`, which allows people using rustup on their musl-based linux distribution to download the rust-docs.
`--disable-docs` is based on the assumption that `x86_64-unknown-linux-musl` is only a cross-compile target.
I have tested that the docs are built. I assume the build-system will automatically detect the docs and create a `rust-docs` component. I will [monitor](https://rust-lang.github.io/rustup-components-history/x86_64-unknown-linux-musl.html) the components and create a follow-up PR, if the docs aren't published.
See also #70619, where we enabled `rust-lld` to enable the wasm-workflow on musl-based linux distributions.
Don't use "weak count" around Weak::from_raw_ptr
As `Rc/Arc::weak_count` returns 0 when having no strong counts, this
could be confusing and it's better to avoid using that completely.
Closes#73840.
`Result::unwrap` is not eligible becuase it formats the contents of the
`Err` variant. `unwrap_or`, `unwrap_or_else` and friends are not
eligible because they drop things or invoke closures.
Fixed a known issue in the coverage map where some regions had
nonsensical source code locations. External crate functions are already
included in their own coverage maps, per library, and don't need to also
be added to the importing crate's coverage map. (In fact, their source
start and end byte positions are not relevant to the importing crate's
SourceMap.)
The fix was to simply skip trying to add imported coverage info to the
coverage map if the instrumented function is not "local".
The injected counters are still relevant, however, and the LLVM
`instrprof.increment` intrinsic call parameters will map those counters
to the external crates' coverage maps, when generating runtime coverage
data.
This commit updates the metadata location logic to ignore errors when
calling `fs::canonicalize`. Canonicalization was added historically so
multiple `-L` paths to the same directory don't print errors about
multiple candidates (since rustc can deduplicate same-named paths), but
canonicalization doesn't work on all filesystems. Cargo, for example,
always uses this sort of fallback where it will opportunitistically try
to canonicalize but fall back to using the input path if it otherwise
doesn't work.
If rustc is run on a filesystem that doesn't support canonicalization
then the effect of this change will be that `-L` paths which logically
point to the same directory will cause errors, but that's a rare enough
occurrence it shouldn't cause much issue in practice. Otherwise rustc
doesn't work at all today on those sorts of filesystem where
canonicalization isn't supported!
Fix incorrect clashing_extern_declarations warnings.
Fixes#73735, fixes#73872.
Fix clashing_extern_declarations warning for `#[repr(transparent)]` structs and safely-FFI-convertible enums, and not warning for clashes of struct members of different types, but the same size.
r? @nagisa
Make `mem::size_of_val` and `mem::align_of_val` unstably const
Implements #46571 but does not stabilize it. I wanted this while working on something today.
The only reason not to immediately stabilize are concerns around [custom DSTs](https://github.com/rust-lang/rust/issues/46571#issuecomment-387669352). That proposal has made zero progress in the last two years and const eval is rich enough to support pretty much any user-defined `len` function as long as nightly features are allowed (`raw_ptr_deref`).
Currently, this raises a `const_err` lint when passed an `extern type`.
r? @oli-obk
cc @rust-lang/wg-const-eval
- Make `is_repr_nullable_ptr` freestanding again to avoid usage of
ImproperCTypesVisitor in ClashingExternDeclarations (and don't
accidentally revert the ParamEnv::reveal_all() fix from a week earlier)
- Revise match condition for 1 Adt, 1 primitive
- Generalise check for non-null type so that it would also work for
ranges which exclude any single value (all bits set, for example)
- Make is_repr_nullable_ptr return the representable type instead of
just a boolean, to avoid adding an additional, independent "source of
truth" about the FFI-compatibility of Option-like enums. Also, rename to
`repr_nullable_ptr`.
An example of an FFI-safe enum conversion is when converting
Option<NonZeroUsize> to usize. Because the Some value must be non-zero,
rustc can use 0 to represent the None variant, making this conversion is
safe. Furthermore, it can be relied on (and removing this optimisation
already would be a breaking change).
Suppress debuginfo on naked function arguments
A function that has no prologue cannot be reasonably expected to support
debuginfo. In fact, the existing code (before this patch) would generate
invalid instructions that caused crashes. We can solve this easily by
just not emitting the debuginfo in this case.
Fixes https://github.com/rust-lang/rust/issues/42779
cc https://github.com/rust-lang/rust/issues/32408
