Rollup merge of #74450 - aticu:master, r=jonas-schievink
Fix `Safety` docs for `from_raw_parts_mut`
This aligns the wording more with the documentation of e.g. `drop_in_place`, `replace`, `swap` and `swap_nonoverlapping` from `core::ptr`.
Also if the pointer were really only valid for writes, it would be trivial to introduce UB from safe code, after calling `core::slice::from_raw_parts_mut`.
Rollup merge of #74441 - eddyb:zlib-on-nixos, r=nagisa
bootstrap.py: patch RPATH on NixOS to handle the new zlib dependency.
This is a stop-gap until #74420 is resolved (assuming we'll patch beta to statically link zlib).
However, I've been meaning to rewrite the NixOS support we have in `bootstrap.py` for a while now, and had to in order to cleanly add zlib as a dependency (the second commit is a relatively small delta in functionality, compared to the first).
Previously, we would extract the `ld-linux.so` path from the output of `ldd /run/current-system/sw/bin/sh`, which assumes a lot. On top of that we didn't use any symlinks, which meant if the user ran GC (`nix-collect-garbage`), e.g. after updating their system, their `stage0` binaries would suddenly be broken (i.e. referring to files that no longer exist).
We were also using `patchelf` directly, assuming it can be found in `$PATH` (which is not necessarily true).
My new approach relies on using `nix-build` to get the following "derivations" (packages, more or less):
* `stdenv.cc.bintools`, which has a `nix-support/dynamic-linker` file containing the path to `ld-linux.so`
* reading this file is [the canonical way to run `patchelf --set-interpreter`](https://github.com/NixOS/nixpkgs/search?l=Nix&q=%22--set-interpreter+%24%28cat+%24NIX_CC%2Fnix-support%2Fdynamic-linker%29%22)
* `patchelf` (so that the user doesn't need to have it installed)
* `zlib`, for the `libz.so` dependency of `libLLVM-*.so` (until #74420 is resolved, presumably)
This is closer to how software is built on Nix, but I've tried to keep it as simple as possible (and not add e.g. a `stage0.nix` file).
Symlinks to each of those dependencies are kept in `stage0/.nix-deps`, which prevents GC from invalidating `stage0` binaries.
r? @nagisa cc @Mark-Simulacrum @oli-obk @davidtwco
Rollup merge of #74418 - rye:gha-dedup-shell-setting, r=pietroalbini
ci: Set `shell: bash` as a default, remove duplicates
A follow-up to #74406, this commit merely removes the `shell: bash` lines where they were added in favor of setting defaults for *all* "run" steps in the jobs that run the tests.
The changes in #74406 were needed because of an upstream change to the `windows-2019` GitHub Actions image. Previously, the configuration worked fine without specifying `shell: bash`, but for some reason this broke with a new change that was deployed today. The preceding PR was a hotfix to get CI passing, but there was a slightly less duplicative way to specify the default shell for the jobs, which was to set the `defaults.run` option.
This change applies to the `pr`, `try`, `auto`, and `auto-fallible` jobs, which are derived from the YAML-anchor `base-ci-job`. I did not apply these changes to the `master`, `try-success`, `try-failure`, `auto-success`, or `auto-failure` jobs because they have only a few steps.
Rollup merge of #72414 - KodrAus:feat/stdlazy, r=Mark-Simulacrum
Add lazy initialization primitives to std
Follow-up to #68198
Current RFC: https://github.com/rust-lang/rfcs/pull/2788
Rebased and fixed up a few of the dangling comments. Some notes carried over from the previous PR:
- [ ] Naming. I'm ok to just roll with the `Sync` prefix like `SyncLazy` for now, but [have a personal preference for `Atomic`](https://github.com/rust-lang/rfcs/pull/2788#issuecomment-574466983) like `AtomicLazy`.
- [x] [Poisoning](https://github.com/rust-lang/rfcs/pull/2788#discussion_r366725768). It seems like there's [some regret around poisoning in other `std::sync` types that we might want to just avoid upfront for `std::lazy`, especially if that would align with a future `std::mutex` that doesn't poison](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/parking_lot.3A.3AMutex.20in.20std/near/190331199). Personally, if we're adding these types to `std::lazy` instead of `std::sync`, I'd be on-board with not worrying about poisoning in `std::lazy`, and potentially deprecating `std::sync::Once` and `lazy_static` in favour of `std::lazy` down the track if it's possible, rather than attempting to replicate their behavior. cc @Amanieu @sfackler.
- [ ] [Consider making`SyncOnceCell::get` blocking](https://github.com/matklad/once_cell/pull/92). There doesn't seem to be consensus in the linked PR on whether or not that's strictly better than the non-blocking variant.
In general, none of these seem to be really blocking an initial unstable merge, so we could possibly kick off a FCP if y'all are happy?
cc @matklad @pitdicker have I missed anything, or were there any other considerations that have come up since we last looked at this?
Rollup merge of #74440 - Abendstolz:patch-1, r=hanna-kruppe
Fix Arc::as_ptr docs
As a non-native speaker I stumbled upon this, looked it up and couldn't find a phrase, so I made my own assumption that "in any way" was meant (which is the meaning I would've deduced anyway)
Rollup merge of #74424 - sexxi-goose:move_hir_place, r=nikomatsakis
Move hir::Place to librustc_middle/hir
Needed to support https://github.com/rust-lang/project-rfc-2229/issues/7
Currently rustc_typeck depends on rustc_middle for definition TypeckTables, etc.
For supporting project-rfc-2229#7, rustc_middle would've to depend on
rustc_typeck for Place -- introducing a circular dependency.
This resembles the MIR equivalent of `Place` located in `lbrustc_middle/mir`.
Separate PR for this move will make the actual PR for using Places to represent captures cleaner/more focused.
Rollup merge of #74251 - shepmaster:bootstrap-target-files, r=Mark-Simulacrum
Teach bootstrap about target files vs target triples
`rustc` allows passing in predefined target triples as well as JSON
target specification files. This change allows bootstrap to have the
first inkling about those differences. This allows building a
cross-compiler for an out-of-tree architecture (even though that
compiler won't work for other reasons).
Even if no one ever uses this functionality, I think the newtype
around the `Interned<String>` improves the readability of the code.
Rollup merge of #74169 - ecstatic-morse:dataflow-unreachable, r=pnkfelix
Stop processing unreachable blocks when solving dataflow
...instead we `debug_assert` that the user is not checking the dataflow state for an unreachable block. This resolves a FIXME in the dataflow engine. The old behavior was an artifact of the previous dataflow framework. Things should run a tiny bit faster now, but I suspect not enough to show up in benchmarks. AFAIK, only the generator transform runs dataflow on MIR with unreachable basic blocks.
This PR also adds some utility methods to `mir::traversal`.
Rollup merge of #74056 - fusion-engineering-forks:fmt-arguments-as-str, r=Amanieu
Add Arguments::as_str().
There exist quite a few macros in the Rust ecosystem which use `format_args!()` for formatting, but special case the one-argument case for optimization:
```rust
#[macro_export]
macro_rules! some_macro {
($s:expr) => { /* print &str directly, no formatting, no buffers */ };
($s:expr, $($tt:tt)*) => { /* use format_args to write to a buffer first */ }
}
```
The problem with these is that a forgotten argument such as in `some_macro!("{}")` will not be diagnosed, but just prints `"{}"`.
With this PR, it is possible to handle the no-arguments case separately *after* `format_args!()`, while simplifying the macro. Then these macros can give the proper error about a missing argument, just like `print!("{}")` does, while still using the same optimized implementation as before.
This is even more important with [RFC 2795](https://github.com/rust-lang/rfcs/pull/2795), to make sure `some_macro!("{some_variable}")` works as expected.
Rollup merge of #74009 - mati865:mingw-tests-implib, r=nikomatsakis
Fix MinGW `run-make-fulldeps` tests
`compiler-rt-works-on-mingw` and `libs-search-path` were not ran because `only-mingw` doesn't match any target.
Enabled and verified few ignored tests with `windows-gnu` toolchain. They are still ignored on MSVC since I'm not experienced with this target.
Rollup merge of #73930 - a1phyr:feature_const_option, r=dtolnay
Make some Option methods const
Tracking issue: #67441
Constantify the following methods of `Option`:
- `as_ref`
- `is_some`
- `is_none`
- `iter` (not sure about this one, but it is possible, and will be useful when const traits are a thing)
Rollup merge of #71670 - GuillaumeGomez:enforce-codeblocks-attribute-check, r=Mark-Simulacrum
Enforce even more the code blocks attributes check through rustdoc
`rustdoc` now has a lint which allows it to warn if a code block attribute is malformated (which can end up in bad situations, even more in case of testing examples!). Now it'll fail if such a situation is encountered when testing markdown code blocks examples.
When ran on Windows `cp` will follow symlink: `checkout/build/<target>/<stage>/lib/rustlib/src/rust`.
It points to `checkout` which means the test will get stuck in copying loop until there is no space left.
Teach bootstrap about target files vs target triples
`rustc` allows passing in predefined target triples as well as JSON
target specification files. This change allows bootstrap to have the
first inkling about those differences. This allows building a
cross-compiler for an out-of-tree architecture (even though that
compiler won't work for other reasons).
Even if no one ever uses this functionality, I think the newtype
around the `Interned<String>` improves the readability of the code.
ci: Replace exec-with-shell wrapper with "plain bash"
Also, promote defaults.run.shell from inside only the primary jobs to
the top level.
The src/ci/exec-with-shell.py wrapper script was formerly used to change
out the shell mid-job by intercepting a CI_OVERRIDE_SHELL environment
variable. Now, instead, we just set `bash` as the global default across
all jobs, and we also delete the exec-with-shell.py script.
As a none-native speaker I stumbled upon this, looked it up and couldn't find a phrase, so I made my own assumption that "in any way" was meant (which is the meaning I would've deduced anyway)
Auto merge of #73365 - Manishearth:rustdoc-vis, r=GuillaumeGomez
Record visibility of reexports for all items, not just type items
This fixes https://github.com/rust-lang/rust/issues/73363
Unfortunately I can't add a test for this since this bug is obscured by the cross-crate bug, being fixed in https://github.com/rust-lang/rust/issues/73363 . Tests will be added later.
Auto merge of #74395 - Mark-Simulacrum:stage0-next, r=pietroalbini
Bump version to 1.47
This also bumps to a more recent rustfmt version, just to keep us relatively up to date (though almost nothing has changed in rustfmt we use beyond bumps to the parser infra). No formatting changes as a result of this.
Auto merge of #74422 - Manishearth:rollup-7mfrf6g, r=Manishearth
Rollup of 8 pull requests
Successful merges:
- #73101 (Resolve items for cross-crate imports relative to the original module)
- #73269 (Enable some timeouts in SGX platform)
- #74033 (Add build support for Cargo's build-std feature.)
- #74351 (Do not render unstable items for rustc doc)
- #74357 (Some `Symbol` related improvements)
- #74371 (Improve ayu rustdoc theme)
- #74386 (Add RISC-V GNU/Linux to src/tools/build-manifest as a host platform)
- #74398 (Clean up E0723 explanation)
Rollup merge of #74371 - Aloso:patch-1, r=GuilliameGomez
Improve ayu rustdoc theme
This PR changes the following:
* It makes some lines darker
* It gives the crate selector and search bar a border
* The search bar's border turns blue when focused
* ~~Gives the logo a bright shadow.~~
For standard library crates, it would be better to invert the logo, but that would be bad for crates with a colored logo, e.g. [async-std](https://docs.rs/async-std/1.6.2/async_std/).
Rollup merge of #74351 - lzutao:remove-rustc-internal-compiler-warns, r=Mark-Simulacrum
Do not render unstable items for rustc doc
See the zulip conversion: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/rustc.20doc.3A.20.22internal.20compiler.20API.22.20warns.20are.20everywhere!/near/203850782
Rollup merge of #74033 - ehuss:std-compile-all-platforms, r=Mark-Simulacrum
Add build support for Cargo's build-std feature.
This makes some changes to the standard library to make it easier to use with Cargo's build-std feature. The primary goal is to make it so that Cargo and its users do not need to know which crates to build and which features to use for every platform.
Conditional cfgs are adjusted so that there is usually a fall-through for unsupported platforms. Additionally, there is a "restricted-std" feature to mark `std` as unstable when used with build-std on no_std platforms. There is no intent to stabilize this feature for the foreseeable future.
This borrows some of the implementation for wasm which already does what this needs. More code sharing can be done with some other platforms (there is a lot of duplication with cloudabi, hermit, and sgx), but I figure that can be done in a future PR.
There are some small changes to stable behavior in this PR:
- `std::env::consts::ARCH` on asmjs now reports "wasm32", to match its actual architecture.
- Some of the wasm error messages for unsupported features report a slightly different error message so that the code can be reused.
There should otherwise not be any changes to how std is built for distribution via bootstrap.
This does not yet support all platforms when used with build-std.
- It doesn't work with 16-bit targets (hashbrown does not support that).
- It does not work with JSON spec targets.
- In particular, all target triple snooping will need to be replaced with appropriate target option checking.
- Switching to gimli (#73441) will make cross-building *much* easier.
- There are still a ton of issues on the Cargo side to resolve. A big one is panic strategy support.
Future PRs are intended to address some of these issues.
ci: Set `shell: bash` as a default, remove duplicates
A follow-up to #74406, this commit merely removes the `shell: bash`
lines where they are explicitly added in favor of setting defaults for
*all* "run" steps.
Aman Arora [Mon, 6 Jul 2020 02:06:37 +0000 (22:06 -0400)]
Move hir::Place to librustc_middle/hir
Needed to support https://github.com/rust-lang/project-rfc-2229/issues/7
Currently rustc_typeck depends on rustc_middle for definition TypeckTables, etc.
For supporting project-rfc-2229#7, rustc_middle would've to depend on
rustc_typeck for Place -- introducing a circular dependcy.
This resembles the MIR equivalent of `Place` located in `lbrustc_middle/mir`.
Co-authored-by: Aman Arora <me@aman-arora.com> Co-authored-by: Jennifer Wills <wills.jenniferg@gmail.com> Co-authored-by: Logan Mosier <logmosier@gmail.com>
This replaces the need for the `description` and `details` symbols in
`UnsafetyViolation`, which are static. As a result some
`Symbol::as_str()` calls are no longer necessary, which is nice.
It's equivalent to `Ident::from_str_and_span`. The commit also
introduces some more static symbols so that `Ident::new` can be used in
various places instead of `Ident::from_str_and_span`.
The commit also changes `Path::path` from a `&str` to a `Symbol`, which
then allows the lifetime annotation to be removed from `Ty`. Also, the
use of `Symbol` in `Bounds` removes the need for its lifetime
annotation.
projects / rust.git / log