| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
RunCompiler::new takes non-optional params, and optional
params can be set using set_*field_name* method.
finally `run` will forward all fields to `run_compiler`.
|
|
Should hopefully fix #78341 and #78340.
|
|
|
|
This will prevent the tool mistakenly ignoring the variables if they
happen to contain non-utf8 data.
|
|
|
|
This commit changes the way build-manifest is invoked, to let it accept
the Rust version directly instead of requiring the path of the Rust
monorepo and letting build-manifest figure out the path on its own.
This allows to run build-manifest without a clone of the monorepo.
|
|
This fixes numbered channel names being created for the nightly channel,
and once the root cause of this rides the trains, for beta.
|
|
The format of the tarballs produced by CI is roughly the following:
{component}-{release}-{target}.{ext}
While on the beta and nightly channels `{release}` is just the channel
name, on the stable channel is either the Rust version or the version of
the component we're shipping:
cargo-0.47.0-x86_64-unknown-linux-gnu.tar.xz
clippy-0.0.212-x86_64-unknown-linux-gnu.tar.xz
llvm-tools-1.46.0-x86_64-unknown-linux-gnu.tar.xz
miri-0.1.0-x86_64-unknown-linux-gnu.tar.xz
rls-1.41.0-x86_64-unknown-linux-gnu.tar.xz
rust-1.46.0-x86_64-unknown-linux-gnu.tar.xz
...
This makes it really hard to get the package URL without having access
to the manifest (and there is no manifest on ci-artifacts.rlo), as there
is no consistent version number to use.
This commit addresses the problem by always using the Rust version
number as `{release}` for the stable channel, regardless of the version
number of the component we're shipping. I chose that instead of "stable"
to avoid breaking the URL scheme *that* much.
Rustup should not be affected by this change, as it fetches the URLs
from the manifest. Unfortunately we don't have a way to test other
clients before making a stable release, as this change only affects the
stable channel.
|
|
Remove `mark-i-m` from rustc-dev-guide maintainers
They aren't a maintainer anymore and it causes failure on our CI now: https://github.com/rust-lang-ci/rust/runs/1243600577
|
|
|
|
|
|
|
|
This avoids overloading the old server, and disrupting the other
programs running on it.
|
|
This commit improves the way build-manifest calculates the checksums
included in the manifest, speeding it up:
* Instead of calculating all the hashes beforehand and then using the
ones we need, the manifest is first generated with placeholder hashes,
and then a function walks through the manifest and calculates only the
needed checksums.
* Calculating the checksums is now done in parallel with rayon, to
better utilize all the available disk bandwidth.
* Calculating the checksums now uses the sha2 crate instead of the
sha256sum CLI tool: this avoids the overhead of calling another
process, but more importantly uses hardware acceleration whenever
available (the CLI tool doesn't support it at all).
|
|
|
|
|
|
|
|
Write manifest for MAJOR.MINOR channel to enable rustup convenience
This connects to https://github.com/rust-lang/rustup/issues/794.
It's hard to remember if there have been patch releases for old versions
when you'd like to install the latest in a MAJOR.MINOR series.
When we're doing a stable release, we write duplicate manifests to
`stable`. With this change, only when we're doing a stable release, also
write duplicate manifests to `MAJOR.MINOR` to eventually enable rustup
(and any other tooling that builds Rust release URLs) to request, say,
`1.45` and get `1.45.2` (assuming `1.45.2` is the latest available
`1.45` and assuming that we never publish patch releases out of order).
I tested the best I could; it's a bit hard to get everything set up right
to be able to run the build-manifest tool. But I was able to run it with
a release of "1.45.2" and in addition to the files like `channel-rust-1.45.2.toml`
and `channel-rust-stable.toml` (and other manifests) that I got before this
change, I now get `channel-rust-1.45.toml`.
I believe this change to be safe to deploy as it does not change or remove
anything about manifests, just adds more. The actions in rust-central-station
that interact with manifests appear to use wildcards in such a way that it will
pick up these files without any problems.
There will need to be changes to `rustup` before `rustup install 1.45` will work,
but we can wait for a stable release and stable patch releases to happen with this
change before making the `rustup` changes, so that we're not committing to anything
before we know it works.
|
|
Rollup of 11 pull requests
Successful merges:
- #76851 (Fix 'FIXME' about using NonZeroU32 instead of u32.)
- #76979 (Improve std::sys::windows::compat)
- #77111 (Stabilize slice_ptr_range.)
- #77147 (Split sys_common::Mutex in StaticMutex and MovableMutex.)
- #77312 (Remove outdated line from `publish_toolstate` hook)
- #77362 (Fix is_absolute on WASI)
- #77375 (rustc_metadata: Do not forget to encode inherent impls for foreign types)
- #77385 (Improve the example for ptr::copy)
- #77389 (Fix some clippy lints)
- #77399 (BTreeMap: use Unique::from to avoid a cast where type information exists)
- #77429 (Link `new` method in `DefautHasher`s doc)
Failed merges:
r? `@ghost`
|
|
Remove outdated line from `publish_toolstate` hook
We no longer add `I-nominated` to toolstate failure issues since T-compiler changed its meeting preparation workflow.
|
|
|
|
* https://github.com/rust-lang/rls/pull/1700
|
|
|
|
This connects to https://github.com/rust-lang/rustup/issues/794.
It's hard to remember if there have been patch releases for old versions
when you'd like to install the latest in a MAJOR.MINOR series.
When we're doing a stable release, we write duplicate manifests to
`stable`. With this change, only when we're doing a stable release, also
write duplicate manifests to `MAJOR.MINOR` to eventually enable rustup
(and any other tooling that builds Rust release URLs) to request, say,
`1.45` and get `1.45.2` (assuming `1.45.2` is the latest available
`1.45` and assuming that we never publish patch releases out of order).
|
|
Update cargo
8 commits in 05c611ae3c4255b7a2bcf4fcfa65b20286a07839..75615f8e69f748d7ef0df7bc0b064a9b1f5c78b2
2020-09-23 23:10:38 +0000 to 2020-09-29 18:42:19 +0000
- Correct mistake about supporting sub-makes and document CARGO_MAKEFLAGS (rust-lang/cargo#8741)
- Properly set for_host for proc-macro tests. (rust-lang/cargo#8742)
- Add Zsh completion for target triples (rust-lang/cargo#8740)
- Reinitialize index on "Object not found" error. (rust-lang/cargo#8735)
- Normalize raw string indentation. (rust-lang/cargo#8739)
- Update links to rustup docs. (rust-lang/cargo#8738)
- Add contributor guide. (rust-lang/cargo#8715)
- Fix minor error in `cargo update` docs. (rust-lang/cargo#8737)
|
|
Defer Apple SDKROOT detection to link time.
This defers the detection of the SDKROOT for Apple iOS/tvOS targets to link time, instead of when the `Target` is defined. This allows commands that don't need to link to work (like `rustdoc` or `rustc --print=target-list`). This also makes `--print=target-list` a bit faster.
This also removes the note in the platform support documentation about these targets being missing. When I wrote it, I misunderstood how the SDKROOT stuff worked.
Notes:
* This means that JSON spec targets can't explicitly override these flags. I think that is probably fine, as I believe the value is generally required, and can be set with the SDKROOT environment variable.
* This changes `x86_64-apple-tvos` to use `appletvsimulator`. I think the original code was wrong (it was using `iphonesimulator`). Also, `x86_64-apple-tvos` seems broken in general, and I cannot build it locally. The `data_layout` does not appear to be correct (it is a copy of the arm64 layout instead of the x86_64 layout). I have not tried building Apple's LLVM to see if that helps, but I suspect it is just wrong (I'm uncertain since I don't know how the tvOS simulator works with its bitcode-only requirements).
* I'm tempted to remove the use of `Result` for built-in target definitions, since I don't think they should be fallible. This was added in https://github.com/rust-lang/rust/pull/34980, but that only relates to JSON definitions. I think the built-in targets shouldn't fail. I can do this now, or not.
Fixes #36156
Fixes #76584
|
|
Ensure that all LLVM components requested by tests are available on CI
Addresses https://github.com/rust-lang/rust/pull/75064#issuecomment-667722652
I used an environment variable because passing a command line option all the way from CI to compiletest would be just too much hassle for this task.
I added a new variable, but any of the already existing ones defined by CI could be used instead.
r? @Mark-Simulacrum
|
|
|
|
|
|
r=Mark-Simulacrum
Refactor versions detection in build-manifest
This PR refactors how `build-manifest` handles versions, making the following changes:
* `build-manifest` now detects the "package releases" on its own, without relying on rustbuild providing them through CLI arguments. This drastically simplifies calling the tool outside of `x.py`, and will allow to ship the prebuilt tool in a tarball in the future, with the goal of stopping to invoke `x.py` during `promote-release`.
* The `tar` command is not used to extract the version and the git hash from tarballs anymore. The `flate2` and `tar` crates are used instead. This makes detecting those pieces of data way faster, as the archive is decompressed just once and we stop parsing the archive once all the information is retrieved.
* The code to extract the version and the git hash now stores all the collected data dynamically, without requiring to add new fields to the `Builder` struct every time.
I tested the changes locally and it should behave the same as before.
r? `@Mark-Simulacrum`
|
|
|
|
Add option to pass a custom codegen backend from a driver
This allows the driver to pass information to the codegen backend. For example the headcrab debugger may in the future want to use cg_clif to JIT code to be injected in the debuggee. This would PR make it possible to tell cg_clif which symbol can be found at which address and to tell it to inject the JITed code into the right process.
This PR may also help with https://github.com/rust-lang/miri/pull/1540 by allowing miri to provide a codegen backend that only emits metadata and doesn't perform any codegen.
cc @nbaksalyar (headcrab)
cc @RalfJung (miri)
|
|
|
|
might_permit_raw_init: also check aggregate fields
This is the next step for https://github.com/rust-lang/rust/issues/66151: when doing `mem::zeroed`/`mem::uninitialized`, also recursively check fields of aggregates (except for arrays) for whether they permit zero/uninit initialization.
|
|
|
|
Move helper function for `missing_const_for_fn` out of rustc to clippy
cc @rust-lang/clippy @ecstatic-morse #76618
r? @Manishearth
I also removed all support for suggesting a function could be `const fn` when that would require feature gates to actually work.
This means we'll now have to maintain this ourselves in clippy, but that's how most lints work anyway, so...
|
|
Update cargo
7 commits in 8777a6b1e8834899f51b7e09cc9b8d85b2417110..05c611ae3c4255b7a2bcf4fcfa65b20286a07839
2020-09-15 19:11:03 +0000 to 2020-09-23 23:10:38 +0000
- --workspace flag for locate-project to find the workspace root (rust-lang/cargo#8712)
- Remove some badges documentation. (rust-lang/cargo#8727)
- Add plain message format for locate-project (rust-lang/cargo#8707)
- Add a term option to configure the progress bar (rust-lang/cargo#8165)
- Replace d_as_f64 with as_secs_f64 (rust-lang/cargo#8721)
- Add cross check to filters_target test. (rust-lang/cargo#8713)
- Add test for whitespace behavior in env flags. (rust-lang/cargo#8706)
|
|
|
|
|
|
update Miri
Fixes https://github.com/rust-lang/rust/issues/77130
|
|
Update mdBook
0.4.2 -> 0.4.3
Also updated version requirement in `Cargo.toml` from 0.4.0 to 0.4.3.
|
|
I misunderstood how this works, and I have fixed the linux builds
to support ios/tvos.
|
|
|
|
Update Clippy
Bi-weekly Clippy update.
This includes a `Cargo.lock` update (d445493479711389f4dea3a0f433041077ba2088), so probably needs `rollup=never`.
r? `@Manishearth`
|
|
Allow a unique name to be assigned to dataflow graphviz output
Previously, if the same analysis were invoked multiple times in a single compilation session, the graphviz output for later runs would overwrite that of previous runs. Allow callers to add a unique identifier to each run so this can be avoided.
|
|
|
|
|
|
|
|
|
