bors [Fri, 1 Feb 2019 23:43:34 +0000 (23:43 +0000)]
Auto merge of #57937 - denzp:nvptx, r=nagisa
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::back::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.
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)
bors [Thu, 31 Jan 2019 19:20:14 +0000 (19:20 +0000)]
Auto merge of #56696 - jonas-schievink:weak-counts, r=alexcrichton
Implement Weak::{strong_count, weak_count}
The counters are also useful on `Weak`, not just on strong references (`Rc` or `Arc`).
In situations where there are still strong references around, you can also get these counts by temporarily upgrading and adjusting the values accordingly. Using the methods introduced here is simpler to do, less error-prone (since you can't forget to adjust the counts), can also be used when no strong references are around anymore, and might be more efficient due to not having to temporarily create an `Rc`.
This is mainly useful in assertions or tests of complex data structures. Data structures might have internal invariants that make them the sole owner of a `Weak` pointer, and an assertion on the weak count could be used to ensure that this indeed happens as expected. Due to the presence of `Weak::upgrade`, the `strong_count` becomes less useful, but it still seems worthwhile to mirror the API of `Rc`.
bors [Thu, 31 Jan 2019 13:40:11 +0000 (13:40 +0000)]
Auto merge of #58003 - nikic:saturating-add, r=nagisa
Use LLVM intrinsics for saturating add/sub
Use the `[su](add|sub).sat` LLVM intrinsics, if we're compiling against LLVM 8, as they should optimize and codegen better than IR based on `[su](add|sub).with.overlow`.
For the fallback for LLVM < 8 I'm using the same expansion that target lowering in LLVM uses, which is not the same as Rust currently uses (in particular due to the use of selects rather than branches).
bors [Thu, 31 Jan 2019 11:07:41 +0000 (11:07 +0000)]
Auto merge of #57514 - michaelwoerister:xlto-tests, r=alexcrichton
compiletest: Support opt-in Clang-based run-make tests and use them for testing xLTO.
Some cross-language run-make tests need a Clang compiler that matches the LLVM version of `rustc`. Since such a compiler usually isn't available these tests (marked with the `needs-matching-clang`
directive) are ignored by default.
For some CI jobs we do need these tests to run unconditionally though. In order to support this a `--force-clang-based-tests` flag is added to compiletest. If this flag is specified, `compiletest` will fail if it can't detect an appropriate version of Clang.
@rust-lang/infra The PR doesn't yet enable the tests yet. Do you have any recommendation for which jobs to enable them?
bors [Thu, 31 Jan 2019 03:47:17 +0000 (03:47 +0000)]
Auto merge of #58016 - Centril:rollup, r=Centril
Rollup of 12 pull requests
Successful merges:
- #57008 (suggest `|` when `,` founds in invalid match value)
- #57106 (Mark str::trim.* functions as #[must_use].)
- #57920 (use `SOURCE_DATE_EPOCH` for man page time if set)
- #57934 (Introduce into_raw_non_null on Rc and Arc)
- #57971 (SGX target: improve panic & exit handling)
- #57980 (Add the edition guide to the bookshelf)
- #57984 (Improve bug message in check_ty)
- #57999 (Add MOVBE x86 CPU feature)
- #58000 (Fixes and cleanups)
- #58005 (update docs for fix_start/end_matches)
- #58007 (Don't panic when accessing enum variant ctor using `Self` in match)
- #58008 (Pass correct arguments to places_conflict)
Rollup merge of #57971 - jethrogb:jb/sgx-panic, r=alexcrichton
SGX target: improve panic & exit handling
Implement this part of the spec:
> The enclave must not rely on userspace to terminate other threads still running. Similarly, the enclave must not trust that it will no longer be entered by userspace, and it must safeguard against that in the entrypoints.
Rollup merge of #57106 - matthiaskrgr:trim_must_use, r=sfackler
Mark str::trim.* functions as #[must_use].
The functions return a reference to a new object and do not modify in-place
as the following code shows:
````
let s = String::from(" hello ");
s.trim();
assert_eq!(s, " hello ");
````
The new reference should be bound to a variable as now indicated by #[must_use].
projects / rust.git / log