| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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
|
|
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.
|
|
`#[allow]`/`#[warn]`/`#[deny]`/`#[forbid]` attributes
|
|
Currently, we allow the user to write things like
'// revisions: rpass1 rpass1', which will not test what they were
intending to test.
|
|
|
|
Remove #[main] attribute.
This removes the #[main] attribute support from the compiler according to the decisions within #29634. For existing use cases within test harness generation, replaced it with a newly-introduced internal attribute `#[rustc_main]`.
This is first part extracted from #84062 .
Closes #29634.
r? `@petrochenkov`
|
|
|
|
|
|
|
|
|
|
Check for asm support in UI tests that require it
Add `needs-asm-support` compiletest directive, and use it in asm tests
that require asm support without relying on any architecture specific
features.
Closes #84038.
|
|
Add `needs-asm-support` compiletest directive, and use it in asm tests
that require asm support without relying on any architecture specific
features.
|
|
update RLS and rustfmt
Fixes #83460 and fixes #83459
cc `@Xanewok`
|
|
|
|
Closes #77548.
|
|
|
|
reduce threads spawned by ui-tests
The test harness already spawns enough tests to keep all cores busy.
Individual tests should keep their own threading to a minimum to avoid context switch overhead.
When running ui tests with lld enabled this shaves about 10% off that testsuite on my machine.
Resolves #81946
|
|
the test harness already spawns enough tests for all cores, individual
tests should keep their own threading to a minimum to avoid context switch
overhead
some tests fail with 1 CGU, so explicit compile flags have been added
to keep their old behavior
|
|
|
|
Fix handling of `--output-format json` flag
- Don't treat it as deprecated on stable and beta channels. Before, it
would give confusing and incorrect output:
```
warning: the 'output-format' flag is considered deprecated
|
= warning: see issue #44136 <https://github.com/rust-lang/rust/issues/44136> for more information
error: json output format isn't supported for doc generation
```
Both of those are wrong: output-format isn't deprecated, and json
output is supported.
- Require -Z unstable-options for `--output-format json`
Previously, it was allowed by default on nightly, which made it hard
to realize the flag wouldn't be accepted on beta or stable.
To get the test working I had to remove `-Z unstable-options`, which x.py passed to compiletest unconditionally. It was first added in https://github.com/rust-lang/rust/commit/8c2ec689c159e7f021d5913efb991aff875be967 so `-Z miri` would be allowed. -Z miri is no longer passed unconditionally, so hopefully removing it won't break anything.
r? ```@aDotInTheVoid``` cc ```@HeroicKatora``` ```@CraftSpider```
Thanks to ```@memoryruins``` for pointing it out on Discord!
cc ```@Mark-Simulacrum``` for the change to compiletest.
|
|
Use AnonConst for asm! constants
This replaces the old system which used explicit promotion. See #83169 for more background.
The syntax for `const` operands is still the same as before: `const <expr>`.
Fixes #83169
Because the implementation is heavily based on inline consts, we suffer from the same issues:
- We lose the ability to use expressions derived from generics. See the deleted tests in `src/test/ui/asm/const.rs`.
- We are hitting the same ICEs as inline consts, for example #78174. It is unlikely that we will be able to stabilize this before inline consts are stabilized.
|
|
- Don't treat it as deprecated on stable and beta channels. Before, it
would give confusing and incorrect output:
```
warning: the 'output-format' flag is considered deprecated
|
= warning: see issue #44136 <https://github.com/rust-lang/rust/issues/44136> for more information
error: json output format isn't supported for doc generation
```
Both of those are wrong: output-format isn't deprecated, and json
output is supported.
- Require -Z unstable-options for `--output-format json`
Previously, it was allowed by default on nightly, which made it hard
to realize the flag wouldn't be accepted on beta or stable.
Note that this still allows `--output-format html`, which has been
stable since 1.0.
- Remove unnecessary double-checking of the feature gate when parsing
the output format
- Add custom run-make test since compiletest passes -Zunstable-options
by default
|
|
Update cargo
3 commits in 3c44c3c4b7900b8b13c85ead25ccaa8abb7d8989..65d57e6f384c2317f76626eac116f683e2b63665
2021-03-31 21:21:15 +0000 to 2021-04-04 15:07:52 +0000
- Fix typo in contrib docs. (rust-lang/cargo#9328)
- fix clippy warnings (rust-lang/cargo#9323)
- Add -Zallow-features to match rustc's -Z (rust-lang/cargo#9283)
|
|
|
|
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #83370 (Add `x.py setup tools` which enables `download-rustc` by default)
- #83489 (Properly suggest deref in else block)
- #83734 (Catch a bad placeholder type error for statics in `extern`s)
- #83814 (expand: Do not ICE when a legacy AST-based macro attribute produces and empty expression)
- #83835 (rustdoc: sort search index items for compression)
- #83849 (rustdoc: Cleanup handling of associated items for intra-doc links)
- #83881 (:arrow_up: rust-analyzer)
- #83885 (Document compiler/ with -Aprivate-intra-doc-links)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
:arrow_up: rust-analyzer
|
|
Use tikv-jemallocator in rustc/rustdoc in addition to jemalloc-sys when enabled.
In https://github.com/rust-lang/rust/pull/81782 it was mentioned that one reason rustc may benefit from minimalloc is it doesn't use the `sdallocx` api from jemalloc.
Currently, on unix, rust uses jemalloc by importing its symbols to use them with the default, System (libc) global allocator.
This PR switches its global alloc to `tikv-jemallocator`, which correctly uses sized deallocation (https://docs.rs/tikv-jemallocator/0.4.1/src/tikv_jemallocator/lib.rs.html#121-126). `tikv-jemallocator`, as far as I can tell, is a more up-to-date set of bindings to jemalloc than `jemallocator`
The perf results of this pr are in large part due to the version upgrade of jemalloc, but sized deallocation has a non-trivial improvement, particularly to rustdoc.
This pr also includes changes to bootstrap to correctly pass the jemalloc feature through to the rustdoc build
|
|
Fix racing file access in tidy
That should fix the failure in https://github.com/rust-lang/rust/pull/83776#issuecomment-813311289
The file is only created for a brief moment during the bins checks in the source directories while other checks may also be visiting the same directory. By skipping it we avoid file not found errors.
|
|
Remove unnecessary exceptions to the platform-specific code check
Some of these were just wrong, like src/librustc. Some looked outdated,
like std::f64. Not sure what was going on with the others - maybe this
check isn't as smart as it needs to be? But in the meantime it seems
silly to ignore the check if it will pass anyway.
|
|
Give a better error when --theme is not a CSS file
Before:
```
error: invalid argument: "bacon.toml"
```
After:
```
error: invalid argument: "bacon.toml"
|
= help: arguments to --theme must be CSS files
```
cc https://github.com/rust-lang/rust/pull/83478
|
|
|
|
this file is only created for a brief moment during the bins checks
in the source directories while other checks may also be visiting
that directory. skip processing it to avoid missing file errors
|
|
Some of these were just wrong, like src/librustc. Some looked outdated,
like std::f64. Not sure what was going on with the others - maybe this
check isn't as smart as it needs to be? But it the meantime it seems
silly to ignore the check if it will pass anyway.
|
|
Rollup of 7 pull requests
Successful merges:
- #80525 (wasm64 support)
- #83019 (core: disable `ptr::swap_nonoverlapping_one`'s block optimization on SPIR-V.)
- #83717 (rustdoc: Separate filter-empty-string out into its own function)
- #83807 (Tests: Remove redundant `ignore-tidy-linelength` annotations)
- #83815 (ptr::addr_of documentation improvements)
- #83820 (Remove attribute `#[link_args]`)
- #83841 (Allow clobbering unsupported registers in asm!)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Bump bootstrap to 1.52 beta
This includes the standard bump, but also a workaround for new cargo behavior around clearing out the doc directory when the rustdoc version changes.
|
|
Remove attribute `#[link_args]`
Closes https://github.com/rust-lang/rust/issues/29596
The attribute could always be replaced with `-C link-arg`, but cargo didn't provide a reasonable way to pass such flags to rustc.
Now cargo supports `cargo:rustc-link-arg*` directives in build scripts (https://doc.rust-lang.org/cargo/reference/unstable.html#extra-link-arg), so this attribute can be removed.
|
|
rustdoc: Separate filter-empty-string out into its own function
|
|
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #73945 (Add an unstable --json=unused-externs flag to print unused externs)
- #81619 (Implement `SourceIterator` and `InPlaceIterable` for `ResultShunt`)
- #82726 (BTree: move blocks around in node.rs)
- #83521 (2229: Fix diagnostic issue when using FakeReads in closures)
- #83532 (Fix compiletest on FreeBSD)
- #83793 (rustdoc: highlight macros more efficiently)
- #83809 (Remove unneeded INITIAL_IDS const)
- #83827 (cleanup leak after test to make miri happy)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Fix compiletest on FreeBSD
Recent FreeBSD gdb packages have a different format for the version string.
|
|
2229: Fix diagnostic issue when using FakeReads in closures
This PR fixes a diagnostic issue caused by https://github.com/rust-lang/rust/pull/82536. A temporary work around was used in this merged PR which involved feature gating the addition of FakeReads introduced as a result of pattern matching in closures.
The fix involves adding an optional closure DefId to ForLet and ForMatchedPlace FakeReadCauses. This DefId will only be added if a closure pattern matches a Place starting with an Upvar.
r? ```@nikomatsakis```
|
