| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Tracking issue: https://github.com/rust-lang/rust/issues/49137
|
|
|
|
Don't unconditionally set CLOEXEC twice on every fd we open on Linux
Previously, every `open64` was accompanied by a `ioctl(…, FIOCLEX)`,
because some old Linux version would ignore the `O_CLOEXEC` flag we pass
to the `open64` function.
Now, we check whether the `CLOEXEC` flag is set on the first file we
open – if it is, we won't do extra syscalls for every opened file. If it
is not set, we fall back to the old behavior of unconditionally calling
`ioctl(…, FIOCLEX)` on newly opened files.
On old Linuxes, this amounts to one extra syscall per process, namely
the `fcntl(…, F_GETFD)` call to check the `CLOEXEC` flag.
On new Linuxes, this reduces the number of syscalls per opened file by
one, except for the first file, where it does the same number of
syscalls as before (`fcntl(…, F_GETFD)` to check the flag instead of
`ioctl(…, FIOCLEX)` to set it).
|
|
|
|
|
|
|
|
|
|
|
|
Previously, every `open64` was accompanied by a `ioctl(…, FIOCLEX)`,
because some old Linux version would ignore the `O_CLOEXEC` flag we pass
to the `open64` function.
Now, we check whether the `CLOEXEC` flag is set on the first file we
open – if it is, we won't do extra syscalls for every opened file. If it
is not set, we fall back to the old behavior of unconditionally calling
`ioctl(…, FIOCLEX)` on newly opened files.
On old Linuxes, this amounts to one extra syscall per process, namely
the `fcntl(…, F_GETFD)` call to check the `CLOEXEC` flag.
On new Linuxes, this reduces the number of syscalls per opened file by
one, except for the first file, where it does the same number of
syscalls as before (`fcntl(…, F_GETFD)` to check the flag instead of
`ioctl(…, FIOCLEX)` to set it).
|
|
|
|
|
|
This is recommend by [RFC 0505] and as far as I know, the only primitive
types without this heading.
[RFC 0505]: https://github.com/rust-lang/rfcs/blob/c892139be692586e0846fbf934be6fceec17f329/text/0505-api-comment-conventions.md#using-markdown
|
|
Generate an IO error if the offset is out of bounds for the system call.
|
|
|
|
Update canonicalize docs
I was recently working with file-paths in Rust, and I felt let down by the `std::fs::canonicalize` docs, so I figured I should submit a PR with some suggestions.
I was looking for a method to turn a relative path into an absolute path. The `canonicalize` docs didn't mention the words "relative" or "absolute", but they did mention resolving symlinks (which is a kind of canonicalisation and does not imply converting to absolute), so I assumed that's all it did. To remedy this, I've added the word "absolute" to the description of both `std::fs::canonicalize` and `std::path::Path::canonicalize`.
After calling `canonicalize` on Windows, I ran into a bunch of other problems I would not have expected from the function's behaviour on Linux. Specifically, if you call `canonicalize` on a path:
- it's allowed to be much longer than it otherwise would
- `.join("a/slash/delimited/path")` gives you a broken path that Windows can't use, where the same operation would have worked perfectly without `canonicalize` (if the path were short enough)
- the resulting path may confuse other Windows programs if you pass it to them on the command-line, or write it to a config file that they read, etc.
...so I tried to summarize those behaviours too.
If I understand correctly, those behaviours are a side-effect of calling `GetFinalPathNameByHandle`, and the documentation says `canonicalize` might not call that function in future, so maybe those side-effects shouldn't be part of the function's documentation. However, I bet there's a lot of applications deliberately calling `canonicalize` just for the path-length-extension alone, so that particular side-effect is de-facto part of the `canonicalize` interface.
|
|
use fmt::Result where applicable
This is a quite boring PR, but I think the type alias improves readability, so why not use it?
|
|
Rollup of 18 pull requests
Successful merges:
- #49423 (Extend tests for RFC1598 (GAT))
- #50010 (Give SliceIndex impls a test suite of girth befitting the implementation (and fix a UTF8 boundary check))
- #50447 (Fix update-references for tests within subdirectories.)
- #50514 (Pull in a wasm fix from LLVM upstream)
- #50524 (Make DepGraph::previous_work_products immutable)
- #50532 (Don't use Lock for heavily accessed CrateMetadata::cnum_map.)
- #50538 ( Make CrateNum allocation more thread-safe. )
- #50564 (Inline `Span` methods.)
- #50565 (Use SmallVec for DepNodeIndex within dep_graph.)
- #50569 (Allow for specifying a linker plugin for cross-language LTO)
- #50572 (Clarify in the docs that `mul_add` is not always faster.)
- #50574 (add fn `into_inner(self) -> (Idx, Idx)` to RangeInclusive (#49022))
- #50575 (std: Avoid `ptr::copy` if unnecessary in `vec::Drain`)
- #50588 (Move "See also" disambiguation links for primitive types to top)
- #50590 (Fix tuple struct field spans)
- #50591 (Restore RawVec::reserve* documentation)
- #50598 (Remove unnecessary mutable borrow and resizing in DepGraph::serialize)
- #50606 (Retry when downloading the Docker cache.)
Failed merges:
- #50161 (added missing implementation hint)
- #50558 (Remove all reference to DepGraph::work_products)
|
|
Map the stack guard page with max protection on NetBSD
On NetBSD the initial mmap() protection of a mapping can not be made
less restrictive with mprotect().
So when mapping a stack guard page, use the maximum protection
we ever want to use, then mprotect() it to the permission we
want it to have initially.
Fixes #50313
|
|
Move "See also" disambiguation links for primitive types to top
Closes #50384.
<details>
<summary>Images</summary>
</details>
r? @steveklabnik
|
|
Clarify in the docs that `mul_add` is not always faster.
Fixes https://github.com/rust-lang/rust/issues/49842.
Other resources:
- https://users.rust-lang.org/t/why-does-the-mul-add-method-produce-a-more-accurate-result-with-better-performance/1626
- https://en.wikipedia.org/wiki/Multiply%E2%80%93accumulate_operation
|
|
|
|
|
|
also make a drive-by typo fix
|
|
|
|
Fixes https://github.com/rust-lang/rust/issues/49842.
Other resources:
- https://users.rust-lang.org/t/why-does-the-mul-add-method-produce-a-more-accurate-result-with-better-performance/1626
- https://en.wikipedia.org/wiki/Multiply%E2%80%93accumulate_operation
|
|
Add some explanations for #[must_use]
`#[must_use]` can be given a string argument which is shown whilst warning for things.
We should add a string argument to most of the user-exposed ones.
I added these for everything but the operators, mostly because I'm not sure what to write there or if we need anything there.
|
|
Mention Result<!, E> in never docs.
Fixes #48096.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
These are unstable, and were deprecated by #47510, since Rust 1.25. The
internal `sys` implementations are still kept to support the call in the
common `resolve_socket_addr`.
|
|
Forbid constructing empty identifiers from concat_idents
The empty identifier is a [reserved identifier](https://github.com/rust-lang/rust/blob/8a37c75a3a661385cc607d934c70e86a9eaf5fd7/src/libsyntax_pos/symbol.rs#L300-L305) in rust, apparently used for black magicks like representing the crate root or somesuch... and therefore, being able to construct it is Ungood. Presumably.
...even if the macro that lets you construct it is so useless that you can't actually do any damage with it. (and believe me, I tried)
Fixes #50403.
**Note:** I noticed that when you try to do something similar with `proc_macro::Term`, the compiler actually catches it and flags the identifier as reserved. Perhaps a better solution would be to somehow have that same check applied here.
|
|
|
|
This reverts commit 05a9acc3b844ff284a3e3d85dde2d9798abfb215.
|
|
While currently only NetBSD seems to be affected, all systems
implementing PAX MPROTECT in strict mode need this treatment,
and it does not hurt others.
|
|
|
|
It's subsumed by `feature(use_extern_macros)` and `pub use`
|
|
stabilize `#[must_use]` for functions and must-use comparison operators (RFC 1940)
r? @nikomatsakis
|
|
Rollup of 7 pull requests
Successful merges:
- #50233 (Make `Vec::new` a `const fn`)
- #50312 (Add more links in panic docs)
- #50316 (Fix some broken links in docs.)
- #50325 (Add a few more tests for proc macro feature gating)
- #50327 (Display correct unused field suggestion for nested struct patterns)
- #50330 (check that #[used] is used only on statics)
- #50344 (Update Cargo to 2018-04-28 122fd5be5201913d42e219e132d6569493583bca)
Failed merges:
|
|
Fix some broken links in docs.
|
|
Add more links in panic docs
Fixes #48695 by adding a link to `AssertUnwindSafe`. Also added some other links in the module's docs to make things clearer.
|
|
Bury Error::description()
Second attempt of #49536 https://github.com/rust-lang/rfcs/pull/2230
The exact wording of the default implementation is still up in the air, but I think it's a detail that can be amended later.
|
|
On NetBSD the initial mmap() protection of a mapping can not be made
less restrictive with mprotect().
So when mapping a stack guard page, use the maximum protection
we ever want to use, then mprotect() it to the permission we
want it to have initially.
|
|
|
|
|
|
This is in the matter of RFC 1940 and tracking issue #43302.
|
|
This should allow us to tighten up the [codegen][example] a bit more, avoiding a
function call across object boundaries in the default optimized case.
[example]: https://play.rust-lang.org/?gist=c1179088b0f8a4dcd93a9906463f993d&version=stable&mode=release
|
