Rollup of 8 pull requests
Successful merges:
- #62644 (simplify std::io::Write::write rustdoc)
- #62971 (Add keywords item into the sidebar)
- #63122 (Account for `maybe_whole_expr` in range patterns)
- #63158 (Add test for issue-58951)
- #63170 (cleanup StringReader fields)
- #63179 (update test cases for vxWorks)
- #63188 (Fix typos in release notes.)
- #63191 (ci: fix toolstate not pushing data for Linux)
Failed merges:
r? @ghost
simplify std::io::Write::write rustdoc
The std::io::Write::write method currensly suggests consumers guaranteed
that `0 <= n <= buf.len()`, for `Ok(n)`, however `n` is of type `usize`
causing the compiler to emit a warning:
```
warning: comparison is useless due to type limits
--> lib.rs:6:18
|
6 | Ok(n) => 0 <= n && n <= output.len(),
| ^^^^^^
|
= note: #[warn(unused_comparisons)] on by default
```
This PR removes the suggestion to check `0 <= n` since it is moot.
r? @steveklabnik
Remove derives `Encodable`/`Decodable` and unstabilize attribute `#[bench]`
`Encodable` and `Decodable` were deprecated before 1.0 and emitted an unsuppressable warning all this time.
`#[bench]` is a part of the custom test framework feature and cannot be used meaningfully on stable, only as `cfg(false)`.
Crater results can be found in https://github.com/rust-lang/rust/pull/62507#issuecomment-513850732 and below.
This PR also reroutes the tracking issue for `feature(test)` from #27812 (compiler internals) to #50297 (custom test frameworks).
Closes https://github.com/rust-lang/rust/issues/62048
Some fixes for i686-msvc and Windows have landed on the `backtrace`
crate but hadn't made their way here yet. Let's update that and see if
it passes CI.
std: Fix a failing `fs` test on Windows
In testing 4-core machines on Azure the `realpath_works_tricky` test in
the standard library is failing with "The directory name is invalid". In
attempting to debug this test I was able to reproduce the failure
locally on my machine, and after inspecing the test it I believe is
exploiting Unix-specific behavior that seems to only sometimes work on
Windows. Specifically the test basically executes:
mkdir -p a/b
mkdir -p a/d
touch a/f
ln -s a/b/c ../d/e
ln -s a/d/e ../f
and then asserts that `canonicalize("a/b/c")` and
`canonicalize("a/d/e")` are equivalent to `a/f`. On Windows however the
first symlink is a "directory symlink" and the second is a file symlink.
In both cases, though, they're pointing to files. This means that for
whatever reason locally and on the 4-core environment the call to
`canonicalize` is failing. On Azure today it seems to be passing, and
I'm not entirely sure why. I'm sort of presuming that there's some sort
of internals going on here where there's some global Windows setting
which makes symlinks behavior more unix-like and ignore the directory
hint.
In any case this should keep the test working and also fixes the test
locally for me. It's also worth pointing out that this test was made Windows compatible in https://github.com/rust-lang/rust/pull/31360, a pretty ancient PR at this point.
In testing 4-core machines on Azure the `realpath_works_tricky` test in
the standard library is failing with "The directory name is invalid". In
attempting to debug this test I was able to reproduce the failure
locally on my machine, and after inspecing the test it I believe is
exploiting Unix-specific behavior that seems to only sometimes work on
Windows. Specifically the test basically executes:
mkdir -p a/b
mkdir -p a/d
touch a/f
ln -s a/b/c ../d/e
ln -s a/d/e ../f
and then asserts that `canonicalize("a/b/c")` and
`canonicalize("a/d/e")` are equivalent to `a/f`. On Windows however the
first symlink is a "directory symlink" and the second is a file symlink.
In both cases, though, they're pointing to files. This means that for
whatever reason locally and on the 4-core environment the call to
`canonicalize` is failing. On Azure today it seems to be passing, and
I'm not entirely sure why. I'm sort of presuming that there's some sort
of internals going on here where there's some global Windows setting
which makes symlinks behavior more unix-like and ignore the directory
hint.
In any case this should keep the test working and also fixes the test
locally for me.
rustc: Update wasm32 support for LLVM 9
This commit brings in a number of minor updates for rustc's support for
the wasm target which has changed in the LLVM 9 update. Notable updates
include:
* The compiler now no longer manually inserts the `producers` section,
instead relying on LLVM to do so. LLVM uses the `llvm.ident` metadata
for the `processed-by` directive (which is now emitted on the wasm
target in this PR) and it uses debuginfo to figure out what `language`
to put in the `producers` section.
* Threaded WebAssembly code now requires different flags to be passed
with LLD. In LLD we now pass:
* `--shared-memory` - required since objects are compiled with
atomics. This also means that the generated memory will be marked as
`shared`.
* `--max-memory=1GB` - required with the `--shared-memory` argument
since shared memories in WebAssembly must have a maximum size. The
1GB number is intended to be a conservative estimate for rustc, but
it should be overridable with `-C link-arg` if necessary.
* `--passive-segments` - this has become the default for multithreaded
memory, but when compiling a threaded module all data segments need
to be marked as passive to ensure they don't re-initialize memory
for each thread. This will also cause LLD to emit a synthetic
function to initialize memory which users will have to arrange to
call.
* The `__heap_base` and `__data_end` globals are explicitly exported
since they're now hidden by default due to the `--export` flags we
pass to LLD.
Rollup of 8 pull requests
Successful merges:
- #61856 (Lint attributes on function arguments)
- #62360 (Document that ManuallyDrop::drop should not called more than once)
- #62392 (Update minifier-rs version)
- #62871 (Explicit error message for async recursion.)
- #62995 (Avoid ICE when suggestion span is at Eof)
- #63053 (SystemTime docs: recommend Instant for elapsed time)
- #63081 (tidy: Cleanup the directory whitelist)
- #63088 (Remove anonymous_parameters from unrelated test)
Failed merges:
r? @ghost
SystemTime docs: recommend Instant for elapsed time
Introduction to `SystemTime` mentions problems with non-monotonic clocks, but individual methods don't.
For benefit of users who jump directly to method's documentation, also recommend `Instant` in `elapsed` and `duration_since`.
`SystemTime::elapsed()` docs overpromised the elapsed time. It's not elapsed time, but a difference between two clocks.
add `repr(transparent)` to `IoSliceMut` where missing
tried using `IoSliceMut` in FFI, got `improper_ctypes` warning.
according to the docs: `IoSliceMut` is "guaranteed to be ABI compatible with the `iovec` type" so it should be usable in FFI.
`IoSlice` is also `repr(transparent)` for every platform where these types contain `iovec`-like types.
vxworks also has `IoSliceMut` as transparent so its not even consistently one or the other.
no comment about this next to the types or in the PR that introduced the types, so assuming this was just missed.
r? @sfackler
Define built-in macros through libcore
This PR defines built-in macros through libcore using a scheme similar to lang items (attribute `#[rustc_builtin_macro]`).
All the macro properties (stability, visibility, etc.) are taken from the source code in libcore, with exception of the expander function transforming input tokens/AST into output tokens/AST, which is still provided by the compiler.
The macros are made available to user code through the standard library prelude (`{core,std}::prelude::v1`), so they are still always in scope.
As a result **built-in macros now have stable absolute addresses in the library**, like `core::prelude::v1::line!()`, this is an insta-stable change.
Right now `prelude::v1` is the only publicly available absolute address for these macros, but eventually they can be moved into more appropriate locations with library team approval (e.g. `Clone` derive -> `core::clone::Clone`).
Now when built-in macros have canonical definitions they can be imported or reexported without issues (https://github.com/rust-lang/rust/issues/61687).
Other changes:
- You can now define a derive macro with a name matching one of the built-in derives (https://github.com/rust-lang/rust/issues/52269). This was an artificial restriction that could be worked around with import renaming anyway.
Known regressions:
- Empty library crate with a crate-level `#![test]` attribute no longer compiles without `--test`. Previously it didn't compile *with* `--test` or with the bin crate type.
Fixes https://github.com/rust-lang/rust/issues/61687
Fixes https://github.com/rust-lang/rust/issues/61804
r? @eddyb
std: Add more accessors for `Metadata` on Windows
This commit adds accessors for more fields in `fs::Metadata` on Windows
which weren't previously exposed. There's two sources of `fs::Metadata`
on Windows currently, one from `DirEntry` and one from a file itself.
These two sources of information don't actually have the same set of
fields exposed in their stat information, however. To handle this the
platform-specific accessors of Windows-specific information all return
`Option` to return `None` in the case a metadata comes from a
`DirEntry`, but they're guaranteed to return `Some` if it comes from a
file itself.
This is motivated by some changes in CraneStation/wasi-common#42, and
I'm curious how others feel about this platform-specific functionality!
This commit adds accessors for more fields in `fs::Metadata` on Windows
which weren't previously exposed. There's two sources of `fs::Metadata`
on Windows currently, one from `DirEntry` and one from a file itself.
These two sources of information don't actually have the same set of
fields exposed in their stat information, however. To handle this the
platform-specific accessors of Windows-specific information all return
`Option` to return `None` in the case a metadata comes from a
`DirEntry`, but they're guaranteed to return `Some` if it comes from a
file itself.
This is motivated by some changes in CraneStation/wasi-common#42, and
I'm curious how others feel about this platform-specific functionality!
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: https://github.com/mirror/mingw-w64/commit/e8c433c871687a78408ae9b40ab7776577db908d#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,
Rollup of 15 pull requests
Successful merges:
- #60066 (Stabilize the type_name intrinsic in core::any)
- #60938 (rustdoc: make #[doc(include)] relative to the containing file)
- #61884 (Stablize Euclidean Modulo (feature euclidean_division))
- #61890 (Fix some sanity checks)
- #62528 (Add joining slices of slices with a slice separator, not just a single item)
- #62707 (Add tests for overlapping explicitly dropped locals in generators)
- #62735 (Turn `#[global_allocator]` into a regular attribute macro)
- #62822 (Improve some pointer-related documentation)
- #62887 (Make the parser TokenStream more resilient after mismatched delimiter recovery)
- #62921 (Add method disambiguation help for trait implementation)
- #62930 (Add test for #51559)
- #62942 (Use match ergonomics in Condvar documentation)
- #62977 (Fix inconsistent highlight blocks.)
- #62978 (Remove `cfg(bootstrap)` code for array implementations)
- #62981 (Add note suggesting to borrow a String argument to find)
Failed merges:
- #62964 (clarify and unify some type test names)
r? @ghost
Use match ergonomics in Condvar documentation
Documentation was written before match ergonomics was merged. See #62857.
In short, replaces
```rust
let &(ref lock, ref cvar) = &*pair;
```
with
```rust
let (lock, cvar) = &*pair
```
in the docs of `std::sync::Condvar`.
Attempt to create sockets with the WSA_FLAG_NO_HANDLE_INHERIT flag, and
handle the potential error gracefully (as the flag isn't support on
Windows 7 before SP1)
Rename .cap() methods to .capacity()
As mentioned in #60316, there are a few `.cap()` methods, which seem out-of-place because such methods are called `.capacity()` in the rest of the code.
This PR renames them to `.capacity()` but leaves `RawVec::cap()` in there for backwards compatibility.
I didn't try to mark the old version as "deprecated", because I guess this would cause too much noise.
Mazdak Farrokhzad