Currently, the target of a use statement will be updated with
the visibility of the use statement itself (if the use statement was
visible).
This commit ensures that if the path to the target item is via another
use statement then that intermediate use statement will also have the
visibility updated like the target. This silences incorrect
`unreachable_pub` lints with inactionable suggestions.
targets: aarch64-unknown-none: Add +strict-align
On AArch64, an unaligned access causes a synchronous exception. In the current
state of the target, the compiler might generate unaligned accesses, see
https://github.com/rust-embedded/rust-raspi3-tutorial/issues/10.
Since this is a bare-metal target, it is possible that there is no exception
handling in place (yet) to recover from this case, causing a binary to just
silently fail.
Add `+strict-align` to avoid this case.
NVPTX target specification
This change adds a built-in `nvptx64-nvidia-cuda` GPGPU no-std target specification and a basic PTX assembly smoke tests.
The approach is taken here and the target spec is based on `ptx-linker`, a project started about 1.5 years ago. Key feature: bitcode object files being linked with LTO into the final module on the linker's side.
Prior to this change, the linker used a `ld` linker-flavor, but I think, having the special CLI convention is a more reliable way.
Questions about further progress on reliable CUDA workflow with Rust:
1. Is it possible to create a test suite `codegen-asm` to verify end-to-end integration with LLVM backend?
1. How would it be better to organise no-std `compile-fail` tests: add `#![no_std]` where possible and mark others as `ignore-nvptx` directive, or alternatively, introduce `compile-fail-no-std` test suite?
1. Can we have the `ptx-linker` eventually be integrated as `rls` or `clippy`? Hopefully, this should allow to statically link against LLVM used in Rust and get rid of the [current hacky solution](https://github.com/denzp/rustc-llvm-proxy).
1. Am I missing some methods from `rustc_codegen_ssa:🔙:linker::Linker` that can be useful for bitcode-only linking?
Currently, there are no major public CUDA projects written in Rust I'm aware of, but I'm expecting to have a built-in target will create a solid foundation for further experiments and awesome crates.
Related to #38789Fixes#38787Fixes#38786
On AArch64, an unaligned access causes a synchronous exception. In the current
state of the target, the compiler might generate unaligned accesses, see
https://github.com/rust-embedded/rust-raspi3-tutorial/issues/10.
Since this is a bare-metal target, it is possible that there is no exception
handling in place (yet) to recover from this case, causing a binary to just
silently fail.
Add `+strict-align` to avoid this case.
Implement public/private dependency feature
Implements https://github.com/rust-lang/rust/issues/44663
The core implementation is done - however, there are a few issues that still need to be resolved:
- [x] The `EXTERNAL_PRIVATE_DEPENDENCY` lint currently does notthing when the `public_private_dependencies` is not enabled. Should mentioning the lint (in an `allow` or `deny` attribute) be an error if the feature is not enabled? (Resolved- the feature was removed)
- [x] Crates with the name `core` and `std` are always marked public, without the need to explcitily specify them on the command line. Is this what we want to do? Do we want to allow`no_std`/`no_core` crates to explicitly control this in some way? (Resolved - private crates are now explicitly specified)
- [x] Should I add additional UI tests? (Resolved - added more tests)
- [x] Does it make sense to be able to allow/deny the `EXTERNAL_PRIVATE_DEPENDENCY` on an individual item? (Resolved - this is implemented)
