about summary refs log tree commit diff
path: root/src
AgeCommit message (Collapse)AuthorLines
2019-02-03Auto merge of #58079 - ljedrz:HirIdification_phase_1, r=Zoxcbors-114/+257
hir: add HirId to main Hir nodes This is the 1st PR in a series dedicated to `HirId`-ification, i.e. deprecating `ast::NodeId`s after the AST > HIR lowering process. The bigger proof of concept can be seen in https://github.com/rust-lang/rust/pull/57578. **Phase 1**: store `HirId` in all remaining (some already have it) main HIR nodes (excluding `*Id` objects). - [x] `Field` - [x] `FieldPat` - [x] `ForeignItem` - [x] `GenericParam` - [x] `Lifetime` - [x] `MacroDef` - [x] `PathSegment` - [x] `PatKind::Binding` - [x] `Stmt` - [x] `StructField` - [x] `TypeBinding` - [x] `VariantData` - [x] `WhereClause` - [x] `WhereEqPredicate` r? @Zoxc Cc @varkor
2019-02-03Improve file list displayGuillaume Gomez-2/+3
2019-02-02Auto merge of #58071 - Centril:adjust-stabilization-order, r=varkorbors-2/+2
Fix stabilization order of `uniform_paths` The `accepted` list is not correctly sorted; this PR fixes that. r? @alexreg @bors rollup
2019-02-02liballoc: remove redundant extern crate.Mazdak Farrokhzad-2/+0
2019-02-02hir: add HirId to main Hir nodesljedrz-114/+257
2019-02-02Update visibility of intermediate use items.David Wood-9/+107
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.
2019-02-02liballoc: fix some idiom lints.Mazdak Farrokhzad-87/+90
2019-02-02liballoc: elide &'static.Mazdak Farrokhzad-2/+2
2019-02-02liballoc: elide some lifetimes.Mazdak Farrokhzad-126/+119
2019-02-02rustfmt the testRalf Jung-30/+62
2019-02-02pre_exec: expand docsRalf Jung-6/+8
2019-02-02liballoc: apply uniform_paths.Mazdak Farrokhzad-19/+20
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-60/+482
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/+182
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
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-28 11:08:31 +0000