about summary refs log tree commit diff
AgeCommit message (Collapse)AuthorLines
2019-02-02deprecate things a bit slowerRalf Jung-2/+2
2019-02-02liballoc: prefer imports of borrow from libcore.Mazdak Farrokhzad-14/+13
2019-02-02liballoc: adjust abolute imports + more import fixes.Mazdak Farrokhzad-25/+15
2019-02-02liballoc: refactor & fix some imports.Mazdak Farrokhzad-342/+424
2019-02-02Auto merge of #58047 - SimonSapin:split_ascii_whitespace, r=Centrilbors-8/+6
Stabilize split_ascii_whitespace Tracking issue FCP to merge: https://github.com/rust-lang/rust/issues/48656#issuecomment-442372750 Closes https://github.com/rust-lang/rust/issues/48656
2019-02-02liballoc: cargo check passes on 2018Mazdak Farrokhzad-60/+61
2019-02-02liballoc => edition = 2018.Mazdak Farrokhzad-0/+1
2019-02-02fix stabilization order of uniform_paths.Mazdak Farrokhzad-2/+2
2019-02-02Auto merge of #58048 - SimonSapin:error_type_id, r=Centrilbors-3/+1
Stabilize std::error::Error::type_id This should have been part of https://github.com/rust-lang/rust/pull/57834 FCP: https://github.com/rust-lang/rust/issues/27745#issuecomment-373906749
2019-02-02Auto merge of #58060 - andre-richter:master, r=nagisabors-0/+1
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.
2019-02-01fix the build errorsLokathor-3/+6
2019-02-01const-int-wrapping.rs += wrapping_negLokathor-2/+5
2019-02-01const-int-overflowing.rs += overflowing_negLokathor-0/+6
2019-02-01Simplify the overflowing_neg expressionLokathor-1/+1
2019-02-02Test alloca with #[repr(align(x))] on enumNiklas Fiekas-0/+36
2019-02-01Auto merge of #57937 - denzp:nvptx, r=nagisabors-61/+483
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. Related to #38789 Fixes #38787 Fixes #38786
2019-02-01Rename iter::unfold to iter::from_fn and remove explicit stateSimon Sapin-32/+25
This API is unstable. CC https://github.com/rust-lang/rust/issues/55977#issuecomment-459657195
2019-02-01targets: aarch64-unknown-none: Add +strict-alignAndre Richter-0/+1
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.
2019-02-01Auto merge of #57978 - varkor:fix-irrefutable-integer-range-match, r=oli-obkbors-7/+21
Fix bug in integer range matching Fixes #57894.
2019-02-01Fix bug in integer range matchingvarkor-7/+21
2019-02-01update testRalf Jung-13/+13
2019-02-01also replace before_exec by pre_exec on redoxRalf Jung-6/+26
2019-02-01deprecate before_exec in favor of unsafe pre_execRalf Jung-4/+24
2019-02-01Auto merge of #58049 - king6cong:typo, r=oli-obkbors-1/+1
Fix typo None
2019-02-01add regression test for #57979Niko Matsakis-0/+42
2019-02-01don't try to get a DefId for a Def that doesn't have oneQuietMisdreavus-6/+18
2019-02-01Make the existential type errors a little bit more helpfulOliver Scherer-12/+32
2019-02-01Test more related casesOliver Scherer-0/+9
2019-02-01Restrict concrete types to equivalent typesOliver Scherer-33/+264
2019-02-01Generic type parameters are flexible even for existential typesOliver Scherer-87/+32
2019-02-01Test aller thingsOliver Scherer-0/+34
2019-02-01Test all the thingsOliver Scherer-24/+87
2019-02-01Be more permissive with required bounds on existential typesOliver Scherer-6/+8
2019-02-01Add FIXMEOliver Scherer-0/+2
2019-02-01Auto merge of #57586 - Aaron1011:feature/pub-priv-dep, r=petrochenkovbors-2/+183
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)
2019-02-01Cleanup unecessary codeAaron Hill-15/+0
2019-02-01Update tests for future-compat warning removalAaron Hill-13/+2
2019-02-01Add future compat lint declarationAaron Hill-5/+0
2019-02-01Remove unnecessary is_local() checkAaron Hill-2/+1
2019-02-01Test allowing individual struct fieldAaron Hill-0/+6
2019-02-01Replace --extern-public with --extern-privateAaron Hill-36/+36
2019-02-01Remove feature from testAaron Hill-1/+0
2019-02-01Tidy fixesAaron Hill-4/+5
2019-02-01Move --extern-public behind -Z unstable-optionsAaron Hill-24/+29
2019-02-01Remove feature gateAaron Hill-3/+0
2019-02-01Rename external_private_dependency to exported_private_dependenciesAaron Hill-12/+14
2019-02-01Delete dead codeAaron Hill-26/+0
2019-02-01Track extern_public command-line argumentAaron Hill-5/+5
2019-02-01Add test for 'std' crate being publicAaron Hill-0/+13
2019-02-01Clippy fixes, rename stuff to match RFCAaron Hill-13/+32
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-04-25 14:28:24 +0000