Support configurable deny-warnings for all in-tree crates.
This removes the hard-coded `deny(warnings)` on all in-tree tools, and allows it to be configured from the config. This is just a personal preference, as I find `deny(warnings)` frustrating during development or doing small tests.
This also fixes some regressions in terms of warning handling. Warnings used to be dependent on `SourceType`, but in #64316 it was changed to be based on `Mode`. This means tools like rustdoc no longer used the same settings as the rest of the tree. It also made `SourceType` useless since the only thing it was used for was warnings. I think it would be better for everything in the tree to use the same settings.
Fixes#64523
proc_macro: Stop flattening groups with dummy spans
Reduce the scope of the hack described in https://github.com/rust-lang/rust/issues/72545#issuecomment-640276791.
We still pass AST fragments to attribute and derive macros as single nonterminal tokens rather than as tokens streams, but now use a precise flag instead of the span-based heuristic that could do lead to incorrect behavior in unrelated cases.
https://github.com/rust-lang/rust/pull/73345 attempts to fully resolve this issue, but there are some compatibility issues to be addressed.
Don't move cursor in search box when using arrows to navigate results
## What happens
- Go to https://doc.rust-lang.org/stable/std/index.html
- Press 's' to focus the search box
- Type a query like 'test'
- Press the down arrow one or more times to change which search result is highlighted
- Press the up arrow once to go up one search result
- Notice the cursor in the search box is now at the beginning of your query, such that if you now typed 'a' the search box would contain 'atest', when it would be expected that the cursor would have remained where it was and if you typed 'a' at this point it would result in 'testa'
- Press the down arrow once to go down one search result
- Now notice the cursor is at the end of your query again
## What I expected
I expected that changing which search result was highlighted using the up and down arrows would have no effect on where the cursor was in the search box.
## The fix
This PR prevents the default action of the up and down arrows when the custom keydown events are happening during a search.
Omit DW_AT_linkage_name when it is the same as DW_AT_name
The DWARF standard suggests that it might be useful to include
`DW_AT_linkage_name` when it is *distinct* from the identifier name.
Fixes#46487.
Fixes#59422.
rustc_lint: only query `typeck_tables_of` when a lint needs it.
This was prompted by @jyn514 running into a situation where `rustdoc` wants to run the `unused_doc` lint without triggering type-checking (as an alternative to the "everybody loops" approach - type-checking may error/ICE because of the `rustdoc` feature of allowing multi-platform docs where the actual bodies of functions may refer to APIs for different platforms).
There was also this comment in the source:
```rust
// FIXME: Make this lazy to avoid running the TypeckTables query?
```
The main effect of this is for lint authors, who now need to use `cx.tables()` to get `&TypeckTables`, as opposed to having them always available in `cx.tables`.
r? @oli-obk or @Manishearth
Document the return keyword
Partial fix of #34601.
This documents the `return` keyword with two short example to explain it is not needed for the last expression in a function and a long example to show its use when interrupting a function execution early.
I did not put a link to the reference since the only link I found was https://doc.rust-lang.org/stable/reference/expressions/return-expr.html#return-expressions.
@rustbot modify labels: T-doc,C-enhancement
Document the mut keyword
Partial fix for #34601.
Documentation for the `mut` keyword. I think it's okay for it to be quite short, this is not the book not the reference, but if you find something is missing, do not hesitate to tell me.
Provide suggestions for some moved value errors
When encountering an used moved value where the previous move happened
in a `match` or `if let` pattern, suggest using `ref`. Fix#63988.
When encountering a `&mut` value that is used in multiple iterations of
a loop, suggest reborrowing it with `&mut *`. Fix#62112.
Emit line info for generator variants
Debuggers should be able to read a generator / async fn state machine and show the line it's suspended at. Eventually, this could grow into an "async stack trace" feature of sorts. While no debugger support this for Rust today, this PR adds the debuginfo necessary for that support to exist.
[This gist](https://gist.github.com/tmandry/6d7004fa008684f76809208847459f9b) shows the resulting debuginfo for a simple example. Here's a snippet:
```
0x00000986: DW_TAG_variant
DW_AT_discr_value (0x03)
0x00000988: DW_TAG_member
DW_AT_name ("3")
DW_AT_type (0x000009bc "Suspend0")
DW_AT_decl_file ("/home/tmandry/code/playground/generator-simple.rs")
DW_AT_decl_line (6)
DW_AT_alignment (8)
DW_AT_data_member_location (0x00)
```
The file and line have been added here. The line currently points to the beginning of the statement containing the yield (or await), because that's what the MIR source info points to for the yield terminator. (We may want to point to the yield or await line specifically, but that can be done independently of this change.)
Debuggers don't know how to use this kind of info yet. However, we're hoping to experiment with adding such support to Fuchsia's debugger. It would be exciting if someone were interested in adding similar to support to gdb/lldb.
r? @oli-obk
cc @eddyb @jonas-schievink
Part of #73524.
Add unstable `core::mem::variant_count` intrinsic
Adds a new `const fn` intrinsic which can be used to determine the number of variants in an `enum`.
I've shown this to a couple of people and they invariably ask 'why on earth?', but there's actually a very neat use case:
At the moment, if you want to create an opaque array type that's indexed by an `enum` with one element for each variant, you either have to hard-code the number of variants, add a `LENGTH` variant or use a `Vec`, none of which are suitable in general (number of variants could change; pattern matching `LENGTH` becomes frustrating; might not have `alloc`). By including this intrinsic, it becomes possible to write the following:
```rust
#[derive(Copy, Clone)]
enum OpaqueIndex {
A = 0,
B,
C,
}
struct OpaqueVec<T>(Box<[T; std::mem::num_variants::<OpaqueIndex>()]>);
impl<T> std::ops::Index<OpaqueIndex> for OpaqueVec<T> {
type Output = T;
fn index(&self, idx: OpaqueIndex) -> &Self::Output {
&self.0[idx as usize]
}
}
```
(We even have a use cases for this in `rustc` and I plan to use it to re-implement the lang-items table.)
Implement mixed script confusable lint.
This implements the mixed script confusable lint defined in RFC 2457.
This is blocked on #72069 and https://github.com/unicode-rs/unicode-security/pull/13, and will need a Cargo.toml version bump after those are resolved.
The lint message warning is sub-optimal for now. We'll need a mechanism to properly output `AugmentScriptSet` to screen, this is to be added in `unicode-security` crate.
r? @Manishearth
Self contained linking option
With objects moved to self-contained directory by https://github.com/rust-lang/rust/pull/72999 we can now add option to control whether to use self-contained on native linkage mode.
Add a fast path for `std:🧵:panicking`.
This is done by adding a global atomic variable (non-TLS) that counts how many threads are panicking. In order to check if the current thread is panicking, this variable is read and, if it is zero, no thread (including the one where `panicking` is being called) is panicking and `panicking` can return `false` immediately without needing to access TLS. If the global counter is not zero, the local counter is accessed from TLS to check if the current thread is panicking.
Print environment variables accessed by rustc as special comments into depinfo files
So cargo (and perhaps others tools) can use them for linting (at least) or for actually rebuilding crates on env var changes.
---
I've recently observed one more forgotten environment variable in a build script 8a77d1ca3f and thought it would be nice to provide the list of accessed variables to cargo automatically as a part of depinfo.
Unsurprisingly, I wasn't the first who had this idea - cc https://github.com/rust-lang/rust/issues/70517https://github.com/rust-lang/rust/issues/40364https://github.com/rust-lang/rust/issues/44074.
Also, there are dozens of uses of `(option_)env!` in rustc repo and, like, half of them are not registered in build scripts.
---
Description:
- depinfo files are extended with special comments containing info about environment variables accessed during compilation.
- Comment format for environment variables with successfully retrieved value: `# env-dep:KEY=VALUE`.
- Comment format for environment variables without successfully retrieved value: `# env-dep:KEY` (can happen with `option_env!`).
- `KEY` and `VALUE` are minimally escaped (`\n`, `\r`, `\\`) so they don't break makefile comments and can be unescaped by anything that can unescape standard `escape_default` and friends.
FCP report: https://github.com/rust-lang/rust/pull/71858#issuecomment-633071488
Closes https://github.com/rust-lang/rust/issues/70517
Closes https://github.com/rust-lang/rust/issues/40364
Closes https://github.com/rust-lang/rust/issues/44074
A new issue in the cargo repo will be needed to track the cargo side of this feature.
r? @ehuss
Add TryFrom<{int}> for NonZero{int}
Adds `TryFrom<{int}> for NonZero{int}`.
It uses the existing `NonZero{int}::new()` and `Option::ok_or()` functions, meaning the checks are not repeated.
I also added tests, I tried to follow the convention I saw in the test file.
I also used `#[stable(feature = "nzint_try_from_int_conv", since = "1.46.0")]`, but I have no idea if the feature/version are correctly named or even correct.
This commit modifies the column width computation in the emitter when
`termize::dimensions` returns `None` so that it uses the default value
of 140 (which is used in UI testing currently) instead of `usize::MAX`
which just ends up causing overflows in later computations. This is hard
to test but appears to produce the same output as using saturating
functions instead.
Signed-off-by: David Wood <david@davidtw.co>
