Auto merge of #53621 - jordanrh1:windows-arm, r=alexcrichton
Add target thumbv7a-pc-windows-msvc
This is an early draft of support for Windows/ARM. To test it,
1. Install Visual Studio 2017 and Windows SDK version 17134.
1. Obtain alexcrichton/xz2-rs#35, rust-lang-nursery/compiler-builtins#256, and the fix for [LLVM Bug 38620](https://bugs.llvm.org/show_bug.cgi?id=38620).
2. Open a command prompt and run
```
set CC_thumbv7a-pc-windows-msvc=C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.11.25503\bin\HostX64\arm\CL.exe
set CFLAGS_thumbv7a-pc-windows-msvc=/D_ARM_WINAPI_PARTITION_DESKTOP_SDK_AVAILABLE=1 /nologo
c:\python27\python.exe x.py build --host x86_64-pc-windows-msvc --build x86_64-pc-windows-msvc --target thumbv7a-pc-windows-msvc
```
It will build the stage 2 compiler, but fail building stage 2 test. To build an executable targeting windows/arm,
1. Copy `build\x86_64-pc-windows-msvc\stage0\bin\cargo.exe` to `build\x86_64-pc-windows-msvc\stage2\bin`
2. Open a command prompt and run
```
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Auxiliary\Build\vcvars64.bat"
set PATH=build\x86_64-pc-windows-msvc\stage2\bin;%PATH%
cargo new hello
cd hello
cargo build --target thumbv7a-pc-windows-msvc –release
```
Copy target\thumbv7a-pc-windows-msvc\release\hello.exe to your platform and run.
There are a number of open issues that I'm hoping to get help with:
- Error when compiling the `test` crate: `error: cannot link together two panic runtimes: panic_abort and panic_unwind`
- Warnings when building the compiler_builtins crate: `warning: cl : Command line warning D9002 : ignoring unknown option '-fvisibility=hidden'`. It looks like the build system is passing GCC-style flags to MSVC.
- How to specify the LIBPATH entries for ARM. Right now they are hardcoded as absolute paths in the target spec.
This pull request depends on
- alexcrichton/xz2-rs#35 - update vcxproj to Visual Studio 2017
- rust-lang-nursery/compiler-builtins#256 - fix compile errors when building for windows/arm
- [Bug 38620 - ARM: Incorrect COFF relocation type for thumb bl instruction](https://bugs.llvm.org/show_bug.cgi?id=38620)
Auto merge of #54086 - petrochenkov:derhelp, r=alexcrichton
resolve: Future proof derive helper attributes
Derive helpers no longer require going through recovery mode (fixes https://github.com/rust-lang/rust/issues/53481).
They also report an error if they are ambiguous with any other macro in scope, so we can resolve the question about their exact priority sometime later (cc https://github.com/rust-lang/rust/issues/52226).
- #52514 (Fix a few AMDGPU related issues)
- #53703 (Document .0 to unpack integer from Wrapping)
- #53777 (Implemented map_or_else for Result<T, E>)
- #54031 (A few cleanups and minor improvements to rustc_passes)
- #54046 (Update documentation for fill_buf in std::io::BufRead)
- #54064 (`&CStr`, not `CStr`, is the counterpart of `&str`)
- #54072 (Stabilization change for mod.rs)
- #54073 (docs: Use dollar sign for all bash prompts)
- #54074 (simplify ordering for Kind)
- #54085 (Remove documentation about proc_macro being bare-bones)
- #54087 (rustdoc: Remove generated blanket impls from trait pages)
- #54106 (Reexport CheckLintNameResult)
- #54107 (Fix typos in libstd hash map)
- #54136 (Update LLVM to fix GlobalISel dbg.declare)
- #54142 (Recover proper regression test for issue #16278.)
Rollup merge of #54106 - flip1995:pub_checklintnameresult, r=Manishearth
Reexport CheckLintNameResult
Make the enum `CheckLintNameResult` public, so that lint tools (aka Clippy) can use it together with [`LintStore::check_lint_name`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/lint/struct.LintStore.html#method.check_lint_name), to handle the case that a scoped `tool_lint` doesn't exist in the tool.
This is currently not handled by the compiler:
https://github.com/rust-lang/rust/blob/595345419d12c3ea860151df52f78744a31bafff/src/librustc/lint/levels.rs#L309-L314
Rollup merge of #54087 - ollie27:rustdoc_blanket_impl, r=QuietMisdreavus
rustdoc: Remove generated blanket impls from trait pages
#53801 only deduped the generated blanket impls but they shouldn't be displayed at all because the original blanket impl is already in the "Implementors" section. This also removes the impls from the sidebar.
Rollup merge of #54085 - dtolnay:bare, r=alexcrichton
Remove documentation about proc_macro being bare-bones
A large chunk of useful API surface area is stabilizing in Rust 1.29. We no longer have a commitment to expand the API over time as much as implied by these comments.
Rollup merge of #54072 - blitzerr:master, r=Mark-Simulacrum
Stabilization change for mod.rs
This change is in response to https://github.com/rust-lang/rust/issues/53125.
The patch makes the feature accepted and removes the tests that tested the
non-accepted status of the feature.
Rollup merge of #54046 - snaedis:issue-48022, r=steveklabnik
Update documentation for fill_buf in std::io::BufRead
Brings the documentation in line with the BufReader implementation.
Fixes #48022.
This is my first PR, and I think the `E-easy` label is very cool, as so is the practice of describing the fix but leaving it for someone else; it really makes it a lot less intimidating to get started with something!
Rollup merge of #54031 - ljedrz:cleanup_passes, r=oli-obk
A few cleanups and minor improvements to rustc_passes
- prefer `if let` to `match` when only one branch matters
- prefer equality checks to pattern matching
- prefer `is_empty` to `len() == 0`
- collapse a couple of `if` expressions
- rename `label` to `destination` when destructuring `hir::ExprKind::Continue`
- `derive Copy` for `Promotability`
- `impl BitAndAssign` for `Promotability`
- a few formatting fixes
- a few other minor cleanups
Rollup merge of #52514 - DiamondLovesYou:amdgpu-fixes, r=eddyb
Fix a few AMDGPU related issues
* AMDGPU ignores `noinline` and sadly doesn't clear the attribute when it slaps `alwaysinline` on everything,
* an AMDGPU related load bit range metadata assertion,
* I didn't enable the `amdgpu` component in the `librustc_llvm` build script,
* Add AMDGPU call abi info.
First step towards `u128` instead of `Const` in `PatternKind::Range`
This PR accomplishes two things:
* It adds `ty::Ty` to `PatternKind::Range`. The extra type information will make it easier to remove it from the `hi` and `lo` members.
* It exchanges `Const` for `u128` in `Constructor::ConstantRange`.
Auto merge of #53913 - petrochenkov:biattr4, r=alexcrichton
resolve: Future proof resolutions for potentially built-in attributes
This is not full "pass all attributes through name resolution", but a more conservative solution.
If built-in attribute is ambiguous with any other macro in scope, then an error is reported.
What complications arise with the full solution - https://github.com/rust-lang/rust/pull/53913#issuecomment-418204136.
cc https://github.com/rust-lang/rust/pull/50911#issuecomment-411605393
cc https://github.com/rust-lang/rust/issues/52269
Closes https://github.com/rust-lang/rust/issues/53531
Auto merge of #53873 - nikomatsakis:nll-universe-subtyping-and-pattern-ascription, r=pnkfelix
support ascription for patterns in NLL
This implements the strategy outlined in [this comment](https://github.com/rust-lang/rust/issues/47184#issuecomment-416669986):
- We first extend the NLL subtyping code so it can handle inference variables and subtyping.
- Then we extend HAIR patterns with type ascription.
- Then we treat the type `T` in `let pat: T = ...` as an ascription.
Before landing, a few things:
- [x] Fix the WF rule bug (filed a FIXME https://github.com/rust-lang/rust/issues/54105)
- [x] Fix an ICE I encountered locally around bound regions, or else file a follow-up
- [x] More tests probably =)
resolve: Support resolving identifier macros without their own ID
Invocation/expansion ID (aka `Mark`) is not really necessary for resolving a macro path.
What is really necessary is its parent module, parent expansion and parent legacy scope.
This is required for validation resolutions of built-in attributes, which don't get their own `Mark`s
Niko Matsakis [Wed, 5 Sep 2018 20:23:45 +0000 (16:23 -0400)]
optimize `let x: T = ..` to avoid a temporary
For some weird reason this fixes `intrinsic-move-val`. It also affects
various test heuristics. I removed one test (`reborrow_basic`) that
didn't seem to really be testing anything in particular anymore,
compared to all the other tests we've got.
Auto merge of #54011 - eddyb:anchored-in-the-future, r=petrochenkov
rustc_resolve: inject `uniform_paths` canaries regardless of the feature-gate, on Rust 2018.
This PR is an attempt at future-proofing "anchored paths" by emitting the same ambiguity errors that `#![feature(uniform_paths)]` would, with slightly changed phrasing (see added UI tests).
Also, on top of #54005, this PR allows this as well:
```rust
use crate_name;
use crate_name::foo;
```
In that any ambiguity between an extern crate and an import *of that same crate* is ignored.
r? @petrochenkov cc @aturon @Centril @joshtriplett
Auto merge of #53565 - PramodBisht:issue/53359_b, r=estebank
#53359: putting multiple unresolved import on single line
r? @estebank
Here is WIP implementation of #53359
this PR have clubbed multiple unresolved imports into a single line.
I think still two things need to improve like giving specific `label message` for each span of multi_span(how we can do this?) and second we are getting a warning while compiling, stating something like `E0432` have been passed before.
Auto merge of #53778 - petrochenkov:shadrelax2, r=nikomatsakis
resolve: Relax shadowing restrictions on macro-expanded macros
Previously any macro-expanded macros weren't allowed to shadow macros from outer scopes.
Now only "more macro-expanded" macros cannot shadow "less macro-expanded" macros.
See comments to `fn may_appear_after` and added tests for more details and examples.
Auto merge of #54057 - matthiaskrgr:stabilize-edition-plus-clippy, r=Mark-Simulacrum
Stabilize edition 2018; also updates Clippy, RLS and Cargo
Supersedes https://github.com/rust-lang/rust/pull/53999 , https://github.com/rust-lang/rust/pull/53935
Clippy build was failing there because crate_visibility_modifier feature was taken out of edition 2018 and clippy used it.
The clippy update enables the corresponding feature explicitly.
Auto merge of #53902 - dtolnay:group, r=petrochenkov
proc_macro::Group::span_open and span_close
Before this addition, every delimited group like `(`...`)` `[`...`]` `{`...`}` has only a single Span that covers the full source location from opening delimiter to closing delimiter. This makes it impossible for a procedural macro to trigger an error pointing to just the opening or closing delimiter. The Rust compiler does not seem to have the same limitation:
On that same input, a procedural macro would be forced to trigger the error on the last token inside the block, on the entire block, or on the next token after the block, none of which is really what you want for an error like above.
This commit adds `group.span_open()` and `group.span_close()` which access the Span associated with just the opening delimiter and just the closing delimiter of the group. Relevant to Syn as we implement real error messages for when parsing fails in a procedural macro: https://github.com/dtolnay/syn/issues/476.
Auto merge of #53998 - eddyb:issue-53728, r=oli-obk
rustc_codegen_llvm: don't assume offsets are always aligned.
Fixes #53728 by taking into account not just overall type alignment and the field's alignment when determining whether a field is aligned or not ("packed"), but also the field's offset within the type.
Previously, rustc assumed that the offset was always at least as aligned as `min(struct.align, field.align)`. However, there's no real reason to have that assumption, and it obviously can't always be true after we implement `#[repr(align(N), pack(K))]`. There's also a case today where that assumption is not true, involving niche discriminants in enums:
Suppose that we have the code in #53728:
```Rust
#[repr(u16)]
enum DeviceKind {
Nil = 0,
}
Observe the layout of `Option<Wrapper>`. It has an alignment of 4 because of the `u32`. `device_info.device_kind` is a good niche field to use, which means the enum ends up with this layout:
```
size = 8
align = 4
fields = [
{ offset=1, type=u16 } // discriminant, .<Some>.device_info.device_kind
]
```
And here we have an discriminant with alignment 2 (`u16`) but offset 1.
projects / rust.git / log