add explicit download methods #14
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rust-lang#15105) No longer suggests `&[i32]` or `&mut [i32]` instead of `&Vec<i32>` or `&mut Vec<i32>` (also: `Path` and `PathBuf`, etc.) for the parameter type when the parameter name starts with an underscore (or, if that does not start with one, then a local `let` binding in the function body, pointing to the same value, does) – (Fixes rust-lang/rust-clippy#13489, fixes rust-lang/rust-clippy#13728) ~changelog: fix false positive: [`ptr_arg`] no longer triggers with underscore binding to `&mut` argument~ changelog: fix false positive: [`ptr_arg`] no longer triggers with underscore binding to `&T` or `&mut T` argument *Edit:* This change has been extended to all references, not just mutable ones. See [discussion below](#issuecomment-3006386877).
Fixes rust-lang/rust-clippy#15151 See also https://rust-lang.zulipchat.com/#narrow/channel/257328-clippy/topic/uninlined_format_args.20is.20contentious/ changelog: Move [`uninlined_format_args`] to `pedantic`
…4432) To avoid false positives, the `range_plus_one` and `range_minus_one` lints will restrict themselves to situations where the iterator types can be easily switched from exclusive to inclusive or vice-versa. This includes situations where the range is used as an iterator, or is used for indexing. On the other hand, assignments of the range to variables, including automatically typed ones or wildcards, will no longer trigger the lint. However, the cases where such an assignment would benefit from the lint are probably rare. In a second commit, the `range_plus_one` and `range_minus_one` logic are unified, in order to properly emit parentheses around the suggestion when needed. Fix rust-lang/rust-clippy#3307 Fix rust-lang/rust-clippy#9908 changelog: [`range_plus_one`, `range_minus_one`]: restrict lint to cases where it is safe to switch the range type *Edit:* as a consequence, this led to the removal of three `#[expect(clippy::range_plus_one)]` in the Clippy sources to avoid those false positives.
This PR supersedes rust-lang#14328 following the [2025-03-18 Clippy meeting discussion](https://rust-lang.zulipchat.com/#narrow/channel/257328-clippy/topic/Meeting.202025-03-18/with/506527762). It uses a simpler approach than what was proposed initially in rust-lang#14328 and does not add new options. First, it documents how `cfg_attr` can be used to change the MSRV considered by Clippy to trigger the lint. This allows the MSRV to be feature gated, or to be raised in tests. Also, the lint stops warning about items which have been explicitly allowed through a rustc feature. This works even if the feature has been stabilized since. It allows using an older compiler with some features turned on, as is done in Rust for Linux. This fixes rust-lang#14425. Then, if the lint triggers, and it looks like the code is located below a `cfg` or `cfg_attr` attribute, an additional note is issued, once, to indicate that the `clippy::msrv` attribute can be controlled by an attribute. Finally, the lint is extended to cover any path, not just method and function calls. For example, enumeration variants, or constants, were not MSRV checked. This required replacing two `u32::MAX` by `u32::max_value()` in MSRV-limited tests. An extra commit adds a TODO for checking the const stability also, as this is not done right now. @Centri3 I'll assign this to you because you were assigned rust-lang#14328 and you were the one who nominated the issue for discussion (thanks!), but of course feel free to reroll! r? @Centri3 changelog: [`incompatible_msrv`]: better documentation, honor the `features` attribute, and lint non-function entities as well
Closes rust-lang/rust-clippy#15283 ---- changelog: [`ptr_as_ptr`]: fix wrong suggestions with turbo fish
There are many places that join path segments with `::` to produce a
string. A lot of these use `join("::")`. Many in rustdoc use
`join_with_double_colon`, and a few use `.joined("..")`. One in Clippy
uses `itertools::join`. A couple of them look for `kw::PathRoot` in the
first segment, which can be important.
This commit introduces `rustc_ast::join_path_{syms,ident}` to do the
joining for everyone. `rustc_ast` is as good a location for these as
any, being the earliest-running of the several crates with a `Path`
type. Two functions are needed because `Ident` printing is more complex
than simple `Symbol` printing.
The commit also removes `join_with_double_colon`, and
`estimate_item_path_byte_length` with it.
There are still a handful of places that join strings with "::" that are
unchanged. They are not that important: some of them are in tests, and
some of them first split a path around "::" and then rejoin with "::".
This fixes one test case where `{{root}}` shows up in an error message.
Improve path segment joining Currently paths are joined with `::` in many places, in a variety of ways. This PR unifies things. r? ``@petrochenkov``
…taxes-rewording, r=traviscross,jieyouxu Reword mismatched-lifetime-syntaxes text based on feedback Key changes include: - Removal of the word "syntax" from the lint message. More accurately, it could have been something like "syntax group" or "syntax category", but avoiding it completely is easier. - The primary lint message now reflects exactly which mismatch is occurring, instead of trying to be general. A new `help` line is general across the mismatch kinds. - Suggestions have been reduced to be more minimal, no longer also changing non-idiomatic but unrelated aspects. - Suggestion text no longer mentions changes when those changes don't occur in that specific suggestion. r? ``@jieyouxu``
For example, the `Duration` type from the standard library was only introduced in Rust 1.3.0.
For example, the `Duration` type from the standard library was only introduced in Rust 1.3.0. changelog: [`incompatible_msrv`]: recognize types exceeding MSRV as well r? Jarcho @rustbot label +C-bug +I-false-negative
This makes `const` contexts use the `const`-stability version information instead of the regular stability one, as `const`-stability may happen much later than stability in non-`const` contexts.
… r=fmease parse `const trait Trait` r? oli-obk or anyone from project-const-traits cc `@rust-lang/project-const-traits`
changelog: [`pattern_type_mismatch`]: fix unwanted hit in external macro
This makes `const` contexts use the `const`-stability version information instead of the regular stability one, as `const`-stability may happen much later than stability in non-`const` contexts. ~~It includes the content of PR rust-lang/rust-clippy#15296 as its first commit. I separated them because this one is more complex, and rust-lang/rust-clippy#15296 may be merged more rapidly.~~ changelog: [`incompatible_msrv`]: check the right MSRV when in a `const` context r? Jarcho @rustbot label +C-bug +I-false-negative
This is blocking rust-lang/rust-clippy#14724 changelog: none
) Take to account that we don't have lints under under `None` for `LEVEL_FILTERS_DEFAULT` so far https://rust-lang.github.io/rust-clippy/master/index.html?levels=none, we can remove it. changelog: none
This is blocking rust-lang/rust-clippy#14724 changelog: none
Closes rust-lang/rust-clippy#15309 changelog: [`needless_range_loop`] fix FP on array literals
…ang#15048) Closes rust-lang/rust-clippy#15047 changelog: [`filter_map_bool_then`] fix wrongly showed macro definitions in suggestions
…ust-lang#15313) Closes rust-lang/rust-clippy#15301 changelog: [`missing_inline_in_public_items`] fix FP on functions with `extern`
) Closes rust-lang/rust-clippy#15007 Removes the `break` stmt and the dead code after it when appropriate. changelog: [`never_loop`] Make sure to remove `break` in suggestions
…g#15124) Fixes rust-lang/rust-clippy#14882 changelog: [`single_match`]: fix ICE with deref patterns and string literals
…only, r=compiler-errors Limit defaultness query to impl of trait I separated this out from rust-lang#144386.
…rgs, r=RalfJung Allow pretty printing paths with `-Zself-profile-events=args` `-Zself-profile-events=args` is pretty heavy and can pretty print a lot of stuff. Rather than hunting down specific cases where this happens, I'd just allow calling `trimmed_def_paths` in this mode. Fixes: rust-lang#144457 r? `@RalfJung`
change_tracker: fix a typo there is no `llvm.lld` option r? `@Kobzol`
…rrowLii resolve: Do not create `NameResolutions` on access unless necessary `fn resolution` now just performs the access, and `fn resolution_or_default` will insert a default entry if the entry is missing.
…iaskrgr Rollup of 10 pull requests Successful merges: - rust-lang#144331 (Disable non_exhaustive_omitted_patterns within matches! macro) - rust-lang#144376 (Suggest unwrapping when private method name is available in inner type) - rust-lang#144421 (Call `is_parsed_attribute` rather than keeping track of a list of parsed attributes manually) - rust-lang#144424 (Allow setting `release-blog-post` label with rustbot) - rust-lang#144427 (rename ext_tool_checks to extra_checks and use mod.rs) - rust-lang#144435 (rustc-dev-guide subtree update) - rust-lang#144448 (Limit defaultness query to impl of trait) - rust-lang#144462 (Allow pretty printing paths with `-Zself-profile-events=args`) - rust-lang#144463 (change_tracker: fix a typo) - rust-lang#144468 (resolve: Do not create `NameResolutions` on access unless necessary) r? `@ghost` `@rustbot` modify labels: rollup
…=lcnr Skip walking into param-env component if it has no placeholder/re-var Although it only provides a minor perf improvement, it seems like it could matter in more pathological cases.
…WaffleLapkin Let `codegen_transmute_operand` just handle everything When combined with rust-lang#143720, this means `rvalue_creates_operand` can just return `true` for *every* `Rvalue`. (A future PR could consider removing it, though just letting it optimize out is fine for now.) It's nicer anyway, IMHO, because it avoids needing the layout checks to be consistent in the two places, and thus is an overall reduction in code. Plus it's a more helpful building block when used in other places this way. (TBH, it probably would have been better to have it this way the whole time, but I clearly didn't understand `rvalue_creates_operand` when I originally wrote rust-lang#109843.)
If `HOME` is empty, use the fallback instead This is a minor change in the `home_dir` api. An empty path is never (or should never be) valid so if the `HOME` environment variable is empty then let's use the fallback instead. r? libs-api
…r-errors add codegen test for variadics This is a part of rust-lang#144066 that can land without FCP.
…-multiple-abis, r=RalfJung test using multiple c-variadic ABIs in the same program tracking issue: rust-lang#100189 Check that multiple c-variadic calling conventions can be used in the same program. Clang and gcc reject defining functions with a non-default calling convention and a variable argument list, so C programs that use multiple c-variadic calling conventions are unlikely to come up. Here we validate that our codegen backends do in fact generate correct code. (CI will not run this test because it runs on aarch64, I would like to at least test that this runs on windows) try-job: `x86_64-gnu` try-job: `x86_64-msvc-*` try-job: `x86_64-apple-2`
…li-obk disable cfg.has_reliable_f128 on amdgcn I was experimenting with compiling a few kernels for amd while working on std::offload. It seems like the logic in rust-lang/compiler-builtins#737 got removed, so I re-introduce it here. Probably should have a test to avoid another regression and make sure that f128 doesn't show up as target feature for amdgcn. It looks like currently we neither check that for nvptx, nor amdgpu. Maybe I could add two revisions to https://github.com/rust-lang/rust/blob/master/tests/ui/float/target-has-reliable-nightly-float.rs? r? ````@Flakebi```` fixes: rust-lang#144381
…ly-abort, r=oli-obk Stop compilation early if macro expansion failed Fixes rust-lang#116180. So there isn't really a type that is central for macro expansion and some errors are actually emitted (because the resolution happens after the expansion I suppose) after the expansion pass (like "not found macro"). Sometimes, errors are only emitted on the second "try" (to improve error output). So I couldn't reach a similar solution than what was done in rust-lang#133937 and suggested by ````@estebank```` in rust-lang#116180 (comment). But maybe I missed something? So in the end, I realized that there is method called every time (except one, described below) a macro error is actually emitted: `ExtCtxt::trace_macros_diag`. Considering I updated what it did, I renamed it into `macro_error_and_trace_macros_diag` to better reflect it. There is only one call of `trace_macros_diag` which isn't reporting an error but just used for `macro_trace` feature, so I kept it as is. r? ````@oli-obk````
library/windows_targets: Fix macro expansion error in 'link' macro
A recent change altered the definition of the link! macro when the windows_raw_dylib feature is enabled, changing its syntax from pub macro {..} to pub macro($tt:tt) {..} in rust-lang#143592
This change introduced a build failure with the error: "macros that expand to items must be delimited with braces or followed by a semicolon".
We add a semicolon to the line causing the issue as we also modify the non windows_raw_dylib link to make use of the link_dylib macro
…musl, r=Amanieu Enable outline-atomics for aarch64-unknown-linux-musl They were disabled in bd287fa and haven't been causing problems for a while anymore, see rust-lang#89626 for details. The entire testsuite still passes on `aarch64-unknown-linux-musl` with this feature enabled.
…target, r=Noratrieb tests: aarch64-outline-atomics: Remove hardcoded target Since this test is limited to aarch64 and linux hosts, the `--target` flag is entirely unnecessary and only breaks this on musl hosts. Let the compiler use the default target instead.
…ts, r=Kobzol Fix `./x check bootstrap` (again) Redoes rust-lang#134883 and reverts 40c2ca9 from rust-lang#142416. Unfortunately I missed this during review. - Commit 1: Reverts 40c2ca9 and re-applies rust-lang#134883. - Commit 2: Check `./x check bootstrap` in `pr-check-1` to catch "obvious" problems like this. r? Kobzol
… r=jieyouxu canonicalize build root in `tests/run-make/linker-warning` r? jieyouxu This is similar to rust-lang#139823 -- the test fails for me because my build dir is a symlink.
Only run bootstrap tests in `x test` on CI Discussed at https://rust-lang.zulipchat.com/#narrow/channel/122652-new-members/topic/Linux.20Distribution/with/530839642. The bootstrap tests can be sensitive of the environment where they are executed. And now that they are executed very early in the test pipeline, it can be annoying for people who just try to do `x test` when it fails on bootstrap tests. We could move the bootstrap tests back to the end of the `x test` pipeline, but then it would just fail later. I'd prefer to only run them on CI by default. Fixes: rust-lang#143973
…r=bjorn3 clif: Don't set the `compiler-builtins-no-f16-f128` feature Since rust-lang/rust be35d37 ("Use the compiler to determine whether or not to enable f16 and f128"), `compiler-builtins` relies on `rustc` to report whether or not `f16` and `f128` are supported, which is reported by the backend. This means that there should no longer be any need to unconditionally disable the types for clif in Bootstrap. Backend config: https://github.com/rust-lang/rust/blob/a955f1cd09a027363729ceed919952d09f76f28e/compiler/rustc_codegen_cranelift/src/lib.rs#L224-L233
…thar Revert "coverage: Enlarge empty spans during MIR instrumentation, not codegen" Surprisingly, rust-lang#144298 alone (extracted from rust-lang#140847) was enough to re-trigger the failures observed in rust-lang#141577 (comment). --- This reverts commit f877aa7. --- r? ghost
Rollup of 13 pull requests Successful merges: - rust-lang#141840 (If `HOME` is empty, use the fallback instead) - rust-lang#144359 (add codegen test for variadics) - rust-lang#144379 (test using multiple c-variadic ABIs in the same program) - rust-lang#144383 (disable cfg.has_reliable_f128 on amdgcn) - rust-lang#144409 (Stop compilation early if macro expansion failed) - rust-lang#144422 (library/windows_targets: Fix macro expansion error in 'link' macro) - rust-lang#144429 (Enable outline-atomics for aarch64-unknown-linux-musl) - rust-lang#144430 (tests: aarch64-outline-atomics: Remove hardcoded target) - rust-lang#144445 (Fix `./x check bootstrap` (again)) - rust-lang#144453 (canonicalize build root in `tests/run-make/linker-warning`) - rust-lang#144464 (Only run bootstrap tests in `x test` on CI) - rust-lang#144470 (clif: Don't set the `compiler-builtins-no-f16-f128` feature) - rust-lang#144480 (Revert "coverage: Enlarge empty spans during MIR instrumentation, not codegen") r? `@ghost` `@rustbot` modify labels: rollup
Shourya742
force-pushed
the
2025-07-24-have-explicit-download-methods
branch
from
d2df958 to
19dc195
Compare
…nd during config parsing directly invoke cdownload methods
…ation in config parsing
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.