Alex Crichton [Mon, 12 Mar 2018 20:09:03 +0000 (13:09 -0700)]
rustc: Start a custom cabi module for wasm32
It actually was already using the `cabi_asmjs` module but that was by accident,
so route the new `wasm32-unknown-unknown` target to a new `cabi_wasm32` module.
The first entries in this module are to use `signext` and `zeroext` for types
that are under 32 bytes in size
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.
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!
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.
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