| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Cross reference io::copy and fs::copy in docs.
Fixes https://github.com/rust-lang/rust/issues/52524.
|
|
|
|
|
|
|
|
in order to avoid constantly zeroing memory when it's not needed.
|
|
|
|
I think it might be used in some other things, but I'm not fluent enough
at sifting through the rust compiler's source code to find every use of
a specific keyword.
This leaves the question of how to document the `extern` keyword, what
with how much overlap it has with `crate`, but that's used with ABI
stuff so that should be fine.
|
|
|
|
|
|
|
|
|
|
|
|
Update Cargo.lock
This also includes major version bumps for the rand crate used by core, std, and alloc tests, among other crates (regex, etc.) used elsewhere. Since these are all internal there should be no user-visible changes.
r? @alexcrichton
|
|
Allow to check if sync::Once is already initialized
Hi!
I propose to expose a way to check if a `Once` instance is initialized.
I need it in `once_cell`. `OnceCell` is effetively a pair of `(Once, UnsafeCell<Option<T>>)`, which can set the `T` only once. Because I can't check if `Once` is initialized, I am forced to add an indirection and check the value of ptr instead:
https://github.com/matklad/once_cell/blob/8127a81976c3f2f4c0860562c3f14647ebc025c0/src/lib.rs#L423-L429
https://github.com/matklad/once_cell/blob/8127a81976c3f2f4c0860562c3f14647ebc025c0/src/lib.rs#L457-L461
The `parking_lot`'s version of `Once` exposes the state as an enum: https://docs.rs/parking_lot/0.6.3/parking_lot/struct.Once.html#method.state.
I suggest, for now, just to add a simple `bool` function: this fits my use-case perfectly, exposes less implementation details, and is forward-compatible with more fine-grained state checking.
|
|
|
|
|
|
Mostly addressing notes on ambiguous syntax and spurious newlines.
|
|
Turns out writing docs on keywords that are used in multiple different
places in entirely different contexts gets a little harder. I put a
footnote on `*const` syntax just to make sure you can find it if need
be, but it might need more detail.
|
|
It's pretty basic and could do with more details, but it's a good
starter until someone else improves it.
|
|
The whole keyword docs thing is pretty new in Rust's history and needs
some work before it's a shining gem. Here's hoping I can provide that.
I basically shoved in a bunch of the most important information from the
reference and the book, along with leaving links to both at the end. I
don't think keyword docs need to have complete detail, just all the
broad strokes, so if someone's confused about a usage of a keyword they
can look at the std documentation for that keyword.
|
|
Reduce number of syscalls in `rand`
This skips the initial zero-length `getrandom` call and
directly hands the user buffer to the operating system, saving one
`getrandom` syscall.
|
|
|
|
Add Error::source method per RFC 2504.
This implements part of RFC 2504.
* Adds `Error::source`, a replacement for `Error::cause` with the "right" signature, which will be instantly stable.
* Deprecates `Error::cause` in 1.33 (this choice was based on the precedent in #52994, which we haven't finalized).
* Redefines `Error::cause` to delegate to `Error::source` (the delegation can only go in this direction, not the other).
@rfcbot fcp merge
|
|
Rollup of 9 pull requests
Successful merges:
- #53076 (set cfg(rustdoc) when rustdoc is running on a crate)
- #53622 (cleanup: Add main functions to some UI tests)
- #53769 (Also link Clippy repo in the CONTRIBUTING.md file)
- #53774 (Add rust-gdbgui script.)
- #53781 (bench: libcore: fix build failure of any.rs benchmark (use "dyn Any"))
- #53782 (Make Arc cloning mechanics clearer in module docs)
- #53790 (Add regression test for issue #52060)
- #53801 (Prevent duplicated impl on foreign types)
- #53850 (Nuke the `const_to_allocation` query)
|
|
set cfg(rustdoc) when rustdoc is running on a crate
When using `#[doc(cfg)]` to document platform-specific items, it's a little cumbersome to get all the platforms' items to appear all at once. For example, the standard library adds `--cfg dox` to rustdoc's command line whenever it builds docs, and the documentation for `#![feature(doc_cfg)]` suggests using a Cargo feature to approximate the same thing. This is a little awkward, because you always need to remember to set `--features dox` whenever you build documentation.
This PR proposes making rustdoc set `#[cfg(rustdoc)]` whenever it runs on a crate, to provide an officially-sanctioned version of this that is set automatically. This way, there's a standardized way to declare that a certain version of an item is specifically when building docs.
To try to prevent the spread of this feature from happening too quickly, this PR also restricts the use of this flag to whenever `#![feature(doc_cfg)]` is active. I'm sure there are other uses for this, but right now i'm tying it to this feature. (If it makes more sense to give this its own feature, i can easily do that.)
|
|
|
|
|
|
|
|
|
|
|
|
Replace usages of 'bad_style' with 'nonstandard_style'.
`bad_style` is being deprecated in favor of `nonstandard_style`:
- https://github.com/rust-lang/rust/issues/41646
|
|
Fix typo in comment
|
|
fix a typo: taget_env -> target_env
This typo was introduced in https://github.com/rust-lang/rust/pull/47334. A couple tests bitrotted as a result, so we fix those too, and move them to a more sensible place.
Is there some lint we could turn on that would've caught this? It's a drag that cfg typos can silently pass through the compiler.
|
|
document effect of join on memory ordering
Fixes https://github.com/rust-lang/rust/issues/45467
|
|
|
|
|
|
`bad_style` is being deprecated in favor of `nonstandard_style`:
- https://github.com/rust-lang/rust/issues/41646
|
|
|
|
|
|
document the platform-specific behavior of Command::current_dir
See also https://github.com/rust-lang/rust/issues/37868.
Here's my initial wording:
> Note that if the program path is relative (e.g. `"./script.sh"`), the interaction between that path and `current_dir` varies across platforms. Windows currently ignores `current_dir` when locating the program, but Unix-like systems interpret the program path relative to `current_dir`. These implementation details aren't considered stable, and it's recommended to call `canonicalize` to get an absolute program path instead of using relative paths and `current_dir` together.
I'd like to get feedback on:
- _Should_ we consider those details stable? It might be disruptive to change them, regardless of what I can get away with claiming in docs :)
- Is `canonicalize` an appropriate recommendation? As discussed in #37868 above, there are reasons it's not called automatically in the `Command` implementation.
|
|
Warn on anon params in 2015 edition
cc #41686 https://github.com/rust-lang/rfcs/pull/2522
cc @Centril @nikomatsakis
TODO:
- [x] Make sure the tests pass.
- [x] Make sure there is rustfix-able suggestion. Current plan is to just suggest `_ : Foo`
- [x] Add a rustfix ui test.
EDIT: It seems I already did the last two in #48309
|
|
move the Pin API into its own module for centralized documentation
This implements the change proposed by @withoutboats in #49150, as suggested by @RalfJung in the review of #53104,
along with the documentation that was originally in it, that was deemed more appropriate in module-level documentation.
r? @RalfJung
|
|
This typo was introduced in https://github.com/rust-lang/rust/pull/47334.
A couple tests bitrotted as a result, so we fix those too, and move them
to a more sensible place.
|
|
fix for late-bound regions
Fix for https://github.com/rust-lang/rust/issues/53419
r? @nikomatsakis
|
|
|
|
rustc: Continue to tweak "std internal symbols"
In investigating [an issue][1] with `panic_implementation` defined in an
executable that's optimized I once again got to rethinking a bit about the
`rustc_std_internal_symbol` attribute as well as weak lang items. We've sort of
been non-stop tweaking these items ever since their inception, and this
continues to the trend.
The crux of the bug was that in the reachability we have a [different branch][2]
for non-library builds which meant that weak lang items (and std internal
symbols) weren't considered reachable, causing them to get eliminiated by
ThinLTO passes. The fix was to basically tweak that branch to consider these
symbols to ensure that they're propagated all the way to the linker.
Along the way I've attempted to erode the distinction between std internal
symbols and weak lang items by having weak lang items automatically configure
fields of `CodegenFnAttrs`. That way most code no longer even considers weak
lang items and they're simply considered normal functions with attributes about
the ABI.
In the end this fixes the final comment of #51342
[1]: https://github.com/rust-lang/rust/issues/51342#issuecomment-414368019
[2]: https://github.com/rust-lang/rust/blob/35bf1ae25799a4e62131159f052e0a3cbd27c960/src/librustc/middle/reachable.rs#L225-L238
|
|
In investigating [an issue][1] with `panic_implementation` defined in an
executable that's optimized I once again got to rethinking a bit about the
`rustc_std_internal_symbol` attribute as well as weak lang items. We've sort of
been non-stop tweaking these items ever since their inception, and this
continues to the trend.
The crux of the bug was that in the reachability we have a [different branch][2]
for non-library builds which meant that weak lang items (and std internal
symbols) weren't considered reachable, causing them to get eliminiated by
ThinLTO passes. The fix was to basically tweak that branch to consider these
symbols to ensure that they're propagated all the way to the linker.
Along the way I've attempted to erode the distinction between std internal
symbols and weak lang items by having weak lang items automatically configure
fields of `CodegenFnAttrs`. That way most code no longer even considers weak
lang items and they're simply considered normal functions with attributes about
the ABI.
In the end this fixes the final comment of #51342
[1]: https://github.com/rust-lang/rust/issues/51342#issuecomment-414368019
[2]: https://github.com/rust-lang/rust/blob/35bf1ae25799a4e62131159f052e0a3cbd27c960/src/librustc/middle/reachable.rs#L225-L238
|
|
In case that it is statically known that the OS doesn't support
`getrandom` (non-Linux) or becomes clear at runtime that `getrandom`
isn't available (`ENOSYS`), the opened fd ("/dev/urandom") isn't closed
after the function, so that future calls can reuse it. This saves
repeated `open`/`close` system calls at the cost of one permanently open
fd.
Additionally, this skips the initial zero-length `getrandom` call and
directly hands the user buffer to the operating system, saving one
`getrandom` syscall.
|
|
Add struct keyword doc
Slowly, one keyword at a time.
r? @QuietMisdreavus
|
