Rename `source` to `span` and `span` to `source`
- Rename `clean::Item.source` to `span`
- Rename `clean::Span::span()` to `clean::Span::inner()`
- Rename `rustdoc_json_types::Item.source` to `span`
- rustdoc-json: Rename `Import.span` to `Import.source`
*See also the [discussion on Zulip][z] (this is a bit more than discussed in
that conversation, but all the changes are related).*
r? `@jyn514`
[z]: https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/get.20span.20of.20file.20from.20name/near/229603729
Use TrustedRandomAccess for in-place iterators where possible
This can speed up in-place iterators containing simple casts and transmutes from `Copy` types to any type of same size. `!Copy` types can't be optimized since `TrustedRandomAccess` isn't implemented for those iterators.
```
name on.b ns/iter o1.b ns/iter diff ns/iter diff % speedup
vec::bench_transmute 20 (40000 MB/s) 12 (66666 MB/s) -8 -40.00% x 1.67
```
This saves us both the Freeze/Unpin queries, and avoids placing
noalias attributes, which have a compile-time impact on LLVM
even in optnone builds (due to always_inline functions).
Such structures may contain self-references, in which case the
same location may be accessible through a pointer that is not
based-on the noalias pointer.
This is still grey area as far as language semantics are concerned,
but checking for !Unpin as an indicator for self-referential
sturctures seems like a good approach for the meantime.
Perform 'deep recollection' in test helper macros
Currently, the print helper macro performs 'recollection' by doing
`token_stream.into_iter().collect()`. However, this will not affect
nonterminals that occur nested inside delimited groups, since the
wrapping delimited group will be left untouched.
This commit adds 'deep recollection', which recursively recollects every
delimited group in the token stream. As with normal recollection, we
only print out something if deep recollection results in a different
stringified token stream.
This is useful for catching bugs where we update the AST of a
nonterminal (which affects pretty-printing), but do not update the
attatched `TokenStream`
Currently, the print helper macro performs 'recollection' by doing
`token_stream.into_iter().collect()`. However, this will not affect
nonterminals that occur nested inside delimited groups, since the
wrapping delimited group will be left untouched.
This commit adds 'deep recollection', which recursively recollects every
delimited group in the token stream. As with normal recollection, we
only print out something if deep recollection results in a different
stringified token stream.
This is useful for catching bugs where we update the AST of a
nonterminal (which affects pretty-printing), but do not update the
attatched `TokenStream`
Extend `proc_macro_back_compat` lint to `js-sys`
With this PR, we now lint for all cases where we perform some kind of
proc-macro back-compat hack.
The `js-sys` had an internal fix made to properly handle
`None`-delimited groups, so we need to manually check the version in the
filename. As a result, we no longer apply the back-compat hack to cases
where the version number is missing file the file path. This should not
affect any users of the `crates.io` crate.
const_evaluatable_checked: Stop eagerly erroring in `is_const_evaluatable`
Fixes#82279
We don't want to be emitting errors inside of is_const_evaluatable because we may call this during selection where it should be able to fail silently
There were two errors being emitted in `is_const_evaluatable`. The one causing the compile error in #82279 was inside the match arm for `FailureKind::MentionsParam` but I moved the other error being emitted too since it made things cleaner imo
The `NotConstEvaluatable` enum \*should\* have a fourth variant for when we fail to evaluate a concrete const, e.g. `0 - 1` but that cant happen until #81339
cc `@oli-obk` `@lcnr`
r? `@nikomatsakis`
Mark early otherwise optimization unsound
r? `@oli-obk`
cc `@tmiasko`
Related to #78496 and #82905
Should I also bump this one to level 3 or 4 or given that is unsound it doesn't matter?.
Probably need to adjust some tests.
With this PR, we now lint for all cases where we perform some kind of
proc-macro back-compat hack.
The `js-sys` had an internal fix made to properly handle
`None`-delimited groups, so we need to manually check the version in the
filename. As a result, we no longer apply the back-compat hack to cases
where the version number is missing file the file path. This should not
affect any users of the `crates.io` crate.
Replace closures_captures and upvar_capture with closure_min_captures
Removed all uses of closures_captures and upvar_capture and refactored code to work with closure_min_captures. This also involved removing functions that were no longer needed like the bridge.
Closes https://github.com/rust-lang/project-rfc-2229/issues/18
r? `@nikomatsakis`
Extend `proc_macro_back_compat` lint to `actix-web`
Unlike the other cases of this lint, there's no simple way to detect if
an old version of the relevant crate (`syn`) is in use. The `actix-web`
crate only depends on `pin-project` v1.0.0, so checking the version of
`actix-web` does not guarantee that a new enough version of
`pin-project` (and therefore `syn`) is in use.
Instead, we rely on the fact that virtually all of the regressed crates
are pinned to a pre-1.0 version of `pin-project`. When this is the case,
bumping the `actix-web` dependency will pull in the *latest* version of
`pin-project`, which has an explicit dependency on a newer v dependency
on a newer version of `syn`.
The lint message tells users to update `actix-web`, since that's what
they're most likely to have control over. We could potentially tell them
to run `cargo update -p syn`, but I think it's more straightforward to
suggest an explicit change to the `Cargo.toml`
The `actori-web` fork had its last commit over a year ago, and appears
to just be a renamed fork of `actix-web`. Therefore, I've removed the
`actori-web` check entirely - any crates that actually get broken can
simply update `syn` themselves.
rustdoc: allow list syntax for #[doc(alias)] attributes
Fixes https://github.com/rust-lang/rust/issues/81205.
It now allows to have:
```rust
#[doc(alias = "x")]
// and:
#[doc(alias("y", "z"))]
```
cc ``@jplatte``
r? ``@jyn514``
make changes to liveness to use closure_min_captures
use different span
borrow check uses new structures
rename to CapturedPlace
stop using upvar_capture in regionck
remove the bridge
cleanup from rebase + remove the upvar_capture reference from mutability_errors.rs
remove line from livenes test
make our unused var checking more consistent
update tests
adding more warnings to the tests
move is_ancestor_or_same_capture to rustc_middle/ty
update names to reflect the closures
add FIXME
check that all captures are immutable borrows before returning
add surrounding if statement like the original
move var out of the loop and rename
Co-authored-by: Logan Mosier <logmosier@gmail.com>
Co-authored-by: Roxane Fruytier <roxane.fruytier@hotmail.com>
Unlike the other cases of this lint, there's no simple way to detect if
an old version of the relevant crate (`syn`) is in use. The `actix-web`
crate only depends on `pin-project` v1.0.0, so checking the version of
`actix-web` does not guarantee that a new enough version of
`pin-project` (and therefore `syn`) is in use.
Instead, we rely on the fact that virtually all of the regressed crates
are pinned to a pre-1.0 version of `pin-project`. When this is the case,
bumping the `actix-web` dependency will pull in the *latest* version of
`pin-project`, which has an explicit dependency on a newer v dependency
on a newer version of `syn`.
The lint message tells users to update `actix-web`, since that's what
they're most likely to have control over. We could potentially tell them
to run `cargo update -p syn`, but I think it's more straightforward to
suggest an explicit change to the `Cargo.toml`
The `actori-web` fork had its last commit over a year ago, and appears
to just be a renamed fork of `actix-web`. Therefore, I've removed the
`actori-web` check entirely - any crates that actually get broken can
simply update `syn` themselves.
Allow registering tool lints with `register_tool`
Previously, there was no way to add a custom tool prefix, even if the tool
itself had registered a lint:
```rust
#![feature(register_tool)]
#![register_tool(xyz)]
#![warn(xyz::my_lint)]
```
```
$ rustc unknown-lint.rs --crate-type lib
error[E0710]: an unknown tool name found in scoped lint: `xyz::my_lint`
--> unknown-lint.rs:3:9
|
3 | #![warn(xyz::my_lint)]
| ^^^
```
This allows opting-in to lints from other tools using `register_tool`.
cc https://github.com/rust-lang/rust/issues/66079#issuecomment-788589193, ``@chorman0773``
r? ``@petrochenkov``
Extend `proc_macro_back_compat` lint to `procedural-masquerade`
We now lint on *any* use of `procedural-masquerade` crate. While this
crate still exists, its main reverse dependency (`cssparser`) no longer
depends on it. Any crates still depending off should stop doing so, as
it only exists to support very old Rust versions.
If a crate actually needs to support old versions of rustc via
`procedural-masquerade`, then they'll just need to accept the warning
until we remove it entirely (at the same time as the back-compat hack).
The latest version of `procedural-masquerade` does work with the
latest rustc, but trying to check for the version seems like more
trouble than it's worth.
While working on this, I realized that the `proc-macro-hack` check was
never actually doing anything. The corresponding enum variant in
`proc-macro-hack` is named `Value` or `Nested` - it has never been
called `Input`. Due to a strange Crater issue, the Crater run that
tested adding this did *not* end up testing it - some of the crates that
would have failed did not actually have their tests checked, making it
seem as though the `proc-macro-hack` check was working.
The Crater issue is being discussed at
https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/Nearly.20identical.20Crater.20runs.20processed.20a.20crate.20differently/near/230406661
Despite the `proc-macro-hack` check not actually doing anything, we
haven't gotten any reports from users about their build being broken.
I went ahead and removed it entirely, since it's clear that no one is
being affected by the `proc-macro-hack` regression in practice.
Make source-based code coverage compatible with MIR inlining
When codegenning code coverage use the instance that coverage data was
originally generated for, to ensure basic level of compatibility with
MIR inlining.
Fixes#83061
Emit error when trying to use assembler syntax directives in `asm!`
The `.intel_syntax` and `.att_syntax` assembler directives should not be used, in favor of not specifying a syntax for intel, and in favor of the explicit `att_syntax` option using the inline assembly options.
Closes#79869
