| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Remove unused footer section
I realized yesterday while working on docs.rs that rustdoc was generating a "footer"section that it doesn't use. No need to keep it then.
r? `@jyn514`
|
|
fix suggestion for unsized function parameters
taken from `@fasterthanlime's` article https://fasterthanli.me/articles/whats-in-the-box
|
|
Lower async fn in traits.
An error is already created by AST validation.
Fixes #84149
|
|
Enable sanitizers for x86_64-unknown-linux-musl
Those 4 sanitizers get musl target support in LLVM 12 release.
|
|
|
|
|
|
rustdoc: Reduce visual weight of attributes.
Followup from #83337. As part of that PR, we stopped hiding attributes behind a toggle, because most things have just zero or one attributes. However, this made clear that the current rendering of attributes emphasizes them a lot, which distracts from function signatures. This PR changes their color of attributes to be the same as the toggles, and reduces their font weight.
This also removes `#[lang]` from the list of ALLOWED_ATTRIBUTES. This attribute is an implementation detail rather than part of the public-facing documentation.
Demo at https://hoffman-andrews.com/rust/de-emph-attr/std/string/struct.String.html#method.trim
|
|
r=petrochenkov
Improve an error message.
|
|
rustdoc: get rid of CURRENT_DEPTH
Fixes #82742
|
|
Stablize `non-ascii-idents`
This is the stablization PR for RFC 2457. Currently this is waiting on fcp in [tracking issue](https://github.com/rust-lang/rust/issues/55467).
r? `@Manishearth`
|
|
Add `Unsupported` to `std::io::ErrorKind`
I noticed a significant portion of the uses of `ErrorKind::Other` in std is for unsupported operations.
The notion that a specific operation is not available on a target (and will thus never succeed) seems semantically distinct enough from just "an unspecified error occurred", which is why I am proposing to add the variant `Unsupported` to `std::io::ErrorKind`.
**Implementation**:
The following variant will be added to `std::io::ErrorKind`:
```rust
/// This operation is unsupported on this platform.
Unsupported
```
`std::io::ErrorKind::Unsupported` is an error returned when a given operation is not supported on a platform, and will thus never succeed; there is no way for the software to recover. It will be used instead of `Other` where appropriate, e.g. on wasm for file and network operations.
`decode_error_kind` will be updated to decode operating system errors to `Unsupported`:
- Unix and VxWorks: `libc::ENOSYS`
- Windows: `c::ERROR_CALL_NOT_IMPLEMENTED`
- WASI: `wasi::ERRNO_NOSYS`
**Stability**:
This changes the kind of error returned by some functions on some platforms, which I think is not covered by the stability guarantees of the std? User code could depend on this behavior, expecting `ErrorKind::Other`, however the docs already mention:
> Errors that are `Other` now may move to a different or a new `ErrorKind` variant in the future. It is not recommended to match an error against `Other` and to expect any additional characteristics, e.g., a specific `Error::raw_os_error` return value.
The most recent variant added to `ErrorKind` was `UnexpectedEof` in `1.6.0` (almost 5 years ago), but `ErrorKind` is marked as `#[non_exhaustive]` and the docs warn about exhaustively matching on it, so adding a new variant per se should not be a breaking change.
The variant `Unsupported` itself could be marked as `#[unstable]`, however, because this PR also immediately uses this new variant and changes the errors returned by functions I'm inclined to agree with the others in this thread that the variant should be insta-stabilized.
|
|
|
|
Don't set fast-math for the SIMD operations we set it for previously
Instead of `fast-math`. `fast-math` implies things like functions not
being able to accept as an argument or return as a result, say, `inf`
which made these functions confusingly named or behaving incorrectly,
depending on how you interpret it. It seems that the intended behaviour
was to set a `afn` flag instead. In doing so we also renamed the
intrinsics to say `_approx` so that it is clear these are not precision
oriented and the users can act accordingly.
Fixes #84268
|
|
Fix the wrong return value type description of validateResult
It's should be boolean not [boolean].
|
|
|
|
Deprecate the core::raw / std::raw module
It only contains the `TraitObject` struct which exposes components of wide pointer. Pointer metadata APIs are designed to replace this: https://github.com/rust-lang/rust/issues/81513
|
|
|
|
Move some tests to more reasonable directories - 6
cc #73494
r? `@petrochenkov`
git mv bad/bad-const-type.* static/
git mv bad/bad-crate-name.* extern
git mv bad/bad-env-capture* fn/
git mv bad/bad-expr-lhs.* expr/
git mv bad/bad-expr-path* expr/
git mv bad/bad-extern-link-attrs.* extern/
git mv bad/bad-intrinsic-monomorphization.* intrinsics/
git mv bad/bad-lint-cap* lint/
git mv bad/bad-main.* fn
git mv bad/bad-method-typaram-kind.* type/
git mv bad/bad-mid-path-type-params.* fn
git mv bad/bad-module.* modules/
git mv bad/bad-sized.* type/
git mv bad/bad-type-env-capture.* fn
|
|
|
|
Do not ignore path segments in the middle in `#[allow]`/`#[warn]`/`#[deny]`/`#[forbid]` attributes
Fixes #83477.
|
|
|
|
|
|
Rollup of 4 pull requests
Successful merges:
- #83237 (rustdoc: use more precise relative URLs)
- #84150 (rustdoc: move some search code into search.js)
- #84203 (rustdoc: Give a more accurate span for anchor failures)
- #84257 (Add documentation to help people find `Ipv4Addr::UNSPECIFIED`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
`fast-math` implies things like functions not being able to accept as an
argument or return as a result, say, `inf` which made these functions
confusingly named or behaving incorrectly, depending on how you
interpret it. Since the time when these intrinsics have been implemented
the intrinsics user's (stdsimd) approach has changed significantly and
so now it is required that these intrinsics operate normally rather than
in "whatever" way.
Fixes #84268
|
|
rustdoc: Give a more accurate span for anchor failures
r? `@euclio`
|
|
rustdoc: move some search code into search.js
This reduces main.s from 3094 lines to 1587. Also it saves some bytes
of download in the case where search isn't used.
There were a fair number of variables that needed to be accessible in
both main.js and search.js, but I didn't want to put too many symbols in
the global namespace, so I consolidated much of the search-related
state and functions into a new object `window.searchState`.
Demo at https://hoffman-andrews.com/rust/move-search/std/?search=foo
|
|
rustdoc: use more precise relative URLs
This is a fairly large diff, and will probably conflict with https://github.com/rust-lang/rust/pull/82815 since it reduces (but does not eliminate) the use of the old depth variable.
Instead of using a depth counter and adding "../" to get to the top, this commit makes rustdoc actually compare the path of what it's linking from to the path that it's linking to. This makes the resulting HTML shorter.
Here's a comparison of one of the largest (non-source) files in the Rust standard library docs (about 4% improvement before gzipping).
$ wc -c struct.Wrapping.old.html struct.Wrapping.new.html
2387389 struct.Wrapping.old.html
2298538 struct.Wrapping.new.html
Most if it can be efficiently gzipped away.
$ wc -c struct.Wrapping.old.html.gz struct.Wrapping.new.html.gz
70679 struct.Wrapping.old.html.gz
70050 struct.Wrapping.new.html.gz
But it also makes a difference in the final DOM size, reducing it from 91MiB to 82MiB.
|
|
|
|
Include a backport for wrong DWARF information
A partial fix for #83139
r? `@cuviper` or `@nikic`
|
|
This should help make things consistent.
|
|
|
|
The function `to_src_with_space` doesn't even accept the cache as a parameter,
so it doesn't matter any more what's in it.
|
|
Instead of using a depth counter and adding "../" to get to the top,
this commit makes rustdoc actually compare the path of what it's
linking from to the path that it's linking to. This makes the resulting
HTML shorter.
Here's a comparison of one of the largest (non-source) files in the
Rust standard library docs (about 4% improvement before gzipping).
$ wc -c struct.Wrapping.old.html struct.Wrapping.new.html
2387389 struct.Wrapping.old.html
2298538 struct.Wrapping.new.html
Most if it can be efficiently gzipped away.
$ wc -c struct.Wrapping.old.html.gz struct.Wrapping.new.html.gz
70679 struct.Wrapping.old.html.gz
70050 struct.Wrapping.new.html.gz
But it also makes a difference in the final DOM size, reducing it from 91MiB to 82MiB.
|
|
Error when compiletest is passed duplicate revisions
Currently, we allow the user to write things like
'// revisions: rpass1 rpass1', which will not test what they were
intending to test.
|
|
Mark `has_global_allocator` query as `eval_always`
Fixes #84252
This query reads from untracked global state in `CStore`.
|
|
A partial fix for #83139
|
|
`#[allow]`/`#[warn]`/`#[deny]`/`#[forbid]` attributes
|
|
rustdoc: get rid of unused path printing code
The code for printing a raw path is only used in utils.rs, which only prints the alternative (non-HTML) format. Path has
a function that does the same thing without HTML support, so use that instead.
|
|
fix incomplete diagnostic notes when closure returns conflicting for genric type
fixes #84128
Correctly report the span on for conflicting return type in closures
|
|
Builtin derive macros: fix error with const generics default
This fixes a bug where builtin derive macros (like Clone, Debug) would basically copy-paste the default from a const generic, causing a compile error with very confusing message - it would say defaults are not allowed in impl blocks, while pointing at struct/enum/union definition.
|
|
Detect when suggested paths enter extern crates more rigorously
When reporting resolution errors, the compiler tries to avoid suggesting importing inaccessible paths from other crates. However, the search for suggestions only recognized when it was entering a crate root directly, and so failed to recognize a path like `crate::module::private_item`, where `module` was imported from another crate with `use other_crate::module`, as entering another crate.
Fixes #80079
Fixes #84081
|
|
rustdoc: clean up and test macro visibility print
This fixes the overly-complex invariant mentioned in <https://github.com/rust-lang/rust/pull/83237#issuecomment-815346570>, where the macro source can't have any links in it only because the cache hasn't been populated yet.
|
|
Currently, we allow the user to write things like
'// revisions: rpass1 rpass1', which will not test what they were
intending to test.
|
|
Fixes #84252
This query reads from untracked global state in `CStore`.
|
|
Update miri.
Fixes #84240.
r? `@RalfJung`
|
|
|
|
std: Add a variant of thread locals with const init
This commit adds a variant of the `thread_local!` macro as a new
`thread_local_const_init!` macro which requires that the initialization
expression is constant (e.g. could be stuck into a `const` if so
desired). This form of thread local allows for a more efficient
implementation of `LocalKey::with` both if the value has a destructor
and if it doesn't. If the value doesn't have a destructor then `with`
should desugar to exactly as-if you use `#[thread_local]` given
sufficient inlining.
The purpose of this new form of thread locals is to precisely be
equivalent to `#[thread_local]` on platforms where possible for values
which fit the bill (those without destructors). This should help close
the gap in performance between `thread_local!`, which is safe, relative
to `#[thread_local]`, which is not easy to use in a portable fashion.
|
|
This commit adds a variant of the `thread_local!` macro as a new
`thread_local_const_init!` macro which requires that the initialization
expression is constant (e.g. could be stuck into a `const` if so
desired). This form of thread local allows for a more efficient
implementation of `LocalKey::with` both if the value has a destructor
and if it doesn't. If the value doesn't have a destructor then `with`
should desugar to exactly as-if you use `#[thread_local]` given
sufficient inlining.
The purpose of this new form of thread locals is to precisely be
equivalent to `#[thread_local]` on platforms where possible for values
which fit the bill (those without destructors). This should help close
the gap in performance between `thread_local!`, which is safe, relative
to `#[thread_local]`, which is not easy to use in a portable fashion.
|
|
The code for printing a raw path is only used in utils.rs,
which only prints the alternative (non-HTML) format. Path has
a function that does the same thing without HTML support,
so use that instead.
|
|
|
