| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Use lib crate type for SGX in `fn build_auxiliary`
since SGX does not support `dylib`
cc @Goirad
|
|
Bump bootstrap compiler
This bumps the bootstrap compiler and the rustfmt that x.py fmt uses.
|
|
|
|
Let compiletest recognize gdb 10.x
git gdb has moved to version 10. My build prints this as its
--version:
GNU gdb (GDB) 10.0.50.20200420-git
Unfortunately this conflicts with this comment in compiletest:
// We limit major to 1 digit, otherwise, on openSUSE, we parse the openSUSE version
This patch changes the version parsing to follow the GNU coding
standard, which accounts for both the openSUSE case as well as
handling gdb 10.
My debuginfo test run now says:
NOTE: compiletest thinks it is using GDB with native rust support
NOTE: compiletest thinks it is using GDB version 10000050
... where previously it failed to find that gdb 10 had rust support.
|
|
content there before the current changes
|
|
|
|
The compiletest version-parsing tests failed after the previous patch.
However, I don't believe these tests are correct, in that I don't
think RHEL or CentOS ever put the gdb version number into parentheses.
Instead they display like:
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-119.el7
|
|
git gdb has moved to version 10. My build prints this as its
--version:
GNU gdb (GDB) 10.0.50.20200420-git
Unfortunately this conflicts with this comment in compiletest:
// We limit major to 1 digit, otherwise, on openSUSE, we parse the openSUSE version
This patch changes the version parsing to follow the GNU coding
standard, which accounts for both the openSUSE case as well as
handling gdb 10.
My debuginfo test run now says:
NOTE: compiletest thinks it is using GDB with native rust support
NOTE: compiletest thinks it is using GDB version 10000050
... where previously it failed to find that gdb 10 had rust support.
|
|
Add illumos triple
This fixes rust-lang/rust#55553 and adds support for `illumos` as a `target_os` on `x86_64`. In addition to the compile spec and libstd additions, several library dependencies have been bumped in order to permit working builds of cargo and rustup for the new target.
Work originally started by @jasonbking, with subsequent additions by @pfmooney and @jclulow.
|
|
End cleanup on rustdoc-js tools
Fixes #70689.
It removes a lot of code, which is pretty nice. :3
We now only have one entry point and a small set of options.
r? @ollie27
|
|
Co-Authored-By: Jason King <jason.brian.king@gmail.com>
Co-Authored-By: Joshua M. Clulow <jmc@oxide.computer>
|
|
|
|
ci: run mir-opt tests on PR CI also as 32-bit (for `EMIT_MIR_FOR_EACH_BIT_WIDTH`).
Background: #69916 and [`src/test/mir-opt/README.md`](https://github.com/rust-lang/rust/blob/master/src/test/mir-opt/README.md):
> By default 32 bit and 64 bit targets use the same dump files, which can be problematic in the
presence of pointers in constants or other bit width dependent things. In that case you can add
>
> ```
> // EMIT_MIR_FOR_EACH_BIT_WIDTH
> ```
>
> to your test, causing separate files to be generated for 32bit and 64bit systems.
However, if you change the output of such a test (intentionally or not), or if you add a test and it varies between 32-bit and 64-bit platforms, you have to run this command (for a x64 linux host):
`./x.py test --stage 1 --target x86_64-unknown-linux-gnu --target i686-unknown-linux-gnu --bless src/test/mir-opt`
Otherwise, bors trying to merge the PR will fail, since we test 32-bit targets there.
But we don't on PR CI, which means there's no way the PR author would know (unless they were burnt by this already and know what to look for).
This PR resolves that by running `mir-opt` tests for ~~`i686-unknown-linux-gnu`~~, on PR CI.
**EDIT**: switched to `armv5te-unknown-linux-gnueabi` to work around LLVM 7 crashes (see https://github.com/rust-lang/compiler-builtins/pull/311#issuecomment-612270089), found during testing.
cc @rust-lang/wg-mir-opt @rust-lang/infra
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Make the rustc respect the `-C codegen-units` flag in incremental mode.
This PR implements (the as of yet unapproved) major change proposal at https://github.com/rust-lang/compiler-team/issues/245. See the description there for background and rationale.
The changes are pretty straightforward and should be easy to rebase if the proposal gets accepted at some point.
r? @nikomatsakis cc @pnkfelix
|
|
|
|
|
|
|
|
|
|
r=michaelwoerister
Clean up debugging options
I found various sub-optimal things when I was looking at option handling.
|
|
`-C incremental` was introduced over two years ago. `-Z incremental` was
kept for transitioning, but it's been long enough now that it should be
ok to remove it.
|
|
Because it uses `parse_bool` and defaults to true, it is actually
impossible to set it to false. And it hasn't been experimental for some
time now.
|
|
Convert version string to integer before comparing. Otherwise
we get into trouble with double digit versions ;)
|
|
Add Node.js to PR CI image
This should allow the `rustdoc-js` and `rustdoc-js-std` test suites to run automatically on PRs.
|
|
|
|
--show-coverage json
The purpose of this change is to be able to use it as a tool in docs.rs in order to provide some more stats to crates' owners. Eventually even create a badge or something along the line.
r? @QuietMisdreavus
|
|
|
|
Additionally verify that the current implementation of LLVM version
check (which uses lexicographic ordering) is good enough to exclude
versions before LLVM 9, where the new LLVM pass manager is unsupported.
|
|
|
|
Allow whitespaces in revision flags
Allow whitespaces in revision flags, like `// [foo]`.
Fixes #69183
|
|
r=Mark-Simulacrum
rustc_session: allow overriding lint level of individual lints from a group
Fixes #58211 and fixes rust-lang/rust-clippy#4778 and fixes rust-lang/rust-clippy#4091
Instead of hard-coding the lint level preferences (from lowest to highest precedence: `lint::Allow -> lint::Warn -> lint::Deny -> lint::Forbid`), the position of the argument in the command line gets taken into account.
Examples:
1. Passing `-D unused -A unused-variables` denies everything in the lint group `unused` **except** `unused-variables` which is explicitly allowed.
1. Passing `-A unused-variables -D unused` denies everything in the lint group `unused` **including** `unused-variables` since the allow is specified before the deny (and therefore overridden by the deny).
This matches the behavior that is already being used when specifying `allow`/`deny` in the source code.
|
|
|
|
|
|
compiletest: Unit tests for `EarlyProps` (+ small cleanup)
* Parse `EarlyProps` from a reader
* Add unit tests for `EarlyProps`
* Remove unused `llvm-cxxflags` option
* Remove unnecessary memory allocations in `iter_header`
* Update mode list displayed in `--help`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Replace `BufRead::lines` with `BuRead::read_line` to reduce memory allocations.
|
|
compiletest: Simplify multi-debugger support
Previous implementation used a single mode type to store various pieces
of otherwise loosely related information:
* Whether debuginfo mode is in use or not.
* Which debuggers should run in general.
* Which debuggers are enabled for particular test case.
The new implementation introduces a separation between those aspects.
There is a single debuginfo mode parametrized by a debugger type.
The debugger detection is performed first and a separate configuration
is created for each detected debugger. The test cases are gathered
independently for each debugger which makes it trivial to implement
support for `ignore` / `only` conditions.
Functional changes:
* A single `debuginfo` entry point (rather than `debuginfo-cdb`, `debuginfo-gdb+lldb`, etc.).
* Debugger name is included in the test name.
* Test outputs are placed in per-debugger directory.
* Fixed spurious hash mismatch. Previously, the config mode would change
from `DebugInfoGdbLldb` (when collecting tests) to `DebugInfoGdb` or
`DebugInfoLldb` (when running them) which would affect hash computation.
* PYTHONPATH is additionally included in gdb hash.
* lldb-python and lldb-python-dir are additionally included in lldb hash.
|
|
|
|
|
