Commit Graph

173 Commits

Author SHA1 Message Date
Pietro Albini
9e22b844dd remove cfg(bootstrap) 2021-05-24 11:07:48 -04:00
David Tolnay
34585cb678
impl FromStr for proc_macro::Literal 2021-05-19 11:38:24 -07:00
bors
e1ff91f439 Auto merge of - cbeuw:remap-std, r=michaelwoerister
Fix `--remap-path-prefix` not correctly remapping `rust-src` component paths and unify handling of path mapping with virtualized paths

This PR fixes  ("Binaries end up containing path to the rust-src component despite `--remap-path-prefix`") by preventing real local filesystem paths from reaching compilation output if the path is supposed to be remapped.

`RealFileName::Named` introduced in  is now renamed as `LocalPath`, because this variant wraps a (most likely) valid local filesystem path.

`RealFileName::Devirtualized` is renamed as `Remapped` to be used for remapped path from a real path via `--remap-path-prefix` argument, as well as real path inferred from a virtualized (during compiler bootstrapping) `/rustc/...` path. The `local_path` field is now an `Option<PathBuf>`, as it will be set to `None` before serialisation, so it never reaches any build output. Attempting to serialise a non-`None` `local_path` will cause an assertion faliure.

When a path is remapped, a `RealFileName::Remapped` variant is created. The original path is preserved in `local_path` field and the remapped path is saved in `virtual_name` field. Previously, the `local_path` is directly modified which goes against its purpose of "suitable for reading from the file system on the local host".

`rustc_span::SourceFile`'s fields `unmapped_path` (introduced by ) and `name_was_remapped` (introduced by  when `--remap-path-prefix` feature originally added) are removed, as these two pieces of information can be inferred from the `name` field: if it's anything other than a `FileName::Real(_)`, or if it is a `FileName::Real(RealFileName::LocalPath(_))`, then clearly `name_was_remapped` would've been false and `unmapped_path` would've been `None`. If it is a `FileName::Real(RealFileName::Remapped{local_path, virtual_name})`, then `name_was_remapped` would've been true and `unmapped_path` would've been `Some(local_path)`.

cc `@eddyb` who implemented `/rustc/...` path devirtualisation
2021-05-12 11:05:56 +00:00
Aaron Hill
f916b0474a
Implement span quoting for proc-macros
This PR implements span quoting, allowing proc-macros to produce spans
pointing *into their own crate*. This is used by the unstable
`proc_macro::quote!` macro, allowing us to get error messages like this:

```
error[E0412]: cannot find type `MissingType` in this scope
  --> $DIR/auxiliary/span-from-proc-macro.rs:37:20
   |
LL | pub fn error_from_attribute(_args: TokenStream, _input: TokenStream) -> TokenStream {
   | ----------------------------------------------------------------------------------- in this expansion of procedural macro `#[error_from_attribute]`
...
LL |             field: MissingType
   |                    ^^^^^^^^^^^ not found in this scope
   |
  ::: $DIR/span-from-proc-macro.rs:8:1
   |
LL | #[error_from_attribute]
   | ----------------------- in this macro invocation
```

Here, `MissingType` occurs inside the implementation of the proc-macro
`#[error_from_attribute]`. Previosuly, this would always result in a
span pointing at `#[error_from_attribute]`

This will make many proc-macro-related error message much more useful -
when a proc-macro generates code containing an error, users will get an
error message pointing directly at that code (within the macro
definition), instead of always getting a span pointing at the macro
invocation site.

This is implemented as follows:
* When a proc-macro crate is being *compiled*, it causes the `quote!`
  macro to get run. This saves all of the sapns in the input to `quote!`
  into the metadata of *the proc-macro-crate* (which we are currently
  compiling). The `quote!` macro then expands to a call to
  `proc_macro::Span::recover_proc_macro_span(id)`, where `id` is an
opaque identifier for the span in the crate metadata.
* When the same proc-macro crate is *run* (e.g. it is loaded from disk
  and invoked by some consumer crate), the call to
`proc_macro::Span::recover_proc_macro_span` causes us to load the span
from the proc-macro crate's metadata. The proc-macro then produces a
`TokenStream` containing a `Span` pointing into the proc-macro crate
itself.

The recursive nature of 'quote!' can be difficult to understand at
first. The file `src/test/ui/proc-macro/quote-debug.stdout` shows
the output of the `quote!` macro, which should make this eaier to
understand.

This PR also supports custom quoting spans in custom quote macros (e.g.
the `quote` crate). All span quoting goes through the
`proc_macro::quote_span` method, which can be called by a custom quote
macro to perform span quoting. An example of this usage is provided in
`src/test/ui/proc-macro/auxiliary/custom-quote.rs`

Custom quoting currently has a few limitations:

In order to quote a span, we need to generate a call to
`proc_macro::Span::recover_proc_macro_span`. However, proc-macros
support renaming the `proc_macro` crate, so we can't simply hardcode
this path. Previously, the `quote_span` method used the path
`crate::Span` - however, this only works when it is called by the
builtin `quote!` macro in the same crate. To support being called from
arbitrary crates, we need access to the name of the `proc_macro` crate
to generate a path. This PR adds an additional argument to `quote_span`
to specify the name of the `proc_macro` crate. Howver, this feels kind
of hacky, and we may want to change this before stabilizing anything
quote-related.

Additionally, using `quote_span` currently requires enabling the
`proc_macro_internals` feature. The builtin `quote!` macro
has an `#[allow_internal_unstable]` attribute, but this won't work for
custom quote implementations. This will likely require some additional
tricks to apply `allow_internal_unstable` to the span of
`proc_macro::Span::recover_proc_macro_span`.
2021-05-12 00:51:31 -04:00
Dylan DPC
0c8c21d224
Rollup merge of - jyn514:doc-cfg, r=petrochenkov
Unify rustc and rustdoc parsing of `cfg()`

This extracts a new `parse_cfg` function that's used between both.

- Treat `#[doc(cfg(x), cfg(y))]` the same as `#[doc(cfg(x)]
  #[doc(cfg(y))]`. Previously it would be completely ignored.
- Treat `#[doc(inline, cfg(x))]` the same as `#[doc(inline)]
  #[doc(cfg(x))]`. Previously, the cfg would be ignored.
- Pass the cfg predicate through to rustc_expand to be validated

Technically this is a breaking change, but doc_cfg is still nightly so I don't think it matters.

Fixes https://github.com/rust-lang/rust/issues/84437.

r? `````````@petrochenkov`````````
2021-05-07 16:19:19 +02:00
Deadbeef
4617b03316
E0583: Include secondary path in error message 2021-05-06 09:40:05 +08:00
Andy Wang
5417b45c26
Use local and remapped paths where appropriate 2021-05-05 15:31:28 +01:00
Andy Wang
9e0426d784
Make local_path in RealFileName::Remapped Option to be removed in exported metadata 2021-05-05 15:10:57 +01:00
Andy Wang
6720a37042
Rename RealFileName::Named to LocalPath and Devirtualized to Remapped 2021-05-05 15:10:50 +01:00
Joshua Nelson
6eb4735acc Unify rustc and rustdoc parsing of cfg()
This extracts a new `parse_cfg` function that's used between both.

- Treat `#[doc(cfg(x), cfg(y))]` the same as `#[doc(cfg(x)]
  #[doc(cfg(y))]`. Previously it would be completely ignored.
- Treat `#[doc(inline, cfg(x))]` the same as `#[doc(inline)]
  #[doc(cfg(x))]`. Previously, the cfg would be ignored.
- Pass the cfg predicate through to rustc_expand to be validated

Co-authored-by: Vadim Petrochenkov <vadim.petrochenkov@gmail.com>
2021-05-03 12:49:43 -04:00
hi-rustin
461f52071d use full path for E0761 2021-05-03 18:57:48 +08:00
hi-rustin
f758eb664e use double quotes for E0761 2021-05-03 16:02:54 +08:00
bors
bcd696d722 Auto merge of - crlf0710:impl_main_by_path, r=petrochenkov
Implement RFC 1260 with feature_name `imported_main`.

This is the second extraction part of  plus additional adjustments.
This (mostly) implements RFC 1260.

However there's still one test case failure in the extern crate case. Maybe `LocalDefId` doesn't work here? I'm not sure.

cc https://github.com/rust-lang/rust/issues/28937
r? `@petrochenkov`
2021-04-30 06:59:37 +00:00
Charles Lew
d261df4a72 Implement RFC 1260 with feature_name imported_main. 2021-04-29 08:35:08 +08:00
bors
ca075d268d Auto merge of - mark-i-m:stabilize-pat2015, r=nikomatsakis
Stabilize `:pat_param` and remove `:pat2021`

Blocked on 

cc `@rust-lang/lang` 

If I understand `@nikomatsakis` in  https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/or.20patterns/near/231133873, another FCP is not needed.

r? `@nikomatsakis`
2021-04-28 20:35:17 +00:00
mark
2a9db919ff remove pat2021 2021-04-27 21:15:59 -05:00
klensy
f43ee8ebf6 fix few typos 2021-04-19 15:57:08 +03:00
mark
0566ccc72f rename pat2015 to pat_param 2021-04-15 13:52:09 -05:00
mark
ebc4acee91 stabilize :pat2015, leave :pat2021 gated 2021-04-15 13:52:09 -05:00
Aaron Hill
a93c4f05de
Implement token-based handling of attributes during expansion
This PR modifies the macro expansion infrastructure to handle attributes
in a fully token-based manner. As a result:

* Derives macros no longer lose spans when their input is modified
  by eager cfg-expansion. This is accomplished by performing eager
  cfg-expansion on the token stream that we pass to the derive
  proc-macro
* Inner attributes now preserve spans in all cases, including when we
  have multiple inner attributes in a row.

This is accomplished through the following changes:

* New structs `AttrAnnotatedTokenStream` and `AttrAnnotatedTokenTree` are introduced.
  These are very similar to a normal `TokenTree`, but they also track
  the position of attributes and attribute targets within the stream.
  They are built when we collect tokens during parsing.
  An `AttrAnnotatedTokenStream` is converted to a regular `TokenStream` when
  we invoke a macro.
* Token capturing and `LazyTokenStream` are modified to work with
  `AttrAnnotatedTokenStream`. A new `ReplaceRange` type is introduced, which
  is created during the parsing of a nested AST node to make the 'outer'
  AST node aware of the attributes and attribute target stored deeper in the token stream.
* When we need to perform eager cfg-expansion (either due to `#[derive]` or `#[cfg_eval]`),
we tokenize and reparse our target, capturing additional information about the locations of
`#[cfg]` and `#[cfg_attr]` attributes at any depth within the target.
This is a performance optimization, allowing us to perform less work
in the typical case where captured tokens never have eager cfg-expansion run.
2021-04-11 01:31:36 -04:00
Aaron Hill
21e6cc19fe
Expand derive invocations in left-to-right order
While derives were being collected in left-to-order order, the
corresponding `Invocation`s were being pushed in the wrong order.
2021-04-10 17:29:20 -04:00
Dylan DPC
4d5bb1ca22
Rollup merge of - JohnTitor:unused-doc-comments-on-macros, r=varkor
Trigger `unused_doc_comments` on macros at once

Fixes 
2021-04-07 13:07:12 +02:00
Yuki Okushi
67ffbedada
Rollup merge of - petrochenkov:emptyexpr, r=davidtwco
expand: Do not ICE when a legacy AST-based macro attribute produces and empty expression

Fixes https://github.com/rust-lang/rust/issues/80251

The reported error is the same as for `let _ = #[cfg(FALSE)] EXPR;`
2021-04-06 06:24:12 +09:00
Vadim Petrochenkov
fbf1bec482 resolve/expand: Cache intermediate results of #[derive] expansion 2021-04-04 17:51:41 +03:00
Yuki Okushi
81f00c98a6 Trigger unused_doc_comments on macros at once 2021-04-04 05:06:51 +09:00
Vadim Petrochenkov
cd22425990 expand: Do not ICE when a legacy AST-based macro attribute produces and empty expression 2021-04-03 19:42:09 +03:00
hi-rustin
aa987c2f57 address comments 2021-04-02 08:08:02 +08:00
hi-rustin
2c66e15468 add OR_PATTERNS_BACK_COMPAT lint
test: add more cases

test: add comments

refine msg
2021-04-01 23:14:14 +08:00
Joshua Nelson
441dc3640a Remove (lots of) dead code
Found with https://github.com/est31/warnalyzer.

Dubious changes:
- Is anyone else using rustc_apfloat? I feel weird completely deleting
  x87 support.
- Maybe some of the dead code in rustc_data_structures, in case someone
  wants to use it in the future?
- Don't change rustc_serialize

  I plan to scrap most of the json module in the near future (see
  https://github.com/rust-lang/compiler-team/issues/418) and fixing the
  tests needed more work than I expected.

TODO: check if any of the comments on the deleted code should be kept.
2021-03-27 22:16:33 -04:00
Dylan DPC
b2e254318d
Rollup merge of - cuviper:iter-zip, r=m-ou-se
Add function core::iter::zip

This makes it a little easier to `zip` iterators:

```rust
for (x, y) in zip(xs, ys) {}
// vs.
for (x, y) in xs.into_iter().zip(ys) {}
```

You can `zip(&mut xs, &ys)` for the conventional `iter_mut()` and
`iter()`, respectively. This can also support arbitrary nesting, where
it's easier to see the item layout than with arbitrary `zip` chains:

```rust
for ((x, y), z) in zip(zip(xs, ys), zs) {}
for (x, (y, z)) in zip(xs, zip(ys, zs)) {}
// vs.
for ((x, y), z) in xs.into_iter().zip(ys).zip(xz) {}
for (x, (y, z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {}
```

It may also format more nicely, especially when the first iterator is a
longer chain of methods -- for example:

```rust
    iter::zip(
        trait_ref.substs.types().skip(1),
        impl_trait_ref.substs.types().skip(1),
    )
    // vs.
    trait_ref
        .substs
        .types()
        .skip(1)
        .zip(impl_trait_ref.substs.types().skip(1))
```

This replaces the tuple-pair `IntoIterator` in .
There is prior art for the utility of this in [`itertools::zip`].

[`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html
2021-03-27 20:37:07 +01:00
Josh Stone
72ebebe474 Use iter::zip in compiler/ 2021-03-26 09:32:31 -07:00
Aaron Hill
fe60f19f7e
Ban custom inner attributes in expressions and statements 2021-03-25 18:05:30 -04:00
Yuki Okushi
50d048f142
Rollup merge of - mark-i-m:rename-pat2018, r=joshtriplett
rename :pat2018 -> :pat2015

as requested by T-lang on zulip: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/or.20patterns/near/231133873

No functional changes here... just renaming.

r? `@nikomatsakis`
2021-03-23 10:15:43 +09:00
bors
5d04957a4b Auto merge of - mark-i-m:stabilize-or-pattern, r=nikomatsakis
Stabilize or_patterns (RFC 2535, 2530, 2175)

closes 

This PR stabilizes the or_patterns feature in Rust 1.53.

This is blocked on the following (in order):
- [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021
- [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705)
    - It looks like we will need to pursue some sort of edition-based transition for `:pat`.
- [x] Nomination and discussion by T-lang
- [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100).
- [ ] An FCP on stabilization

EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177
2021-03-22 19:48:27 +00:00
mark
8c4b3dbb50 rename :pat2018 -> :pat215 2021-03-22 12:40:23 -05:00
mark
db5629adcb stabilize or_patterns 2021-03-19 19:45:32 -05:00
Aaron Hill
f6a35d7df2
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.
2021-03-19 14:40:20 -04:00
Aaron Hill
390d1ef6d0
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.
2021-03-18 12:09:14 -04:00
Dylan DPC
7cd7dee315
Rollup merge of - Aaron1011:lint-procedural-masquerade, 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.
2021-03-18 00:28:10 +01:00
Vadim Petrochenkov
d1522b39dd ast: Reduce size of ExprKind by boxing fields of ExprKind::Struct 2021-03-16 11:41:24 +03:00
Vadim Petrochenkov
b25d3ba781 ast/hir: Rename field-related structures
StructField -> FieldDef ("field definition")
Field -> ExprField ("expression field", not "field expression")
FieldPat -> PatField ("pattern field", not "field pattern")

Also rename visiting and other methods working on them.
2021-03-16 11:41:24 +03:00
Aaron Hill
d6a7c1d47f
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 not 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.
2021-03-15 16:00:49 -04:00
Aaron Hill
f190bc4f47
Introduce proc_macro_back_compat lint, and emit for time-macros-impl
Now that future-incompat-report support has landed in nightly Cargo, we
can start to make progress towards removing the various proc-macro
back-compat hacks that have accumulated in the compiler.

This PR introduces a new lint `proc_macro_back_compat`, which results in
a future-incompat-report entry being generated. All proc-macro
back-compat warnings will be grouped under this lint. Note that this
lint will never actually become a hard error - instead, we will remove
the special cases for various macros, which will cause older versions of
those crates to emit some other error.

I've added code to fire this lint for the `time-macros-impl` case. This
is the easiest case out of all of our current back-compat hacks - the
crate was renamed to `time-macros`, so seeing a filename with
`time-macros-impl` guarantees that an older version of the parent `time`
crate is in use.

When Cargo's future-incompat-report feature gets stabilized, affected
users will start to see future-incompat warnings when they build their
crates.
2021-03-14 21:31:46 -04:00
Vadim Petrochenkov
a4cc3cae04 expand: Resolve and expand inner attributes on out-of-line modules 2021-03-14 18:10:29 +03:00
bors
338647db73 Auto merge of - petrochenkov:allunst, r=oli-obk
expand: Do not allocate `Lrc` for `allow_internal_unstable` list unless necessary

This allocation is done for any macro defined in the current crate, or used from a different crate.
EDIT: This also removes an `Lrc` increment from each *use* of such macro, which may be more significant.
Noticed when reviewing https://github.com/rust-lang/rust/pull/82367.
This probably doesn't matter, but let's do a perf run.
2021-03-12 11:46:50 +00:00
Dylan DPC
9c310571a8
Rollup merge of - petrochenkov:cfgeval, r=Aaron1011
Implement built-in attribute macro `#[cfg_eval]` + some refactoring

This PR implements a built-in attribute macro `#[cfg_eval]` as it was suggested in https://github.com/rust-lang/rust/pull/79078 to avoid `#[derive()]` without arguments being abused as a way to configure input for other attributes.

The macro is used for eagerly expanding all `#[cfg]` and `#[cfg_attr]` attributes in its input ("fully configuring" the input).
The effect is identical to effect of `#[derive(Foo, Bar)]` which also fully configures its input before passing it to macros `Foo` and `Bar`, but unlike `#[derive]` `#[cfg_eval]` can be applied to any syntax nodes supporting macro attributes, not only certain items.

`cfg_eval` was the first name suggested in https://github.com/rust-lang/rust/pull/79078, but other alternatives are also possible, e.g. `cfg_expand`.

```rust
#[cfg_eval]
#[my_attr] // Receives `struct S {}` as input, the field is configured away by `#[cfg_eval]`
struct S {
    #[cfg(FALSE)]
    field: u8,
}
```

Tracking issue: https://github.com/rust-lang/rust/issues/82679
2021-03-08 13:13:23 +01:00
Dylan DPC
4a4e3e667d
Rollup merge of - petrochenkov:modin3, r=davidtwco
expand: Refactor module loading

This is an accompanying PR to https://github.com/rust-lang/rust/pull/82399, but they can be landed independently.
See individual commits for more details.

Anyone should be able to review this equally well because all people actually familiar with this code left the project.
2021-03-08 13:13:19 +01:00
Vadim Petrochenkov
f9019b7086 Move full configuration logic from rustc_expand to rustc_builtin_macros
This logic is applicable to two specific macros and not to the expansion infrastructure in general.
2021-03-07 00:17:31 +03:00
Vadim Petrochenkov
069e612e73 rustc_ast: Replace AstLike::finalize_tokens with a getter tokens_mut 2021-03-06 21:19:31 +03:00
bors
a0d66b54fb Auto merge of - estebank:inherit-stability, r=nikomatsakis
Inherit `#[stable(..)]` annotations in enum variants and fields from its item

Lint changes for . The stdlib will have to be updated once this lands in beta and that version is promoted in master.
2021-03-05 05:28:07 +00:00