error_index_generator should output stdout/stderr when it panics.
**bootstrap change**
Call error_index_generator tool using run_quiet which will additionally print std out and std err of the command when it returns an error.
(was `run` uses `run_silent` under the covers.)
Why: PR #62871 is hitting a build error but the panic isn't getting shown so its unclear what the problem is.
Add support for UWP targets
Hi,
This pull request aims at adding support for UWP (Universal Windows Apps) platform.
A few notes:
- This requires a very recent mingw-w64 version (containing this commit and the previous related ones: e8c433c871 (diff-eefdfbfe9cec5f4ebab88c9a64d423a9))
- This was tested using LLVM/clang rather than gcc, and so far it assumes that LLVM/clang will be the native compiler. This is mostly due to the fact that the support for exceptions/stack unwinding for UWP got much more attention in libunwind
- The "uwp" part of the target needs support for it in the `cc-rs` & `backtrace-rs` crates. I'll create the MR there right after I submit this one and will link everything together, but I'm not sure what's the correct way of dealing with external dependencies in the context of rust
- Enabling import libraries and copying them across stages requires a change in cargo, for which I'll open a MR right after I submit this one as well
- The i686 stack unwinding is unsupported for now, because LLVM assumes SjLj, while rust seems to assume SEH will be used. I'm unsure how to fix this
Also, this is my first encounter with rust, so please bear with my code, it might not feel so idiomatic or even correct :)
I'm pretty sure there's a way of doing things in a cleaner way when it comes to win/c.rs, maybe having a UWP & desktop specific modules, and import those conditionally? It doesn't feel right to sprinkle `#[cfg(...)]` all over the place
Off course, I'll gladly update anything you see fit (to the extent of my abilities/knowledge :) )!
Thanks,
Fix some sanity checks
Update: Changes that made it not to work dropped.
* Fix `building_llvm` in sanity check
* This was subtly broken: we build LLVM if any of the hosts builds LLVM, and not setting the config meant that LLVM is built for that target. Because of filtering away the targets not configured and the semantics of `Iterator::any`, it currently didn't set the `building_llvm` flag even if we indeed build it.
* Add `swig` sanity check
* This checks whether there is a `swig` executable needed for LLDB.
So far it is assumed that using a DLL as a -l parameter argument is ok,
but the assumption doesn't hold when compiling the native code with
llvm.
In which case, an import library is required, so let's build one
This also requires the cargo counterpart to add the import library in
the stamp files, at least when compiling libstd. Otherwise, the files
don't get uplifted
In `configure.py`, using the `o` function creates an enable/disable
boolean setting, and writes `true` or `false` in `config.toml`. However,
rustbuild is expecting to parse a `u32` debuginfo level. We can change
to the `v` function to have the options require a value.
port rust for vxWorks
The supporting for vxWorks has been enabled in this branch. Although there are still a lots of work to do, I would like to upstream the code and fix the problems later.
Please let me know if there is anything I have to do before upstream the code.
r? @alexcrichton
Thanks,
Baoshan
ci: Remove Travis/AppVeyor configuration
Now that we've fully moved to Azure Pipelines and bors has been updated
to only gate on Azure this commit removes the remaining Travis/AppVeyor
support contained in this repository. Most of the deletions here are
related to producing better output on Travis by folding certain
sections. This isn't supported by Azure so there's no need to keep it
around, and if Azure ever adds support we can always add it back!
Now that we've fully moved to Azure Pipelines and bors has been updated
to only gate on Azure this commit removes the remaining Travis/AppVeyor
support contained in this repository. Most of the deletions here are
related to producing better output on Travis by folding certain
sections. This isn't supported by Azure so there's no need to keep it
around, and if Azure ever adds support we can always add it back!
In developing #61557 I noticed that there were two parts of our tools
that were rebuilt twice on CI. One was rustfmt fixed in #61557, but
another was Cargo. The actual fix for Cargo's double compile was
rust-lang/cargo#7010 and took some time to propagate here. In an effort
to continue to assert that Cargo is itself not compiled twice, I updated
the assertion in rustbuild at the time of working on #61557 but couldn't
land it because the fix wouldn't be ready until the next bootstrap.
The next bootstrap is now here, so the fix can now land! This does not
change the behavior of rustbuild but it is intended to catch the
previous iteration of compiling cargo twice. The main update here was to
consider more files than those in `$target/release/deps` but also
consider those in `$target/release`. That's where, for example,
`libcargo.rlib` shows up and it's the file we learn about, and that's
what we want to deduplicate.
Update cargo-vendor usage
This contains a variety of updates to clean up the usage of cargo-vendor.
- Remove the install step for the old cargo-vendor now that it is built-in to cargo and available in the stage0 install.
- Update installation instructions, dealing with vendoring. The current instructions of running `sudo ./x.py install` is broken, it will almost always fail (since the vendor directory doesn't exist). Since the steps for properly handling this are numerous, I'm recommending removing the suggestion to use `sudo` altogether.
- If the sudo-forced-vendoring detects that the vendor directory is not available, abort with instructions on how to fix.
- Now that cargo-vendor is built-in, automatically run it if it looks like it is needed.
- Update instructions on how to install cargo.
- Remove the unused markdown link references in README/CONTRIBUTING. This reverts most of #44935. These references don't do anything if they are unused.
Closes#49269
cc #61142#48771#40108
Fix ICEs when `Self` is used in type aliases
I think it is right just to disallow this at resolution stage rather than let typeck produce a cyclic error. This is in line with previous behaviour. There was probably no need at all for the change that introduced this bug in #57428, so I've simply reversed it.
Fixes#62263, #62364, #62305.
r? @eddyb
rustbuild: Cleanup global lint settings
Lint settings do not depend on `if let Some(target) = target` in any way, so they are moved out of that clause.
Internal lints now respect `RUSTC_DENY_WARNINGS`.
Crate name treatment is cleaned up a bit.
cc https://github.com/rust-lang/rust/pull/61545 @flip1995
r? @Mark-Simulacrum
Lint on invalid values passed to x.py --warnings
This also introduces support for `--warnings allow` and fixes --warnings
being overridden by the configuration file, config.toml.
Fixes#62402
r? @RalfJung
Implement another internal lints
cc #49509
This adds ~~two~~ one internal lint~~s~~:
1. LINT_PASS_IMPL_WITHOUT_MACRO: Make sure, that the `{declare,impl}_lint_pass` macro is used to implement lint passes. cc #59669
2. ~~USAGE_OF_TYCTXT_AND_SPAN_ARGS: item 2 on the list in #49509~~
~~With 2. I wasn't sure, if this lint should be applied everywhere. That means a careful review of 0955835 would be great. Also 73fb9b4 allows this lint on some functions. Should I also apply this lint there?~~
TODO (not directly relevant for review):
- [ ] https://github.com/rust-lang/rust/pull/59316#discussion_r280186517 (not sure yet, if this works or how to query for `rustc_private`, since it's not in [`Features`](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/feature_gate/struct.Features.html) 🤔 cc @eddyb)
- [x] https://github.com/rust-lang/rust/pull/61735#discussion_r292389870
- [x] Check explicitly for the `{declare,impl}_lint_pass!` macros
r? @oli-obk
Add `--pass $mode` to compiletest through `./x.py`
Adds a flag `--pass $mode` to compiletest, which is exposed through `./x.py`.
When `--pass $mode` is passed, `{check,build,compile,run}-pass` tests will be forced to run under the given `$mode` unless the directive `// ignore-pass` exists in the test file.
The modes are explained in https://github.com/rust-lang/rust/pull/61778:
- `check` has the same effect as `cargo check`
- `build` or `compile` have the same effect as `cargo build`
- `run` has the same effect as `cargo run`
On my machine, `./x.py -i test src/test/run-pass --stage 1 --pass check` takes 38 seconds whereas it takes 2 min 7 seconds without `--pass check`.
cc https://github.com/rust-lang/rust/issues/61712
r? @petrochenkov
rustbuild: detect cxx for all targets
Replaces #61544Fixes#59917
We need CXX to build llvm-libunwind which can be enabled for alltargets.
As we needed it for all hosts anyways, just move the detection so that it is ran for all targets (which contains all hosts) instead.
Make use of `ptr::null(_mut)` instead of casting zero
There are few places that I don't replace the zero casting pointer with `ptr::null`
or `ptr::null_mut`:
```bash
% git grep -E '[ ([{]0 as \*'
src/libcore/ptr/mod.rs:216:pub const fn null<T>() -> *const T { 0 as *const T }
src/libcore/ptr/mod.rs:231:pub const fn null_mut<T>() -> *mut T { 0 as *mut T }
src/test/run-pass/consts/const-cast-ptr-int.rs:12:static a: TestStruct = TestStruct{x: 0 as *const u8};
src/test/ui/issues/issue-45730.rs:5: let x: *const _ = 0 as *const _; //~ ERROR cannot cast
src/test/ui/issues/issue-45730.rs:8: let x = 0 as *const i32 as *const _ as *mut _; //~ ERROR cannot cast
src/test/ui/issues/issue-45730.stderr:14:LL | let x: *const _ = 0 as *const _;
src/test/ui/issues/issue-45730.stderr:24:LL | let x = 0 as *const i32 as *const _ as *mut _;
src/test/ui/lint/lint-forbid-internal-unsafe.rs:15: println!("{}", evil!(*(0 as *const u8)));
src/test/ui/order-dependent-cast-inference.rs:5: let mut y = 0 as *const _;
src/test/ui/order-dependent-cast-inference.stderr:4:LL | let mut y = 0 as *const _;
```
r? @sfackler
