[ChrisDenton]

View all comments

This is only used internally and is only public because we didn't used to have the ability to gate internal functions used in public macros (other than using doc(hidden) to hide it).

[rustbot]

r? @joboet

rustbot has assigned @joboet.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: libs
• libs expanded to 37 candidates
• Random selection from JohnTitor, Mark-Simulacrum, clarfonthey, jhpratt, joboet

[ChrisDenton]

This might be overkill but I duplicated from_elem so the the standard library can fully act as if it's unstable. And it does avoid needing to allow deprecated.

View changes since the review

[clarfonthey]

Yeah, I dunno if there's an allow_internal_deprecated like allow_internal_unstable has.

[folkertdev]

We can hopefully use Vec::from_elem (perhaps named differently) for that soon (see rust-lang/libs-team#912)

[RalfJung]

I know it's internal but the name still doesn't seem that great (what is "global" about?). Maybe from_repeated_elem or so?

[ChrisDenton]

This has one use: in the vec! macro. If someone does not know (or can't find out) what global means in the context of allocating a Vec then they really should not be touching the macro at all. And I would really prefer its name not to diverge too far from its diagnostic item name. Especially not in this PR.

Btw, the best place to bikeshed this would be rust-lang/libs-team#912 since it proposes a stable API (though personally I'm not in favour of having a guaranteed specialisation wrapper before specialisation is stable).

[clarfonthey]

@rfcbot merge libs

Since this is technically an API change, even though this API should have been perma-unstable initially.

[rust-rfcbot]

@clarfonthey has proposed to merge this. The next step is review by the rest of the tagged team members:

• @ChrisDenton
• @Mark-Simulacrum
• @cuviper
• @dtolnay
• @joshtriplett
• @nia-e
• @the8472
• @thomcc

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/libs-ping: FCP proposed for libs, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[joboet]

r=me when FCP completes.

[rust-rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[RalfJung]

It does not seem correct to say that this was deprecated since Rust 1.0? This should be CURRENT_RUST_VERSION I think.

View changes since the review

[clarfonthey]

So, it was an internal detail since 1.0, it's only that we never prevented its use.

[theemathas]

I think that it should be CURRENT_RUST_VERSION, so people don't get confused about "why didn't I get a warning earlier?", and so they can figure out how "bad" the deprecation is based on recency.

[ChrisDenton]

Aside from adding the literal attribute, this isn't a recent deprecation. It's been deprecated for as long as it has existed. It was always wrong to use it (and we're only talking about a few crates that ever did).

People thinking it's less bad to use it since it's "only a recent deprecation" is exactly what I'd like to avoid.

[RalfJung]

I think it's reasonable to tie the version number to when the attribute was added. It's quite confusing otherwise if code previously was warning free, and now suddenly gets a warning effectively claiming that we warned against this since 1.0.

[ChrisDenton]

I will change because I've already spent way too much time arguing about a warning approximately nobody will ever see. However, I do think it's a bad mistake to treat this at all like a publicly documented function. The #[deprecated] lint is being used out of convenience and I strongly disagree that it should list the version the warning was added. That is not at all actionable information.

[cuviper]

Its previous state is more like what we usually call "soft deprecation".

[hanna-kruppe]

Strictly speaking, do we even need to put anything in since? It's technically optional...

[clarfonthey]

I think that putting in a note why we marked this as deprecated since 1.0 is enough to clear any concerns, but I'm not going to complain too hard.

We could also add a dedicated FCW that gets reported for dependencies too, which would be stronger than a deprecation but get the point across better.

[tgross35]

I will change because I've already spent way too much time arguing about a warning approximately nobody will ever see. However, I do think it's a bad mistake to treat this at all like a publicly documented function. The #[deprecated] lint is being used out of convenience and I strongly disagree that it should list the version the warning was added. That is not at all actionable information.

For what it's worth, I think 1.0 was probably the right choice: it reflects that this wasn't ever supposed to be usable, which is what users should be caring about. Why would a user ever care about having the error message show the deprecated attribute was added? Out lints don't say "lint emitted since 1.xx". If they're checking with two Rust versions then they've figured it out, if they care more than that then look at the blame 🤷‍♂️.

But agreed, it's not worth a battle.

[rust-rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

[ChrisDenton]

@bors r=joboet rollup

[rust-bors]

📌 Commit 458cde8 has been approved by joboet

It is now in the queue for this repository.

[jhpratt]

@bors r- #165480 (comment)

warning: use of deprecated function `std::vec::from_elem`: use the `vec!` macro instead
##[warning]  --> $DIR/vec-spec-extend-with-correct-drop.rs:47:19
   |
LL |     let mut vec = from_elem(DropCounter(&c), 3);
   |                   ^^^^^^^^^

warning: use of deprecated function `std::vec::from_elem`: use the `vec!` macro instead
##[warning]  --> $DIR/vec-spec-extend-with-correct-drop.rs:51:11
   |
LL |     vec = from_elem(DropCounter(&c), 6);
   |           ^^^^^^^^^

warning: use of deprecated function `std::vec::from_elem`: use the `vec!` macro instead
##[warning]  --> $DIR/vec-spec-extend-with-correct-drop.rs:56:11
   |
LL |     vec = from_elem(DropCounter(&c), 0);
   |           ^^^^^^^^^

warning: use of deprecated function `std::vec::from_elem`: use the `vec!` macro instead
##[warning]  --> $DIR/vec-spec-extend-with-correct-drop.rs:65:19
   |
LL |     let mut vec = from_elem(CloneCounter::new(&clones, &drops), 3);
   |                   ^^^^^^^^^

warning: use of deprecated function `std::vec::from_elem`: use the `vec!` macro instead
##[warning]  --> $DIR/vec-spec-extend-with-correct-drop.rs:72:11
   |
LL |     vec = from_elem(CloneCounter::new(&clones, &drops), 6);
   |           ^^^^^^^^^

warning: use of deprecated function `std::vec::from_elem`: use the `vec!` macro instead
##[warning]  --> $DIR/vec-spec-extend-with-correct-drop.rs:79:11
   |
LL |     vec = from_elem(CloneCounter::new(&clones, &drops), 0);
   |           ^^^^^^^^^

warning: 7 warnings emitted


---
To only update this specific test, also pass `--test-args array-slice-vec/vec-spec-extend-with-correct-drop.rs`

error: 1 errors occurred comparing output.
status: exit status: 0
command: env -u RUSTC_LOG_COLOR RUSTC_ICE="0" RUST_BACKTRACE="short" "/checkout/obj/build/aarch64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/tests/ui/array-slice-vec/vec-spec-extend-with-correct-drop.rs" "-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX" "-Ztranslate-remapped-path-to-local-path=no" "-Z" "ignore-directory-in-diagnostics-source-blocks=/cargo" "-Z" "ignore-directory-in-diagnostics-source-blocks=/checkout/vendor" "--sysroot" "/checkout/obj/build/aarch64-unknown-linux-gnu/stage2" "--target=aarch64-unknown-linux-gnu" "--check-cfg" "cfg(test,FALSE)" "-O" "--error-format" "json" "--json" "future-incompat" "-Ccodegen-units=1" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "-Zwrite-long-types-to-disk=no" "-Cstrip=debuginfo" "-C" "prefer-dynamic" "-o" "/checkout/obj/build/aarch64-unknown-linux-gnu/test/ui/array-slice-vec/vec-spec-extend-with-correct-drop/a" "-Znext-solver=coherence" "-A" "internal_features" "-A" "incomplete_features" "-A" "unused_parens" "-A" "unused_braces" "-Crpath" "-Cdebuginfo=0" "-Lnative=/checkout/obj/build/aarch64-unknown-linux-gnu/native/rust-test-helpers" "--edition=2015"
stdout: none
--- stderr -------------------------------
warning: use of deprecated function `std::vec::from_elem`: use the `vec!` macro instead
##[warning]  --> /checkout/tests/ui/array-slice-vec/vec-spec-extend-with-correct-drop.rs:6:15
   |
---

warning: use of deprecated function `std::vec::from_elem`: use the `vec!` macro instead
##[warning]  --> /checkout/tests/ui/array-slice-vec/vec-spec-extend-with-correct-drop.rs:47:19
   |
LL |     let mut vec = from_elem(DropCounter(&c), 3);
   |                   ^^^^^^^^^

warning: use of deprecated function `std::vec::from_elem`: use the `vec!` macro instead
##[warning]  --> /checkout/tests/ui/array-slice-vec/vec-spec-extend-with-correct-drop.rs:51:11
   |
LL |     vec = from_elem(DropCounter(&c), 6);
   |           ^^^^^^^^^

warning: use of deprecated function `std::vec::from_elem`: use the `vec!` macro instead
##[warning]  --> /checkout/tests/ui/array-slice-vec/vec-spec-extend-with-correct-drop.rs:56:11
   |
LL |     vec = from_elem(DropCounter(&c), 0);
   |           ^^^^^^^^^

warning: use of deprecated function `std::vec::from_elem`: use the `vec!` macro instead
##[warning]  --> /checkout/tests/ui/array-slice-vec/vec-spec-extend-with-correct-drop.rs:65:19
   |
LL |     let mut vec = from_elem(CloneCounter::new(&clones, &drops), 3);
   |                   ^^^^^^^^^

warning: use of deprecated function `std::vec::from_elem`: use the `vec!` macro instead
##[warning]  --> /checkout/tests/ui/array-slice-vec/vec-spec-extend-with-correct-drop.rs:72:11
   |
LL |     vec = from_elem(CloneCounter::new(&clones, &drops), 6);
   |           ^^^^^^^^^

warning: use of deprecated function `std::vec::from_elem`: use the `vec!` macro instead
##[warning]  --> /checkout/tests/ui/array-slice-vec/vec-spec-extend-with-correct-drop.rs:79:11
   |
LL |     vec = from_elem(CloneCounter::new(&clones, &drops), 0);
   |           ^^^^^^^^^

warning: 7 warnings emitted
------------------------------------------

[rust-bors]

This pull request was unapproved.

View changes since this unapproval

[ChrisDenton]

Why would we add UI test that uses from_elem?! Easy enough to replace I suppose.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[ChrisDenton]

Let's try again

@bors r=joboet rollup

[rust-bors]

📌 Commit ddfc252 has been tentatively approved by joboet

It will be put into the queue for this repository once PR CI succeeds.

[tgross35]

That is unbelievable timing, but it seems like they may actually want from_elem? Since #163757 mentions it in the description, cc @Paladynee.

[ChrisDenton]

Hm, if the intent is to test the UI of both extend_with and resize as well then those should be explicitly used since internals can change in many different ways. I don't think it should be using a proxy for that. On the other hand if only one thing needs to be tested then vec![elem; n] is fine.