dead-code lint: say "constructed" for structs
Respectively.
This is a sequel to November 2017's #46103 / 1a9dc2e9. It had been
reported (more than once—at least #19140, #44083, and #44565) that the
"never used" language was confusing for enum variants that were "used"
as match patterns, so the wording was changed to say never "constructed"
specifically for enum variants. More recently, the same issue was raised
for structs (#52325). It seems consistent to say "constructed" here,
too, for the same reasons.
~~While we're here, we can also use more specific word "called" for unused
functions and methods. (We declined to do this in #46103, but the
rationale given in the commit message doesn't actually make sense.)~~
This resolves#52325.
Reintroduce `Undef` and properly check constant value sizes
r? @RalfJung
cc @eddyb
basically all kinds of silent failures that never occurred are assertions now
resolve: Implement prelude search for macro paths, implement tool attributes
When identifier is macro path is resolved in scopes (i.e. the first path segment - `foo` in `foo::mac!()` or `foo!()`), scopes are searched in the same order as for non-macro paths - items in modules, extern prelude, tool prelude (see later), standard library prelude, language prelude, but with some extra shadowing restrictions (names from globs and macro expansions cannot shadow names from outer scopes). See the comment in `fn resolve_lexical_macro_path_segment` for more details.
"Tool prelude" currently contains two "tool modules" `rustfmt` and `clippy`, and is searched immediately after extern prelude.
This makes the [possible long-term solution](https://github.com/rust-lang/rfcs/blob/master/text/2103-tool-attributes.md#long-term-solution) for tool attributes exactly equivalent to the existing extern prelude scheme, except that `--extern=my_crate` making crate names available in scope is replaced with something like `--tool=my_tool` making tool names available in scope.
The `tool_attributes` feature is still unstable and `#![feature(tool_attributes)]` now implicitly enables `#![feature(use_extern_macros)]`. `use_extern_macros` is a prerequisite for `tool_attributes`, so their stabilization will happen in the same order.
If `use_extern_macros` is not enabled, then tool attributes are treated as custom attributes (this is temporary, anyway).
Fixes https://github.com/rust-lang/rust/issues/52576
Fixes https://github.com/rust-lang/rust/issues/52512
Fixes https://github.com/rust-lang/rust/issues/51277
cc https://github.com/rust-lang/rust/issues/52269
rustc_resolve: record single-segment extern crate import resolutions.
Fixes#52489 by recording special-cased single-segment imports for later (e.g. stability) checks.
cc @alexcrichton @Mark-Simulacrum @petrochenkov
Does this need to be backported?
Previously linker diagnostic were being hidden when two modules were linked
together but failed to link. This commit fixes the situation by ensuring that we
have a diagnostic handler installed and also adds support for handling linker
diagnostics.
do not overwrite child def-id in place but rather remove/insert
When inserting a node N into the tree of impls, we sometimes find than an existing node C should be replaced with N. We used to overwrite C in place with the new def-id N -- but since the lists of def-ids are separated by simplified type, that could lead to N being inserted in the wrong place. This meant we might miss conflicts. We are now not trying to be so smart -- we remove C and then add N later.
Fixes#52050
r? @aturon -- do you still remember this code at all? :)
Rollup of 16 pull requests
Successful merges:
- #52558 (Add tests for ICEs which no longer repro)
- #52610 (Clarify what a task is)
- #52617 (Don't match on region kinds when reporting NLL errors)
- #52635 (Fix #[linkage] propagation though generic functions)
- #52647 (Suggest to take and ignore args while closure args count mismatching)
- #52649 (Point spans to inner elements of format strings)
- #52654 (Format linker args in a way that works for gcc and ld)
- #52667 (update the stdsimd submodule)
- #52674 (Impl Executor for Box<E: Executor>)
- #52690 (ARM: expose `rclass` and `dsp` target features)
- #52692 (Improve readability in a few sorts)
- #52695 (Hide some lints which are not quite right the way they are reported to the user)
- #52718 (State default capacity for BufReader/BufWriter)
- #52721 (std::ops::Try impl for std::task::Poll)
- #52723 (rustc: Register crates under their real names)
- #52734 (sparc ABI issue - structure returning from function is returned in 64bit registers (with tests))
Failed merges:
- #52678 ([NLL] Use better spans in some errors)
r? @ghost
This is a sequel to November 2017's #46103 / 1a9dc2e9. It had been
reported (more than once—at least #19140, #44083, and #44565) that the
"never used" language was confusing for enum variants that were "used"
as match patterns, so the wording was changed to say never
"constructed" specifically for enum variants. More recently, the same
issue was raised for structs (#52325). It seems consistent to say
"constructed" here, too, for the same reasons.
We considered using more specific word "called" for unused functions
and methods (while we declined to do this in #46103, the rationale
given in the commit message doesn't actually make sense), but it turns
out that Cargo's test suite expects the "never used" message, and
maybe we don't care enough even to make a Cargo PR over such a petty
and subjective wording change.
This resolves#52325.
When inserting a node N into the tree of impls, we sometimes find than
an existing node C should be replaced with N. We used to overwrite C
in place with the new def-id N -- but since the lists of def-ids are
separated by simplified type, that could lead to N being inserted in
the wrong place. This meant we might miss conflicts. We are now not
trying to be so smart -- we remove C and then add N later.
improve error message shown for unsafe operations
Add a short explanation saying why undefined behavior could arise. In particular, the error many people got for "creating a pointer to a packed field requires unsafe block" was not worded great -- it lead to people just adding the unsafe block without considering if what they are doing follows the rules.
I am not sure if a "note" is the right thing, but that was the easiest thing to add...
Inspired by @gnzlbg at https://github.com/rust-lang/rust/issues/46043#issuecomment-381544673
use the adjusted type for cat_pattern in tuple patterns
This looks like a typo introduced in #51686.
Fixes#52213.
r? @pnkfelix
beta + stable nominating because regression + unsoundness.
Implement #[alloc_error_handler]
This to-be-stable attribute is equivalent to `#[lang = "oom"]`. It is required when using the `alloc` crate without the `std` crate. It is called by `handle_alloc_error`, which is in turned called by "infallible" allocations APIs such as `Vec::push`.
This to-be-stable attribute is equivalent to `#[lang = "oom"]`.
It is required when using the alloc crate without the std crate.
It is called by `handle_alloc_error`, which is in turned called
by "infallible" allocations APIs such as `Vec::push`.
refactor and cleanup region errors for NLL
This is a WIP commit. It simplifies some of the code from https://github.com/rust-lang/rust/pull/51536 and extends a few more steps towards the errors that @davidtwco and I were shooting for. These are intended as a replacement for the general "unable to infer lifetime" messages -- one that is actually actionable. We're certainly not there yet, but the overall shape hopefully gets a bit clearer.
I'm thinking about trying to open up an internals thread to sketch out the overall plan and perhaps discuss how to get the wording right, which special cases to handle, etc.
r? @estebank
cc @davidtwco
[NLL] Use better span for initializing a variable twice
Closes#51217
When assigning to a (projection from a) local immutable local which starts initialised (everything except `let PATTERN;`):
* Point to the declaration of that local
* Make the error message refer to the local, rather than the projection.
r? @nikomatsakis
Show known meta items in unknown meta items error
This PR adds a label to E0541. It also factors built-in attribute parsing into a submodule of `attr` for ease of future refactoring.
Fixes#51469.
Loosened rules involving statics mentioning other statics
Before this PR, trying to mention a static in any way other than taking a reference to it caused a compile-time error. So, while
```rust
static A: u32 = 42;
static B: &u32 = &A;
```
compiles successfully,
```rust
static A: u32 = 42;
static B: u32 = A; // error
```
and
```rust
static A: u32 = 42;
static B: u32 = *&A; // error
```
are not possible to express in Rust. On the other hand, introducing an intermediate `const fn` can presently allow one to do just that:
```rust
static A: u32 = 42;
static B: u32 = foo(&A); // success!
const fn foo(a: &u32) -> u32 {
*a
}
```
Preventing `const fn` from allowing to work around the ban on reading from statics would cripple `const fn` almost into uselessness.
Additionally, the limitation for reading from statics comes from the old const evaluator(s) and is not shared by `miri`.
This PR loosens the rules around use of statics to allow statics to evaluate other statics by value, allowing all of the above examples to compile and run successfully.
Reads from extern (foreign) statics are however still disallowed by miri, because there is no compile-time value to be read.
```rust
extern static A: u32;
static B: u32 = A; // error
```
This opens up a new avenue of potential issues, as a static can now not just refer to other statics or read from other statics, but even contain references that point into itself.
While it might seem like this could cause subtle bugs like allowing a static to be initialized by its own value, this is inherently impossible in miri.
Reading from a static causes the `const_eval` query for that static to be invoked. Calling the `const_eval` query for a static while already inside the `const_eval` query of said static will cause cycle errors.
It is not possible to accidentally create a bug in miri that would enable initializing a static with itself, because the memory of the static *does not exist* while being initialized.
The memory is not uninitialized, it is not there. Thus any change that would accidentally allow reading from a not yet initialized static would cause ICEs.
Tests have been modified according to the new rules, and new tests have been added for writing to `static mut`s within definitions of statics (which needs to fail), and incremental compilation with complex/interlinking static definitions.
Note that incremental compilation did not need to be adjusted, because all of this was already possible before with workarounds (like intermediate `const fn`s) and the encoding/decoding already supports all the possible cases.
r? @eddyb
Speed up compilation of large constant arrays
This is a different approach to #51672 as suggested by @oli-obk. Rather
than write each repeated value one-by-one, we write the first one and
then copy its value directly into the remaining memory.
With this change, the [toy program](c2f4744d2d/src/test/run-pass/mir_heavy_promoted.rs) goes from 63 seconds to 19 seconds on my machine.
Edit: Inlining `Size::bytes()` saves an additional 6 seconds dropping the total time to 13 seconds on my machine.
Edit2: Now down to 2.8 seconds.
r? @oli-obk
cc @nnethercote @eddyb
