Auto merge of #36281 - pnkfelix:fix-issue-36036, r=eddyb
Fix issue #36036.
Fix #36036.
We were treating an associated type as unsized even when the concrete instantiation was actually sized. Fix is to normalize before checking if it is sized.
Auto merge of #36200 - mattico:fix-llvm-linkage, r=arielb1
Fix incorrect LLVM Linkage enum
Followup of #33994 to actually work.
The `Linkage` enum in librustc_llvm got out of sync with the version in LLVM and it caused two variants of the `#[linkage=""]` attribute to break.
This adds the functions `LLVMRustGetLinkage` and `LLVMRustSetLinkage` which convert between the Rust Linkage enum and the LLVM one, which should stop this from breaking every time LLVM changes it.
Possible remaining concerns:
1. There could be a codegen test to make sure that the attributes are applied correctly (I don't know how to do this).
2. ~~The test does not exercise the `appending` linkage. I can't figure out how to make a global static raw pointer to an array. This might not even be possible? If not we should probably remove appending linkage as its unusable in rust.~~ Appending linkage is not 'emittable' anyway.
3. The test only runs on Linux.
Auto merge of #35787 - canndrew:bang_type_refactor_check, r=eddyb
Typecheck refactor for `!`
Ping @nikomatsakis @eddyb. This is the PR for the typeck refactor for `!`. Is this what you guys had in mind? Is there anything else that needs doing on it?
We were treating an associated type as unsized even when the concrete
instantiation was actually sized. Fix is to normalize before checking
if it is sized.
Rollup merge of #36242 - semarie:local-rebuild, r=alexcrichton
Use libraries from local-rust-root directory in configure when using …
…--enable-local-rebuild
When using --enable-local-rebuild configure options, the configure
script will test rustc version. But when running it, it will not use the
libraries in the local-rust-root directory.
So use `LD_LIBRARY_PATH` environment variable to correct it.
Under OpenBSD, we use `--enable-local-rebuild` for rebuilding rustc-1.11.0 using rustc-1.11.0. But as it is in use in -current (the developpment branch of OpenBSD), system libraries could easily have ABI/API changes. The (unofficial) bootstrap (rustc-1.11.0 used for building rustc-1.11.0) include several system libraries to permit it to run. The build system use libraries in stage0/lib directory. But the configure script doesn't.
Due to my special use of `--enable-local-rebuild`, I dunno if this PR is suitable for inclusion. But it corrects a difference between build and configure use of the binary.
Auto merge of #36242 - semarie:local-rebuild, r=alexcrichton
Use libraries from local-rust-root directory in configure when using …
…--enable-local-rebuild
When using --enable-local-rebuild configure options, the configure
script will test rustc version. But when running it, it will not use the
libraries in the local-rust-root directory.
So use `LD_LIBRARY_PATH` environment variable to correct it.
Under OpenBSD, we use `--enable-local-rebuild` for rebuilding rustc-1.11.0 using rustc-1.11.0. But as it is in use in -current (the developpment branch of OpenBSD), system libraries could easily have ABI/API changes. The (unofficial) bootstrap (rustc-1.11.0 used for building rustc-1.11.0) include several system libraries to permit it to run. The build system use libraries in stage0/lib directory. But the configure script doesn't.
Due to my special use of `--enable-local-rebuild`, I dunno if this PR is suitable for inclusion. But it corrects a difference between build and configure use of the binary.
Auto merge of #36240 - leeopop:master, r=jseyfried
Allow CompilerControllers to access rustc_plugin::registry::Registry
fixes #36064
I chose to put ructc_plugin::registry::Registry structure
into CompilerState structure, instead of Session structure.
This will preserve dependencies among librustc, libructc_driver, and libructc_plugin.
Matt Ickstadt [Thu, 1 Sep 2016 18:52:33 +0000 (13:52 -0500)]
Fix incorrect LLVM Linkage enum
The `Linkage` enum in librustc_llvm got out of sync with the version in LLVM and it caused two variants of the #[linkage=""] attribute to break.
This adds the functions `LLVMRustGetLinkage` and `LLVMRustSetLinkage` which convert between the Rust Linkage enum and the LLVM one, which should stop this from breaking every time LLVM changes it.
This is how https://github.com/rust-lang/rust/issues/33627 looks in action.
Looks especially nice in leftmost/rightmost positions `(first, ..)`/`(.., last)`.
I haven't touched libsyntax intentionally because the feature is still unstable.
Rollup merge of #36234 - durka:disable-codegen-config, r=alexcrichton
rustbuild: add config.toml option to disable codegen tests
Fixes #36232.
I think it worked? Here's a build log where I tried to bootstrap, it crashed, then I added the setting to config.toml and it continued: https://gist.github.com/durka/cbf97cf04b8e065f1a2cfda4c1b6bf95
Rollup merge of #36225 - johnthagen:fix-nightly-docs, r=steveklabnik
Update nightly docs supported Windows versions to match Getting Started page
https://doc.rust-lang.org/book/getting-started.html#tier-1 shows that Windows 7+ is officially supported (implying, for example Windows 10), but the nightly page only listed 7, 8, and Server 2008 R2).
This is a save-analysis variation which can be used with libraries distributed without their source (e.g., libstd). It will allow IDEs and other tools to get info about types and create URLs to docs and source, without the unnecessary clutter of internal-only save-analysis info. I'm sure we'll iterate somewhat on the design, but this is a first draft.
This is a save-analysis variation which can be used with libraries distributed without their source (e.g., libstd). It will allow IDEs and other tools to get info about types and create URLs to docs and source, without the unnecessary clutter of internal-only save-analysis info. I'm sure we'll iterate somewhat on the design, but this is a first draft.
Auto merge of #36124 - eddyb:fast-array-init, r=alexcrichton
Fix optimization regressions for operations on [x; n]-initialized arrays.
Fixes #35662 by using `!=` instead of `<` as the stop condition for `[x; n]` initialization loops.
Also included is https://github.com/eddyb/llvm/commit/cc2009f02d3b9a3c05be939978212e832310b3d6, a hack to run the GVN pass twice, another time after InstCombine.
This hack results in removal of redundant `memset` and `memcpy` calls (from loops over arrays).
cc @nrc Can we get performance numbers on this? Not sure if it regresses anything else.
Auto merge of #36016 - petrochenkov:union, r=nikomatsakis
Implement untagged unions (RFC 1444)
cc https://github.com/rust-lang/rust/issues/32836
Notes:
- The RFC doesn't talk about `#[packed]` unions, this implementation supports them, packing changes union's alignment to 1 and removes trailing padding.
- The RFC doesn't talk about dynamically sized unions, this implementation doesn't support them and rejects them during wf-checking (similarly, dynamically sized enums are not supported as well).
- The lint for drop fields in unions can't work precisely before monomorphization, so it works pessimistically - non-`Copy` generic fields are reported, types not implementing `Drop` directly, but having non-trivial drop code are reported.
- https://github.com/rust-lang/rust/pull/35764 was indeed helpful and landed timely, I didn't have to implement internal drop flags for unions.
- Unions are not permitted in constant patterns, because matching on union fields is unsafe, I didn't want unsafety checker to dig into all constants to uncover this possible unsafety.
- The RFC doesn't talk about `#[derive]`, generally trait impls cannot be derived for unions, but some of them can. I implemented only `#[derive(Copy)]` so far. In theory shallow `#[derive(Clone)]` can be derived as well if all union fields are `Copy`, I left it for later though, it requires changing how `Clone` impls are generated.
- Moving union fields is implemented as per https://github.com/rust-lang/rust/issues/32836#issuecomment-242511491.
- Testing strategy: union specific behavior is tested, sometimes very basically (e.g. debuginfo), behavior common for all ADTs (e.g. something like coherence
checks) is not generally tested.
Sébastien Marie [Sat, 3 Sep 2016 12:06:38 +0000 (14:06 +0200)]
Use libraries from local-rust-root directory in configure when using --enable-local-rebuild
When using --enable-local-rebuild configure options, the configure
script will test rustc version. But when running it, it will not use the
libraries in the local-rust-root directory.
So use `LD_LIBRARY_PATH` environment variable to correct it.
Auto merge of #36072 - arthurprs:binary_heap_opt, r=Aatch
Optimize BinaryHeap bounds checking
I was experimenting with d-ary binary heaps during the weekend (dead end) and I found that we could get some good improvements by removing bounds checking. Specially due to the panic-safe additional code, llvm can't really optimize them out.
Auto merge of #35957 - alexcrichton:macros-1.1, r=nrc
rustc: Implement custom derive (macros 1.1)
This commit is an implementation of [RFC 1681] which adds support to the
compiler for first-class user-define custom `#[derive]` modes with a far more
stable API than plugins have today.
* A new `rustc-macro` crate-type. This crate type represents one which will
provide custom `derive` implementations and perhaps eventually flower into the
implementation of macros 2.0 as well.
* A new `rustc_macro` crate in the standard distribution. This crate will
provide the runtime interface between macro crates and the compiler. The API
here is particularly conservative right now but has quite a bit of room to
expand into any manner of APIs required by macro authors.
* The ability to load new derive modes through the `#[macro_use]` annotations on
other crates.
All support added here is gated behind the `rustc_macro` feature gate, both for
the library support (the `rustc_macro` crate) as well as the language features.
There are a few minor differences from the implementation outlined in the RFC,
such as the `rustc_macro` crate being available as a dylib and all symbols are
`dlsym`'d directly instead of having a shim compiled. These should only affect
the implementation, however, not the public interface.
This commit also ended up touching a lot of code related to `#[derive]`, making
a few notable changes:
* Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't
sure how to keep this behavior and *not* expose it to custom derive.
* Derive attributes no longer have access to unstable features by default, they
have to opt in on a granular level.
* The `derive(Copy,Clone)` optimization is now done through another "obscure
attribute" which is just intended to ferry along in the compiler that such an
optimization is possible. The `derive(PartialEq,Eq)` optimization was also
updated to do something similar.
---
One part of this PR which needs to be improved before stabilizing are the errors
and exact interfaces here. The error messages are relatively poor quality and
there are surprising spects of this such as `#[derive(PartialEq, Eq, MyTrait)]`
not working by default. The custom attributes added by the compiler end up
becoming unstable again when going through a custom impl.
Hopefully though this is enough to start allowing experimentation on crates.io!
See https://github.com/rust-lang/rfcs/issues/1722 for reference.
It seems that there is `min`, `max` (simple computation of min/max), `min_by_key`, `max_by_key` (min/max by comparing mapped values) but no `min_by` and `max_by` (min/max according to comparison function). However, e.g. on vectors or slices there is `sort`, `sort_by_key` and `sort_by`.
Jonathan Turner [Fri, 2 Sep 2016 22:28:52 +0000 (15:28 -0700)]
Rollup merge of #36198 - alexcrichton:fix-travis, r=brson
test: Add a min-llvm-version directive
We've got tests which require a particular version of LLVM to run as they're
testing bug fixes. Our build system, however, supports multiple LLVM versions,
so we can't run these tests on all LLVM versions.
This adds a new `min-llvm-version` directive for tests so they can opt out of
being run on older versions of LLVM. This then namely applies that logic to the
`issue-36023.rs` test case and...
Jonathan Turner [Fri, 2 Sep 2016 22:28:51 +0000 (15:28 -0700)]
Rollup merge of #36178 - jonathandturner:windows_colors, r=nikomatsakis
Special case a few colors for Windows
As brought up on [this thread](https://github.com/rust-lang/rust/issues/33240#issuecomment-243310067) the colors used in error messages on Windows can be difficult to read because of the lack of bold.
This PR makes a few changes to improve readability, namely:
* Rather than using BRIGHT_BLUE, on Windows we now use BRIGHT_CYAN, which is easier to read on black when you do not have bold
* We used BRIGHT_YELLOW rather than YELLOW, for the same reason
* Titles will be BRIGHT_WHITE now, to give the illusion of being bold
* Detects if a temporary is being used. If so, it changes the labels to mention that a temporary value specifically is in question
* Simplifies wording of the existing labels to focus on lifetimes rather than values being valid
* Changes the help to a note, since the help+span wasn't as helpful (and sometimes more confusing) than just a note.
projects / rust.git / log