kennytm [Mon, 12 Mar 2018 16:54:33 +0000 (00:54 +0800)]
Rollup merge of #48934 - Phlosioneer:42453-debug-hygene, r=petrochenkov
Fix hygene issue when deriving Debug
The code for several of the core traits doesn't use hygenic macros.
This isn't a problem, except for the Debug trait, which is the only
one that uses a variable, named "builder".
Variables can't share names with unit structs, so attempting to
[derive(Debug)] on any type while a unit struct with the name
"builder" was in scope would result in an error.
This commit just changes the name of the variable to
"__debug_trait_builder", because I couldn't figure out how to get a
list of all unit structs in-scope from within the derive expansion
function. If someone wants to have a unit struct with
the exact name "__debug_trait_builder", they'll just have to do it
without a [derive(Debug)].
I also checked the implementations of the other built-in derives to
ensure they didn't declare any variables.
kennytm [Mon, 12 Mar 2018 16:54:32 +0000 (00:54 +0800)]
Rollup merge of #48928 - zackmdavis:span_suggestion_field_day, r=estebank
in which some labels and notes are upgraded to structured suggestions
(Meanwhile, a couple of parse-fail tests are moved to UI tests so that
the reader can see the new output, and an existing UI test is given a
more evocative name.)
kennytm [Mon, 12 Mar 2018 16:54:27 +0000 (00:54 +0800)]
Rollup merge of #48824 - davidalber:update-conduct, r=steveklabnik
Propagating upstream code of conduct changes
[This repository's code of conduct](https://github.com/rust-lang/rust/blob/master/CODE_OF_CONDUCT.md) is out of sync with the [rust-www code of conduct](https://github.com/rust-lang/rust-www/blob/master/en-US/conduct.md) due changes from rust-lang/rust-www#1062. This PR propagates those changes and brings the files back into sync.
kennytm [Mon, 12 Mar 2018 16:54:26 +0000 (00:54 +0800)]
Rollup merge of #48725 - humenda:master, r=nikomatsakis
Update L4Re target specification
Due to the dynamically generated linker arguments of the L4Re build system, it is not a good idea to hard-code them in Rust. This PR undoes this step. It also adds an empty implementation to retrieve the number of CPUs.
kennytm [Mon, 12 Mar 2018 16:54:25 +0000 (00:54 +0800)]
Rollup merge of #48705 - klnusbaum:update_rfc_process, r=aturon
Update Feature Request instructions
As noted in #48393 the contribution instructions for submitting a Feature Request are a little hasty, suggesting that the user immediately create an issue in the RFC repository. For users that want to submit a feature request, let's instead point them directly to the README file for the RFC repository, which contains detailed instructions on how to submit a Feature Request.
kennytm [Mon, 12 Mar 2018 16:54:24 +0000 (00:54 +0800)]
Rollup merge of #48201 - NovemberZulu:master, r=steveklabnik
rephrase UnsafeCell doc
As shown by discussions on users.rust-lang.org [[1]], [[2]], UnsafeCell doc is not totally clear. I tried to made the doc univocal regarding what is allowed and what is not. The edits are based on my understanding following [[1]].
bors [Mon, 12 Mar 2018 12:58:09 +0000 (12:58 +0000)]
Auto merge of #48770 - bobtwinkles:two_phase_borrows_rewrite, r=pnkfelix
Two phase borrows rewrite
This definitely needs a careful review. Both @pnkfelix and @nikomatsakis were involved with the design of this so they're natural choices here. I'm r?'ing @pnkfelix since they wrote the original two-phase borrow implementation. Also ping @KiChjang who expressed interest in working on this. I'm going to leave a few comments below pointing out some of the more dangerous changes I made (i.e. what I would like reviewers to pay special attention too.)
bors [Mon, 12 Mar 2018 05:28:13 +0000 (05:28 +0000)]
Auto merge of #48938 - alexcrichton:no-leak-makeflags, r=kennytm
test: Forcibly remove MAKEFLAGS in compiletest
When executing run-make tests we run a risk of leaking the `MAKEFLAGS`
environment variable if `./x.py` itself was called from `make` (aka `make check
-j3` as the OSX bots do). We may then leak accidentally fds into the child
process and trick it into thinking it's got a jobserver!
Alex Crichton [Sun, 11 Mar 2018 20:15:46 +0000 (13:15 -0700)]
test: Forcibly remove MAKEFLAGS in compiletest
When executing run-make tests we run a risk of leaking the `MAKEFLAGS`
environment variable if `./x.py` itself was called from `make` (aka `make check
-j3` as the OSX bots do). We may then leak accidentally fds into the child
process and trick it into thinking it's got a jobserver!
Alex Crichton [Mon, 26 Feb 2018 17:07:16 +0000 (09:07 -0800)]
Update Cargo submodule
Required moving all fulldeps tests depending on `rand` to different locations as
now there's multiple `rand` crates that can't be implicitly linked against.
bors [Sun, 11 Mar 2018 17:54:18 +0000 (17:54 +0000)]
Auto merge of #48599 - Mark-Simulacrum:rustbuild-updates-step-1, r=alexcrichton
Remove ONLY_BUILD and ONLY_BUILD_TARGETS
Primarily removes `ONLY_BUILD` and `ONLY_BUILD_TARGETS`. These aren't actually needed in the new system since we can simply not take the relevant `host` and `target` fields if we don't want to run with them in `Step::make_run`.
This PR also includes a few other commits which generally clean up the state of rustbuild, but are not related to the `Step` changes.
Phlosioneer [Sun, 11 Mar 2018 14:03:23 +0000 (10:03 -0400)]
Fix hygene issue when deriving Debug
The code for several of the core traits doesn't use hygenic macros.
This isn't a problem, except for the Debug trait, which is the only
one that uses a variable, named "builder".
Variables can't share names with unit structs, so attempting to
[derive(Debug)] on any type while a unit struct with the name
"builder" was in scope would result in an error.
This commit just changes the name of the variable to
"__debug_trait_builder", because I couldn't figure out how to get a
list of all unit structs in-scope from within the derive expansion
function. If someone wants to have a unit struct with
the exact name "__debug_trait_builder", they'll just have to do it
without a [derive(Debug)].
bors [Sun, 11 Mar 2018 13:40:13 +0000 (13:40 +0000)]
Auto merge of #48907 - kennytm:minor-ci-stuff, r=alexcrichton
Some minor CI changes
1. On macOS, ensure crash log printing won't error, and only real crash logs are printed. This may avoid the `find` process exiting abnormally and truncated the Travis log (I guess).
2. Print `/proc/cpuinfo` and `/proc/meminfo`. To determine if there's any variation in the reported clock rate between jobs.
bors [Sun, 11 Mar 2018 09:43:50 +0000 (09:43 +0000)]
Auto merge of #48799 - alexcrichton:more-osx-cores, r=Mark-Simulacrum
travis: Upgrade OSX builders
This upgrades the OSX builders to the `xcode9.3-moar` image which has 3 cores as
opposed to the 2 that our builders currently have. Should help make those OSX
builds a bit speedier!
Zack M. Davis [Sun, 11 Mar 2018 08:04:15 +0000 (00:04 -0800)]
in which some labels and notes are upgraded to structured suggestions
(Meanwhile, a couple of parse-fail tests are moved to UI tests so that
the reader can see the new output, and an existing UI test is given a
more evocative name.)
bors [Sat, 10 Mar 2018 23:34:11 +0000 (23:34 +0000)]
Auto merge of #48419 - bobtwinkles:fix_late_bound_reg_self, r=nikomatsakis
Use free regions when determining self type in `compare_impl_method`
The ExplicitSelf::determine function expects to be able to compare regions. However, when the compare_self_type error reporting code runs we haven't resolved bound regions yet. Thus we replace them with free regions first. Fixes #48276
bors [Sat, 10 Mar 2018 03:38:19 +0000 (03:38 +0000)]
Auto merge of #48901 - alexcrichton:j1-install, r=Mark-Simulacrum
rustbuild: Pass `-j1` to OpenSSL `make install`
We explicitly do this when compiling OpenSSL itself due to weird racy issues in
its build system, and now we've started seeing issues in the `make install` step
so let's try and see what ratcheting down the parallelism does here...
Alex Crichton [Sat, 10 Mar 2018 02:49:28 +0000 (18:49 -0800)]
rustbuild: Pass `-j1` to OpenSSL `make install`
We explicitly do this when compiling OpenSSL itself due to weird racy issues in
its build system, and now we've started seeing issues in the `make install` step
so let's try and see what ratcheting down the parallelism does here...
bors [Fri, 9 Mar 2018 21:46:58 +0000 (21:46 +0000)]
Auto merge of #48891 - alexcrichton:dist-osx-9.3, r=kennytm
travis: Upgrade dist builders for OSX
This commit upgrades the dist builders for OSX to Travis's new `xcode9.3-moar`
image which has 3 cores available to it instead of 2. This should help us
provide speedier builds on OSX and hit timeouts less in theory!
Note that historically the dist builders for OSX have been a different version
than the ones that are running tests. I had forgotten why this was the case and
digging around brought up 307615567 where apparently Xcode 8 wasn't able to
compile LLVM with `MACOSX_DEPLOYMENT_TARGET=10.7` which we desired. On a whim I
gave this PR a spin and it [looks like][green] this has since been fixed (maybe
in LLVM?). In any case those green builds should hopefully mean that we can
safely upgrade and get faster infrastructure to boot.
This commit also includes an upgrade of OpenSSL. This is not done for security
reasons but rather build system reasons. Originally builds with the new image
[did not succeed][red] due to weird build failures in OpenSSL, but upgrading
seems to have made the spurious errors go away to here's to also hoping that's
fixed!
Alex Crichton [Thu, 8 Mar 2018 18:57:03 +0000 (10:57 -0800)]
travis: Upgrade dist builders for OSX
This commit upgrades the dist builders for OSX to Travis's new `xcode9.3-moar`
image which has 3 cores available to it instead of 2. This should help us
provide speedier builds on OSX and hit timeouts less in theory!
Note that historically the dist builders for OSX have been a different version
than the ones that are running tests. I had forgotten why this was the case and
digging around brought up 307615567 where apparently Xcode 8 wasn't able to
compile LLVM with `MACOSX_DEPLOYMENT_TARGET=10.7` which we desired. On a whim I
gave this PR a spin and it [looks like][green] this has since been fixed (maybe
in LLVM?). In any case those green builds should hopefully mean that we can
safely upgrade and get faster infrastructure to boot.
This commit also includes an upgrade of OpenSSL. This is not done for security
reasons but rather build system reasons. Originally builds with the new image
[did not succeed][red] due to weird build failures in OpenSSL, but upgrading
seems to have made the spurious errors go away to here's to also hoping that's
fixed!
bors [Fri, 9 Mar 2018 19:02:13 +0000 (19:02 +0000)]
Auto merge of #48757 - alexcrichton:fix-msbuild-build, r=Mark-Simulacrum
rustbuild: Fix MSBuild location of `llvm-config.exe`
For LLD integration the path to `llvm-config` needed to change to inside the
build directory itself (for whatever reason) but the build directory is
different on MSBuild than it is on `ninja` for MSVC builds, so the path to
`llvm-config.exe` was actually wrong and not working!
This commit removes the `Build::llvm_config` function in favor of the source of
truth, the `Llvm` build step itself. The build step was then updated to find the
right build directory for MSBuild as well as `ninja` for where `llvm-config.exe`
is located.
bobtwinkles [Tue, 6 Mar 2018 03:43:43 +0000 (22:43 -0500)]
Complete re-implementation of 2-phase borrows
See #48431 for discussion as to why this was necessary and what we hoped to
accomplish. A brief summary:
- the first implementation of 2-phase borrows was hard to limit in the way we
wanted. That is, it was too good at accepting all 2-phase borrows rather than
just autorefs =)
- Numerous diagnostic regressions were introduced by 2-phase borrow support
which were difficult to fix
bobtwinkles [Sat, 3 Mar 2018 22:44:06 +0000 (17:44 -0500)]
mir dataflow: change graphviz output
The new output format is perhaps a little more readable. As a bonus, we get
labels on the outgoing edges to more easily corroborate the dataflow with the
plain MIR graphviz output.
Alex Crichton [Mon, 5 Mar 2018 17:47:54 +0000 (09:47 -0800)]
rustbuild: Fix MSBuild location of `llvm-config.exe`
For LLD integration the path to `llvm-config` needed to change to inside the
build directory itself (for whatever reason) but the build directory is
different on MSBuild than it is on `ninja` for MSVC builds, so the path to
`llvm-config.exe` was actually wrong and not working!
This commit removes the `Build::llvm_config` function in favor of the source of
truth, the `Llvm` build step itself. The build step was then updated to find the
right build directory for MSBuild as well as `ninja` for where `llvm-config.exe`
is located.
bors [Fri, 9 Mar 2018 10:45:29 +0000 (10:45 +0000)]
Auto merge of #48326 - RalfJung:generic-bounds, r=petrochenkov
Warn about ignored generic bounds in `for`
This adds a new lint to fix #42181. For consistency and to avoid code duplication, I also moved the existing "bounds in type aliases are ignored" here.
Questions to the reviewer:
* Is it okay to just remove a diagnostic error code like this? Should I instead keep the warning about type aliases where it is? The old code provided a detailed explanation of what's going on when asked, that information is now lost. On the other hand, `span_warn!` seems deprecated (after this patch, it has exactly one user left!).
* Did I miss any syntactic construct that can appear as `for` in the surface syntax? I covered function types (`for<'a> fn(...)`), generic traits (`for <'a> Fn(...)`, can appear both as bounds as as trait objects) and bounds (`for<'a> F: ...`).
* For the sake of backwards compatibility, this adds a warning, not an error. @nikomatsakis suggested an error in https://github.com/rust-lang/rust/issues/42181#issuecomment-306924389, but I feel that can only happen in a new epoch -- right?
Rollup merge of #48588 - alexcrichton:termcolor, r=BurntSushi
rustc: Migrate to `termcolor` crate from `term`
This crate moves the compiler's error reporting to using the `termcolor` crate
from crates.io. Previously rustc used a super-old version of the `term` crate
in-tree which is basically unmaintained at this point, but Cargo has been using
`termcolor` for some time now and tools like `rg` are using `termcolor` as well,
so it seems like a good strategy to take!
Note that the `term` crate remains in-tree for libtest. Changing libtest will be
a bit tricky due to how the build works, but we can always tackle that later.
Programmers used to working in some other languages (such as Python or
Go) might expect to be able to destructure values with comma-separated
identifiers but no parentheses on the left side of an assignment.
Previously, the first name in such code would get parsed as a
single-indentifier pattern—recognizing, for example, the
`let a` in `let a, b = (1, 2);`—whereupon we would have a fatal syntax
error on seeing an unexpected comma rather than the expected semicolon
(all the way nearer to the end of `parse_full_stmt`).
Instead, let's look for that comma when parsing the pattern, and if we
see it, make-believe that we're parsing the remaining elements in a
tuple pattern, so that we can suggest wrapping it all in parentheses. We
need to do this in a separate wrapper method called on a "top-level"
pattern, rather than within
`parse_pat` itself, because `parse_pat` gets called recursively to parse
the sub-patterns within a tuple pattern.
~~We could also do this for `match` arms, `if let`, and `while let`, but
we elect not to in this patch, as it seems less likely for users to make
the mistake in those contexts.~~
Zack M. Davis [Sun, 25 Feb 2018 04:41:16 +0000 (20:41 -0800)]
in which parentheses are suggested for should-have-been-tuple-patterns
Programmers used to working in some other languages (such as Python or
Go) might expect to be able to destructure values with comma-separated
identifiers but no parentheses on the left side of an assignment.
Previously, the first name in such code would get parsed as a
single-indentifier pattern—recognizing, for example, the
`let a` in `let a, b = (1, 2);`—whereupon we would have a fatal syntax
error on seeing an unexpected comma rather than the expected semicolon
(all the way nearer to the end of `parse_full_stmt`).
Instead, let's look for that comma when parsing the pattern, and if we
see it, momentarily make-believe that we're parsing the remaining
elements in a tuple pattern, so that we can suggest wrapping it all in
parentheses. We need to do this in a separate wrapper method called on
the top-level pattern (or `|`-patterns) in a `let` statement, `for`
loop, `if`- or `while let` expression, or match arm rather than within
`parse_pat` itself, because `parse_pat` gets called recursively to parse
the sub-patterns within a tuple pattern.
Rollup merge of #48738 - Songbird0:parseinterror_potential_cause, r=joshtriplett
Add a potential cause raising `ParseIntError`.
Initially, I wanted to add it directly to the documentation of `str. parse()` method, I finally found that it was more relevant (I hope so?) to directly document the structure in question. I've added a scenario, in which we could all get caught at least once, to make it easier to diagnose the problem when parsing integers.
bors [Thu, 8 Mar 2018 08:52:23 +0000 (08:52 +0000)]
Auto merge of #46882 - oli-obk:miri3, r=eddyb
Replace all const evaluation with miri
* error reporting in constants prints a stacktrace through all called const fns
* Trivial constant propagation and folding in MIR (always active, irrelevant of the optimization level)
* can now use floating constants in patterns (previously only floating point literals were allowed)
* the future compat lint is still produced for both cases
* can index into constant arrays during const eval (previously feature gated)
* can create a constant union value with field `a` and read from field `b`
* can dereference references into constants
* can create references inside constants (`const X: &u32 = &22`)
* Tuple struct constructors can be used in constants
* regression in const eval errors spans (some of these need improvements in mir debug info)
* can cast floats to ints and vice versa (in constants, and even nan/inf constants)
* Mir dump prints false/true instead of 0u8/1u8
* `1i8 >> [8][0]` does not lint about exceeding bitshifts anymore.
* Needs const propagation across projections
* `foo[I]` produces a const eval lint if `foo: [T; N]` and `N < I`
* Essentially all builtin panics produce lints if they can be statically proven to trigger at runtime. This is on a best effort basis, so there might be some complex cases that don't trigger. (The runtime panic stays there, irrelevant of whether the lint is produced or not)
* can use `union`s to implement `transmute` for `Copy` types in constants without a feature gate. With all the greatness and nasal demons that come with this.
* can convert integers to `&'static T` in constants (useful for embedded)
fixes #34997 (stack overflow with many constants)
fixes #25574 (deref byte strings in patterns)
fixes #27918 (broken mir ICE)
fixes #46114 (ICE on struct constructors in patterns)
fixes #37448 (`SomeStruct { foo } as SomeStruct`)
fixes #43754 (`return` in const fn)
fixes #41898 (tuple struct constructors)
fixes #31364 (infinite recursion with const fn, fixed by miri's recursion limit)
closes #29947 (const indexing stabilization)
fixes #45044 (pattern matching repeat expressions)
fixes #47971 (ICE on const fn + references)
fixes #48081 (ICE on cyclic assoc const error)
fixes #48746 (nonhelpful error message with unions)
r? @eddyb
even though 1k loc are added in tests, this PR reduces the loc in this repository by 700
projects / rust.git / log