While a bare "NUL" *should* be redirected to the NUL device, especially in this simple case, let's be explicit that we aren't opening a file called "NUL" and instead open it directly.
This will also set a good example for people copying std code.
Lint pinned `#[must_use]` pointers (in particular, `Box<T>` where `T` is `#[must_use]`) in `unused_must_use`.
Fixes: #111458
This is motivated by a common async/await pattern:
```rs
fn foo() -> Pin<Box<dyn Future<Output = i32>>> {
Box::pin(async { 42 })
}
// call `foo`, but forget to await the result
foo();
```
Unlike with `async fn` or return position `impl Future`, this does not currently warn the user that the `Future` is unused.
To fix this, I've extended the `unused_must_use` lint to catch `Pin<P>`, where `P` must be used. In particular, this applies to `Pin<Box<T>>`, where `T` must be used. I'm not sure if there are other pointers where this applies, but I can't think of any situation the user wouldn't want to be warned.
Remove unneeded `unknown` variable and `Symbol` creation when iterating over items in rustdoc rendering
I realized that we were creating a `Symbol` but never actually used it since we check that `item.name` is always `Some()`.
r? `@notriddle`
Adjust frame IP in backtraces relative to image base for SGX target
This is followup to https://github.com/rust-lang/backtrace-rs/pull/566.
The backtraces printed by `panic!` or generated by `std::backtrace::Backtrace` in SGX target are not usable. The frame addresses need to be relative to image base address so they can be used for symbol resolution. Here's an example panic backtrace generated before this change:
```
$ cargo r --target x86_64-fortanix-unknown-sgx
...
stack backtrace:
0: 0x7f8fe401d3a5 - <unknown>
1: 0x7f8fe4034780 - <unknown>
2: 0x7f8fe401c5a3 - <unknown>
3: 0x7f8fe401d1f5 - <unknown>
4: 0x7f8fe401e6f6 - <unknown>
```
Here's the same panic after this change:
```
$ cargo +stage1 r --target x86_64-fortanix-unknown-sgx
stack backtrace:
0: 0x198bf - <unknown>
1: 0x3d181 - <unknown>
2: 0x26164 - <unknown>
3: 0x19705 - <unknown>
4: 0x1ef36 - <unknown>
```
cc `@jethrogb` and `@workingjubilee`
Set `CFG_OMIT_GIT_HASH=1` during builds when `omit-git-hash` is enabled
This environment variable will allow tools like Cargo to disable their own detection when `omit-git-hash` is set to `true`.
I created this PR because of https://github.com/rust-lang/cargo/pull/12968. There is not a dependency between the two PRs, they can land in any order. They just won't do anything until both of them are merged into the repo.
deprecate `if-available` value of `download-ci-llvm`
This PR deprecates the use of the `if-available` value for `download-ci-llvm` since `if-unchanged` serves the same purpose when no changes are detected. In cases where changes are present, it is assumed that compiling LLVM is acceptable (otherwise, why make changes there?).
This was probably missing in the #110087 issue before.
cc `@RalfJung`
Rollup of 5 pull requests
Successful merges:
- #116750 (Add Seek::seek_relative)
- #117110 (Suggest field typo through derefs)
- #117961 (Add `x suggest` entries for testing `mir-opt` and `coverage`)
- #118020 (Fix links to `From<{OwnedHandle, OwnedFd}> for std::process::Child{Stdin, Stdout, Stderr}` in 1.74 release notes)
- #118034 (bump few deps to fix unsoundness and drop few dup deps)
r? `@ghost`
`@rustbot` modify labels: rollup
Add `x suggest` entries for testing `mir-opt` and `coverage`
The `x suggest` subcommand uses git to find paths that have been modified, and uses those paths to suggest relevant test suites to run.
This PR adds suggestions for `x test mir-opt` and `x test coverage` .
Suggest field typo through derefs
Take into account implicit dereferences when suggesting fields.
```
error[E0609]: no field `longname` on type `Arc<S>`
--> $DIR/suggest-field-through-deref.rs:10:15
|
LL | let _ = x.longname;
| ^^^^^^^^ help: a field with a similar name exists: `long_name`
```
CC https://github.com/rust-lang/rust/issues/78374#issuecomment-719564114
Add Seek::seek_relative
The `BufReader` struct has a `seek_relative` method because its `Seek::seek` implementation involved dumping the internal buffer (https://github.com/rust-lang/rust/issues/31100).
Unfortunately, there isn't really a good way to take advantage of that method in generic code. This PR adds the same method to the main `Seek` trait with the straightforward default method, and an override for `BufReader` that calls its implementation.
_Also discussed in [this](https://internals.rust-lang.org/t/add-seek-seek-relative/19546) internals.rust-lang.org thread._
Update cargo
11 commits in 2c03e0e2dcd05dd064fcf10cc1050d342eaf67e3..9765a449d9b7341c2b49b88da41c2268ea599720
2023-11-16 04:21:44 +0000 to 2023-11-17 20:58:23 +0000
- refactor(toml): Clean up workspace inheritance (rust-lang/cargo#12971)
- docs: Recommend a wider selection of libsecret-compatible password managers (rust-lang/cargo#12993)
- feat(cli): add color output for `cargo --list` (rust-lang/cargo#12992)
- refactor: log when loading config from file (rust-lang/cargo#12991)
- Link to rustc lint levels (rust-lang/cargo#12990)
- chore(ci): Catch naive use of AtomicU64 early (rust-lang/cargo#12988)
- cargo-credential-1password: Add missing `--account` argument to `op signin` command (rust-lang/cargo#12985)
- chore: dogfood Cargo `-Zlints` table feature (rust-lang/cargo#12178)
- cargo-credential-1password: Fix README (rust-lang/cargo#12986)
- Fix a rustflags test using a wrong buildfile name (rust-lang/cargo#12987)
- Fix some test output validation. (rust-lang/cargo#12982)
r? ghost
Remove option_payload_ptr; redundant to offset_of
The `option_payload_ptr` intrinsic is no longer required as `offset_of` supports traversing enums (#114208). This PR removes it in order to dogfood offset_of (as suggested at https://github.com/rust-lang/rust/issues/106655#issuecomment-1790907626). However, it will not build until those changes reach beta (which I think is within the next 8 days?) so I've opened it as a draft.
When a local binding shadows a fn, point at fn def in call failure
When a local binding shadows a function that is then called, this local binding will cause an E0618 error. We now point not only at the binding definition, but also at the locally defined function of the same name.
```
error[E0618]: expected function, found `&str`
--> $DIR/issue-22468.rs:3:13
|
LL | let foo = "bar";
| --- `foo` has type `&str`
LL | let x = foo("baz");
| ^^^-------
| |
| call expression requires function
...
LL | fn foo(file: &str) -> bool {
| -------------------------- this function of the same name is available here, but it shadowed by the local binding of the same name
```
Fix#53841
Expose tests for {f32,f64}.total_cmp in docs
Expose tests for {f32,f64}.total_cmp in docs
Uncomment the helpful `assert_eq!` line, which is stripped out completely in docs, and leaves the reader to mentally play through the algorithm, or go to the playground and add a println!, to see what the result will be.
(If these tests are known to fail on some platforms, is there some mechanism to conditionalize this or escape the test so the `assert_eq!` source will be visible on the web? I am a newbie, which is why I was reading docs ;)
impl more traits for ptr::Alignment, add mask method
Changes:
* Adds `rustc_const_unstable` attributes where missing
* Makes `log2` method const
* Adds `mask` method
* Implements `Default`, which is equivalent to `Alignment::MIN`
No longer included in PR:
* Removes indirection of `AlignmentEnum` type alias (this was intentional)
* Implements `Display`, `Binary`, `Octal`, `LowerHex`, and `UpperHex` (should go through libs-api instead)
* Controversially implements `LowerExp` and `UpperExp` using `p` instead of `e` to indicate a power of 2 (also should go through libs-api)
Tracking issue for `ptr::Alignment`: #102070
Reenable effects in libcore
With #116670, #117531, and #117171, I think we would be comfortable with re-enabling the effects feature for more testing in libcore.
r? `@oli-obk`
cc `@fmease`
cc #110395
Add some additional warnings for duplicated diagnostic items
This commit adds warnings if a user supplies several diagnostic options where we can only apply one of them. We explicitly warn about ignored options here. In addition a small test for these warnings is added.
r? `@compiler-errors`
For now that's the last PR to improve the warnings generated by misused `#[diagnostic::on_unimplemented]` attributes. I'm not sure what needs to be done next to move this closer to stabilization.
Add T: ?Sized to `RwLockReadGuard` and `RwLockWriteGuard`'s Debug impls.
For context, `MutexGuard` has `+ ?Sized` on its `Debug` impl, and all three have `+ ?Sized` on their `Display` impls.
It looks like the `?Sized` was just missed when the impls were added (the impl for `MutexGuard` was added in the same PR (https://github.com/rust-lang/rust/pull/38006) with support for `T: Debug + ?Sized`, and `RwLock*Guard`s did allow `T: ?Sized` types already); the `Display` impls were added later (https://github.com/rust-lang/rust/pull/42822) with support for `T: Debug + ?Sized` types.
I think this needs a T-libs-api FCP? I'm not sure if this also needs an ACP. If so I can make one.
These are changes to (stable) trait impls on stable types so will be insta-stable.
`@rustbot` label +T-libs-api
When a local binding shadows a function that is then called, this local
binding will cause an E0618 error. We now point not only at the binding
definition, but also at the locally defined function of the same name.
```
error[E0618]: expected function, found `&str`
--> $DIR/issue-22468.rs:3:13
|
LL | let foo = "bar";
| --- `foo` has type `&str`
LL | let x = foo("baz");
| ^^^-------
| |
| call expression requires function
...
LL | fn foo(file: &str) -> bool {
| -------------------------- this function of the same name is avalable here, but it shadowed by the local binding of the same name
```
Fix#53841
Add stable mir members to triagebot config
I also added the two crates from the project to `[assign.owners]` so it automatically assign to a project member changes to those crates.
When using existing fn as module, don't claim it doesn't exist
Tweak wording of module not found in resolve, when the name exists but belongs to a non-`mod` item.
Fix#81232.
Emit smir
This adds ability to `-Zunpretty=smir` and get smir output of a Rust file, this is obliviously pretty basic compared to `mir` output but I think we could iteratively improve it, and even at this state this is useful for us.
r? ``@celinval``
Remove asmjs
Fulfills [MCP 668](https://github.com/rust-lang/compiler-team/issues/668).
`asmjs-unknown-emscripten` does not work as-specified, and lacks essential upstream support for generating asm.js, so it should not exist at all.
More detail when expecting expression but encountering bad macro argument
On nested macro invocations where the same macro fragment changes fragment type from one to the next, point at the chain of invocations and at the macro fragment definition place, explaining that the change has occurred.
Fix#71039.
```
error: expected expression, found pattern `1 + 1`
--> $DIR/trace_faulty_macros.rs:49:37
|
LL | (let $p:pat = $e:expr) => {test!(($p,$e))};
| ------- -- this is interpreted as expression, but it is expected to be pattern
| |
| this macro fragment matcher is expression
...
LL | (($p:pat, $e:pat)) => {let $p = $e;};
| ------ ^^ expected expression
| |
| this macro fragment matcher is pattern
...
LL | test!(let x = 1+1);
| ------------------
| | |
| | this is expected to be expression
| in this macro invocation
|
= note: when forwarding a matched fragment to another macro-by-example, matchers in the second macro will see an opaque AST of the fragment type, not the underlying tokens
= note: this error originates in the macro `test` (in Nightly builds, run with -Z macro-backtrace for more info)
```
I find `Compilation::and_then` hard to read. This commit removes it,
simplifying the control flow in `run_compiler`, and reducing the number
of lines of code.
In particular, `list_metadata` and `process_try_link` (renamed `rlink`)
are now only called if the relevant condition is true, rather than that
condition being checked within the function.
Currently we have an inconsistency between the "input" and "no input"
cases:
- no input: `rustc --print=sysroot -Whelp` prints the lint help.
- input: `rustc --print=sysroot -Whelp a.rs` prints the sysroot.
It makes sense to print the lint help in both cases, because that's what
happens with `--help`/`-Zhelp`/`-Chelp`.
In fact, the `describe_lints` in the "input" case happens amazingly
late, after *parsing*. This is because, with plugins, lints used to be
registered much later, when the global context was created. But #117649
moved lint registration much earlier, during session construction.
So this commit moves the `describe_lints` call to a single spot for both
for both the "input" and "no input" cases, as early as possible. This is
still not as early as `--help`/`-Zhelp`/`-Chelp`, because `-Whelp` must
wait until the session is constructed.
`rustc_driver_impl::run_compiler` currently has two
`interface::run_compiler` calls: one for the "no input" case, and one
for the normal case.
This commit merges the former into the latter, which makes the control
flow easier to read and avoids some duplication.
It also makes it clearer that the "no input" case will describe lints
before printing crate info, while the normal case does it in the reverse
order. Possibly a bug?
Yes, its type is `EarlyErrorHandler`, but there is another value of that
type later on in the function called `handler` that is initialized with
`sopts.error_format`. So `default_handler` is a better name because it
clarifies that it is initialized with `ErrorOutputType::default()`.
