Target stack-probe support configurable finely
This adds capability to configure the target's stack probe support in a
more precise manner than just on/off. In particular now we allow
choosing between always inline-asm, always call or either one of those
depending on the LLVM version.
Note that this removes the ability to turn off the generation of the
stack-probe attribute. This is valid to replace it with inline-asm for all targets because
`probe-stack="inline-asm"` will not generate any machine code on targets
that do not currently support stack probes. This makes support for stack
probes on targets that don't have any right now automatic with LLVM
upgrades in the future.
(This is valid to do based on the fact that clang unconditionally sets
this attribute when `-fstack-clash-protection` is used, AFAICT)
cc #77885
r? `@cuviper`
Various ABI refactorings
This includes changes to the rust abi and various refactorings that will hopefully make it easier to use the abi handling infrastructure of rustc in cg_clif. There are several refactorings that I haven't done. I am opening this draft PR to check that I haven't broken any non x86_64 architectures.
r? `@ghost`
This gives compiler maintainers a better degree of control
over how the version gets parsed and is a good way to ensure
that there are no changes of behaviour in the future.
Also, issue a warning if the version is invalid instead of erroring
so that we stay forwards compatible with possible future changes
of the versioning scheme.
Last, this improves the present test a little.
Due to macro expansion, its possible to end up with two distinct
`ExpnId`s that have the same `ExpnData` contents. This violates the
contract of `HashStable`, since two unequal `ExpnId`s will end up with
equal `Fingerprint`s.
This commit adds a `disambiguator` field to `ExpnData`, which is used to
force two otherwise-equivalent `ExpnData`s to be distinct.
Fix <unknown> queries and add more timing info to render_html
Closes https://github.com/rust-lang/rust/issues/81251.
## Fix `<unknown>` queries
This happened because `alloc_query_strings` was never called.
## Add more timing info to render_html
This still has some issues I'm not sure how to work out:
- `create_renderer` and `renderer_after_krate` aren't shown by default.
I want something like `verbose_generic_activity_with_arg`, but it doesn't exist.
I'm also not sure how to show activities that aren't on by default - I
tried `-Z self-profile -Z self-profile-args=all`, but it didn't show up.
r? `@wesleywiser`
- Add the module name to `pre_AST_expansion_passes` and don't make it a
verbose event (since it normally doesn't take very long, and it's
emitted many times)
- Don't make the following rustdoc events verbose; they're emitted many times.
+ build_extern_trait_impl
+ build_local_trait_impl
+ build_primitive_trait_impl
+ get_auto_trait_impls
+ get_blanket_trait_impls
- Remove `get_auto_trait_and_blanket_synthetic_impls`; it's wholly
covered by get_{auto,blanket}_trait_impls and not very useful.
This avoids each tool having to separately find and call
`self_profile_alloc_strings`.
- Don't compute the global context if it hasn't yet been computed
This avoids giving extraneous errors about unresolved names if an error
occurs during parsing.
avoid promoting division, modulo and indexing operations that could fail
For division, `x / y` will still be promoted if `y` is a non-zero integer literal; however, `1/(1+1)` will not be promoted any more.
While at it, also see if we can reject promoting floating-point arithmetic (which are [complicated](https://github.com/rust-lang/unsafe-code-guidelines/issues/237) so maybe we should not promote them).
This will need a crater run to see if there's code out there that relies on these things being promoted.
If we can land this, promoteds in `fn`/`const fn` cannot fail to evaluate any more, which should let us do some simplifications in codegen/Miri!
Cc https://github.com/rust-lang/rfcs/pull/3027
Fixes https://github.com/rust-lang/rust/issues/61821
r? `@oli-obk`
Abi::ScalarPair is only ever used for types that don't have a stable
layout anyway so this doesn't break any FFI. It does however reduce the
amount of special casing on the abi outside of the code responsible for
abi specific adjustments to the pass mode.
Improve diagnostics when parsing angle args
https://github.com/rust-lang/rust/pull/79266 introduced parsing of generic arguments in associated type constraints, this however resulted in possibly very confusing error messages in cases in which closing angle brackets were missing such as in `Vec<(u32, _, _) = vec![]`, which outputs an incorrectly parsed equality constraint error, as noted by `@cynecx.`
This PR tries to provide better error messages in such cases.
r? `@petrochenkov`
Refactor token collection to capture trailing token immediately
Split out from https://github.com/rust-lang/rust/pull/80689 - when we start capturing more information about attribute targets, we'll need to know in advance if we're capturing a trailing token or not.
r? `@ghost`
Following traits are now diagnostic items:
- `From` (unchanged)
- `Into`
- `TryFrom`
- `TryInto`
This also adds symbols for those items:
- `into_trait`
- `try_from_trait`
- `try_into_trait`
Gracefully handle loop labels missing leading `'` in different positions
Fix#81192.
* Account for labels when suggesting `loop` instead of `while true`
* Suggest `'a` when given `a` only when appropriate
* Add loop head span to hir
* Tweak error for invalid `break expr`
* Add more misspelled label tests
* Avoid emitting redundant "unused label" lint
* Parse loop labels missing a leading `'`
Each commit can be reviewed in isolation.
Fix formatting for removed lints
- Don't add backticks for the reason a lint was removed. This is almost
never a code block, and when it is the backticks should be in the reason
itself.
- Don't assume clippy is the only tool that needs to be checked for
backwards compatibility
I split this out of https://github.com/rust-lang/rust/pull/80527/ because it kept causing tests to fail, and it's a good change to have anyway.
r? `@flip1995`
When encountering a name `a` that isn't resolved, but a label `'a` is
found in the current ribs, only suggest `'a` if this name is the value
expression of a `break` statement.
Solve FIXME.
Force token collection to run when parsing nonterminals
Fixes#81007
Previously, we would fail to collect tokens in the proper place when
only builtin attributes were present. As a result, we would end up with
attribute tokens in the collected `TokenStream`, leading to duplication
when we attempted to prepend the attributes from the AST node.
We now explicitly track when token collection must be performed due to
nomterminal parsing.
Remove --export-dynamic from the link arguments on the wasm32-wasi
target, as it emits spurious exports and increases code size.
Leave it in place for wasm32-unknown-unknown and
wasm32-unknown-emscripten. Even though it isn't a great solution
there, users are likely depending on its behavior there.
Fix ICE in mir when evaluating SizeOf on unsized type
Not quite ready yet. This tries to fix#80742 as discussed on [Zulip topic][1],
by using `delay_span_bug`.
I don't understand what `delay_span_bug` does. It seems like my error message
is never used. With this patch, in this program:
```rust
#![allow(incomplete_features)]
#![feature(const_evaluatable_checked)]
#![feature(const_generics)]
use std::fmt::Debug;
use std::marker::PhantomData;
use std::mem::size_of;
struct Inline<T>
where
[u8; size_of::<T>() + 1]: ,
{
_phantom: PhantomData<T>,
buf: [u8; size_of::<T>() + 1],
}
impl<T> Inline<T>
where
[u8; size_of::<T>() + 1]: ,
{
pub fn new(val: T) -> Inline<T> {
todo!()
}
}
fn main() {
let dst = Inline::<dyn Debug>::new(0); // line 27
}
```
these errors are printed, both for line 27 (annotated line above):
- "no function or associated item named `new` found for struct `Inline<dyn
Debug>` in the current scope"
- "the size for values of type `dyn Debug` cannot be known at compilation time"
Second error makes sense, but I'm not sure about the first one and why it's
even printed.
Finally, I'm not sure about the span passing in `const_eval`.
[1]: https://rust-lang.zulipchat.com/#narrow/stream/269128-miri/topic/Help.20fixing.20.2380742
Fixes#81007
Previously, we would fail to collect tokens in the proper place when
only builtin attributes were present. As a result, we would end up with
attribute tokens in the collected `TokenStream`, leading to duplication
when we attempted to prepend the attributes from the AST node.
We now explicitly track when token collection must be performed due to
nomterminal parsing.
Change link_sanitizer_runtime() to check if the sanitizer library exists
in the specified/session sysroot, and if it doesn't exist, use the
default sysroot.
Serialize dependency graph directly from DepGraph
Reduce memory usage by serializing dep graph directly from `DepGraph`,
rather than copying it into `SerializedDepGraph` and serializing that.
Fix `unused_unsafe` label with `unsafe_block_in_unsafe_fn
Previously, the following code:
```rust
#![feature(unsafe_block_in_unsafe_fn)]
unsafe fn foo() {
unsafe { unsf() }
}
unsafe fn unsf() {}
```
Would give the following warning:
```
warning: unnecessary `unsafe` block
--> src/lib.rs:4:5
|
4 | unsafe { unsf() }
| ^^^^^^ unnecessary `unsafe` block
|
= note: `#[warn(unused_unsafe)]` on by default
```
which doesn't point out that the block is in an `unsafe fn`.
Tracking issue: #71668
cc #79208
don't suggest erroneous trailing comma after `..`
In #76612, suggestions were added for missing fields in patterns. However, the suggestions are being inserted just at the end
of the last field in the pattern—before any trailing comma after the last field. This resulted in the "if you don't care about missing fields" suggestion to recommend code with a trailing comma after the field ellipsis (`..,`), which is actually not legal ("`..` must be at the end and cannot have a trailing comma")!
Incidentally, the doc-comment on `error_unmentioned_fields` was using `you_cant_use_this_field` as an example field name (presumably copy-paste inherited from the description of Issue #76077), but the present author found this confusing, because unmentioned fields aren't necessarily unusable.
The suggested code in the diff this commit introduces to `destructuring-assignment/struct_destructure_fail.stderr` doesn't work, but it didn't work beforehand, either (because of the "found reserved identifier `_`" thing), so you can't really call it a regression; it could be fixed in a separate PR.
Resolves#78511.
r? `@davidtwco` or `@estebank`
Stability oddity with const intrinsics
cc `@RalfJung`
In https://github.com/rust-lang/rust/pull/80699#discussion_r551495670 `@usbalbin` realized we accepted some intrinsics as `const` without a `#[rustc_const_(un)stable]` attribute. I did some digging, and that example works because intrinsics inherit their stability from their parents... including `#[rustc_const_(un)stable]` attributes. While we may want to fix that (not sure, wasn't there just a MCPed PR that caused this on purpose?), we definitely want tests for it, thus this PR adding tests and some fun tracing statements.
Prevents LateContext::maybe_typeck_results() from returning data in a
nested item without a body. Consequently, LateContext::qpath_res is less
likely to ICE when called in a nested item. Would have prevented
rust-lang/rust-clippy#4545, presumably.
Add track_caller to .steal()
Before:
```
thread 'rustc' panicked at 'attempt to read from stolen value', /home/joshua/rustc/compiler/rustc_data_structures/src/steal.rs:43:15
```
After:
```
thread 'rustc' panicked at 'attempt to steal from stolen value', compiler/rustc_mir/src/transform/mod.rs:423:25
```
r? `@lcnr`
Initialize a few variables directly
Currently they are declared as `mut`, get initialized to a default value, and
then possibly overwritten.
By initializing to the final value directly, they don't need to be `mut` and
it's clear that they don't get mutated elsewhere later on.
Use PlaceRef projection abstractions more consistently in rustc_mir
PlaceRef contains abstractions for dealing with the `projections` array. This PR uses these abstractions more consistently within the `rustc_mir` crate.
See associated issue: rust-lang/rust#80647.
r? `@RalfJung`
- Don't add backticks for the reason a lint was removed. This is almost
never a code block, and when it is the backticks should be in the reason
itself.
- Don't assume clippy is the only tool that needs to be checked for
backwards compatibility
Don't make tools responsible for checking unknown and renamed lints
Previously, clippy (and any other tool emitting lints) had to have their
own separate UNKNOWN_LINTS pass, because the compiler assumed any tool
lint could be valid. Now, as long as any lint starting with the tool
prefix exists, the compiler will warn when an unknown lint is present.
This may interact with the unstable `tool_lint` feature, which I don't entirely understand, but it will take the burden off those external tools to add their own lint pass, which seems like a step in the right direction to me.
- Don't mark `ineffective_unstable_trait_impl` as an internal lint
- Use clippy's more advanced lint suggestions
- Deprecate the `UNKNOWN_CLIPPY_LINTS` pass (and make it a no-op)
- Say 'unknown lint `clippy::x`' instead of 'unknown lint x'
This is tested by existing clippy tests. When https://github.com/rust-lang/rust/pull/80527 merges, it will also be tested in rustdoc tests. AFAIK there is no way to test this with rustc directly.
Before:
```
thread 'rustc' panicked at 'attempt to read from stolen value', /home/joshua/rustc/compiler/rustc_data_structures/src/steal.rs:43:15
```
After:
```
thread 'rustc' panicked at 'attempt to steal from stolen value', compiler/rustc_mir/src/transform/mod.rs:423:25
```
Use Option::unwrap_or instead of open-coding it
r? ```@oli-obk``` Noticed this while we were talking about the other PR just now 😆
```@rustbot``` modify labels +C-cleanup +T-compiler
Force vec![] to expression position only
r? `@oli-obk`
I went with the lazy way of only changing what broke. I moved the test to ui/macros because the diagnostics no longer give suggestions.
Closes#61933
resolve: Simplify collection of traits in scope
"Traits in scope" for a given location are collected by walking all scopes in type namespace, collecting traits in them and pruning traits that don't have an associated item with the given name and namespace.
Previously we tried to prune traits using some kind of hygienic resolution for associated items, but that was complex and likely incorrect, e.g. in #80762 correction to visibilites of trait items caused some traits to not be in scope anymore.
I previously had some comments and concerns about this in https://github.com/rust-lang/rust/pull/65351.
In this PR we are doing some much simpler pruning based on `Symbol` and `Namespace` comparisons, it should be enough to throw away 99.9% of unnecessary traits.
It is not necessary for pruning to be precise because for trait aliases, for example, we don't do any pruning at all, and precise hygienic resolution for associated items needs to be done in typeck anyway.
The somewhat unexpected effect is that trait imports introduced by macros 2.0 now bring traits into scope due to the removed hygienic check on associated item names.
I'm not sure whether it is desirable or not, but I think it's acceptable for now.
The old check was certainly incorrect because macros 2.0 did bring trait aliases into scope.
If doing this is not desirable, then we should come up with some other way to avoid bringing traits from macros 2.0 into scope, that would accommodate for trait aliases as well.
---
The PR also contains a couple of pure refactorings
- Scope walk is done by using `visit_scopes` instead of a hand-rolled version.
- Code is restructured to accomodate for rustdoc that also wants to query traits in scope, but doesn't want to filter them by associated items at all.
r? ```@matthewjasper```
Improve diagnostics when closure doesn't meet trait bound
Improves the diagnostics when closure doesn't meet trait bound by modifying `TypeckResuts::closure_kind_origins` such that `hir::Place` is used instead of `Symbol`. Using `hir::Place` to describe which capture influenced the decision of selecting a trait a closure satisfies to (Fn/FnMut/FnOnce, Copy) allows us to show precise path in the diagnostics when `capture_disjoint_field` feature is enabled.
Closes rust-lang/project-rfc-2229/issues/21
r? ```@nikomatsakis```
resolve: Reject ambiguity built-in attr vs different built-in attr
Fixes https://github.com/rust-lang/rust/issues/79798.
Resolution ensures that inert attributes cannot be used through imports like this, but built-in attributes don't go through initial resolution (only through resolution validation), so we have to keep some extra data (the built-in attribute name) to prevent it from happening.
correctly deal with late-bound lifetimes in anon consts
adds support for using late bound lifetimes of the parent context in anon consts.
```rust
#![feature(const_generics)]
const fn inner<'a>() -> usize where &'a (): Sized { 3 }
fn test<'a>() {
let _: [u8; inner::<'a>()];
}
```
The lifetime `'a` is late bound in `test` so it's not included in its generics but is instead dealt with separately in borrowck.
This didn't previously work for anon consts as they have to use the late bound lifetimes of their parent which has
to be explicitly handled.
r? ```@matthewjasper``` cc ```@varkor``` ```@eddyb```
Currently they are declared as `mut`, get initialized to a default value, and
then possibly overwritten.
By initializing to the final value directly, they don't need to be `mut` and
it's clear that they don't get mutated elsewhere later on.
In #76612, suggestions were added for missing fields in
patterns. However, the suggestions are being inserted just at the end
of the last field in the pattern—before any trailing comma after the
last field. This resulted in the "if you don't care about missing
fields" suggestion to recommend code with a trailing comma after the
field ellipsis (`..,`), which is actually not legal ("`..` must be at
the end and cannot have a trailing comma")!
Incidentally, the doc-comment on `error_unmentioned_fields` was using
`you_cant_use_this_field` as an example field name (presumably
copy-paste inherited from the description of Issue #76077), but
the present author found this confusing, because unmentioned fields
aren't necessarily unusable.
The suggested code in the diff this commit introduces to
`destructuring-assignment/struct_destructure_fail.stderr` doesn't
work, but it didn't work beforehand, either (because of the "found
reserved identifier `_`" thing), so you can't really call it a
regression; it could be fixed in a separate PR.
Resolves#78511.
Rollup of 17 pull requests
Successful merges:
- #78455 (Introduce {Ref, RefMut}::try_map for optional projections in RefCell)
- #80144 (Remove giant badge in README)
- #80614 (Explain why borrows can't be held across yield point in async blocks)
- #80670 (TrustedRandomAaccess specialization composes incorrectly for nested iter::Zips)
- #80681 (Clarify what the effects of a 'logic error' are)
- #80764 (Re-stabilize Weak::as_ptr and friends for unsized T)
- #80901 (Make `x.py --color always` apply to logging too)
- #80902 (Add a regression test for #76281)
- #80941 (Do not suggest invalid code in pattern with loop)
- #80968 (Stabilize the poll_map feature)
- #80971 (Put all feature gate tests under `feature-gates/`)
- #81021 (Remove doctree::Import)
- #81040 (doctest: Reset errors before dropping the parse session)
- #81060 (Add a regression test for #50041)
- #81065 (codegen_cranelift: Fix redundant semicolon warn)
- #81069 (Add sample code for Rc::new_cyclic)
- #81081 (Add test for #34792)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
This copies the unknown_lints code clippy uses for its
unknown_clippy_lints lint to rustc. The unknown_clippy_lints code is
more advanced, because it doesn't suggest renamed or removed lints and
correctly suggest lower casing lints.
implement ptr::write without dedicated intrinsic
This makes `ptr::write` more consistent with `ptr::write_unaligned`, `ptr::read`, `ptr::read_unaligned`, all of which are implemented in terms of `copy_nonoverlapping`.
This means we can also remove `move_val_init` implementations in codegen and Miri, and its special handling in the borrow checker.
Also see [this Zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/ptr.3A.3Aread.20vs.20ptr.3A.3Awrite).
This adds capability to configure the target's stack probe support in a
more precise manner than just on/off. In particular now we allow
choosing between always inline-asm, always call or either one of those
depending on the LLVM version on a per-target basis.
It's not an internal lint:
- It's not in the rustc::internal lint group
- It's on unconditionally, because it actually lints `staged_api`, not
the compiler
This fixes a bug where `#[deny(rustc::internal)]` would warn that
`rustc::internal` was an unknown lint.
Remove DepKind::CrateMetadata and pre-allocation of DepNodes
Remove much of the special-case handling around crate metadata
dependency tracking by replacing `DepKind::CrateMetadata` and the
pre-allocation of corresponding `DepNodes` with on-demand invocation
of the `crate_hash` query.
Previously, clippy (and any other tool emitting lints) had to have their
own separate UNKNOWN_LINTS pass, because the compiler assumed any tool
lint could be valid. Now, as long as any lint starting with the tool
prefix exists, the compiler will warn when an unknown lint is present.
Don't try to add nested predicate to Rustdoc auto-trait `ParamEnv`
Fixes#80233
We already have logic in `evaluate_predicates` that tries to add
unimplemented predicates to our `ParamEnv`. Trying to add a predicate
that already holds can lead to errors later on, since projection
will prefer trait candidates from the `ParamEnv` to predicates from an
impl.
Set tokens on AST node in `collect_tokens`
A new `HasTokens` trait is introduced, which is used to move logic from
the callers of `collect_tokens` into the body of `collect_tokens`.
In addition to reducing duplication, this paves the way for PR #80689,
which needs to perform additional logic during token collection.
Use better ICE message when no MIR is available
The ICE message is somewhat confusing and overly specific - the issue is
that there's no MIR available.
This should make debugging these ICEs easier since the error tells you
what's actually wrong, not what it was trying to do when it failed.
cc https://github.com/rust-lang/rust/pull/80952#issuecomment-759198841
cc `````@jyn514`````
Update tests of "unused_lifetimes" lint for async functions and corresponding source code
Before this PR the following code would cause an error:
```
#![deny(unused_lifetimes)]
async fn f<'a>(_: &'a i32) {}
fn main() {}
```
It was happening because of the desugaring of return type in async functions. As a result of the desugaring, the return type contains all lifetimes involved in the function signature. And these lifetimes were interpreted separately from the same in the function scope => so they are unused.
Now, all lifetimes from the return type are interpreted as used. It is also not perfect, but at least this lint doesn't cause wrong errors now.
This PR connected to issues #78522, #77217
A new `HasTokens` trait is introduced, which is used to move logic from
the callers of `collect_tokens` into the body of `collect_tokens`.
In addition to reducing duplication, this paves the way for PR #80689,
which needs to perform additional logic during token collection.
Properly handle `SyntaxContext` of dummy spans in incr comp
Fixes#80336
Due to macro expansion, we may end up with spans with an invalid
location and non-root `SyntaxContext`. This commits preserves the
`SyntaxContext` of such spans in the incremental cache, and ensures
that we always hash the `SyntaxContext` when computing the `Fingerprint`
of a `Span`
Previously, we would discard the `SyntaxContext` during serialization to
the incremental cache, causing the span's `Fingerprint` to change across
compilation sessions.
Rework diagnostics for wrong number of generic args (fixes#66228 and #71924)
This PR reworks the `wrong number of {} arguments` message, so that it provides more details and contextual hints.
Fixes#80336
Due to macro expansion, we may end up with spans with an invalid
location and non-root `SyntaxContext`. This commits preserves the
`SyntaxContext` of such spans in the incremental cache, and ensures
that we always hash the `SyntaxContext` when computing the `Fingerprint`
of a `Span`
Previously, we would discard the `SyntaxContext` during serialization to
the incremental cache, causing the span's `Fingerprint` to change across
compilation sessions.
Consistently avoid constructing optimized MIR when not doing codegen
The optimized MIR for closures is being encoded unconditionally, while
being unnecessary for cargo check. This turns out to be especially
costly with MIR inlining enabled, since it triggers computation of
optimized MIR for all callees that are being examined for inlining
purposes https://github.com/rust-lang/rust/pull/77307#issuecomment-751915450.
Skip encoding of optimized MIR for closures, enum constructors, struct
constructors, and trait fns when not doing codegen, like it is already
done for other items since 49433.
The ICE message is somewhat confusing and overly specific - the issue is
that there's no MIR available.
This should make debugging these ICEs easier since the error tells you
what's actually wrong, not what it was trying to do when it failed.
cc https://github.com/rust-lang/rust/pull/80952#issuecomment-759198841
For example, this code:
struct S(i32, f32);
let S(x) = S(0, 1.0);
will make the compiler suggest either:
let S(x, _) = S(0, 1.0);
or:
let S(x, ..) = S(0, 1.0);
