-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 5 pull requests #126726
Rollup of 5 pull requests #126726
Conversation
…cause of the bound that binds the parameter's type
People were tripped up by the "precludes", interpreting it that this function must not ever be used in cryptographic contexts rather than the std lib merely making zero promises about it being fit-for-purpose. What remains unchanged is that if someone does try to use it *despite the warnings* then it is on them to pin their compiler versions and verify the assembly of every single binary build they do.
It's clearer this way, because the `Interpolated` cases in `can_begin_const_arg` and `is_pat_range_end_start` are more permissive than the `Interpolated` cases in `can_begin_literal_maybe_minus`.
We currently use `can_begin_literal_maybe_minus` in a couple of places where only string literals are allowed. This commit introduces a more specific function, which makes things clearer. It doesn't change behaviour because the two functions affected (`is_unsafe_foreign_mod` and `check_keyword_case`) are always followed by a call to `parse_abi`, which checks again for a string literal.
Actually taint InferCtxt when a fulfillment error is emitted And avoid checking the global error counter fixes rust-lang#122044 fixes rust-lang#123255 fixes rust-lang#123276 fixes rust-lang#125799
Fix `feature = "nightly"` in the new trait solver r? lcnr
…orn3,Urgau Clarify that anonymous consts still do introduce a new scope See rust-lang#120363 (comment) This error message is misleading: it's trying to say that `const _ : () = ...` is a workaround for the lint, but by saying that anonymous constants are treated as being in the parent scope, it makes them appear useless for scope-hiding. They *are* useful for scope-hiding, they are simply treated as part of the parent scope when it comes to this lint.
…scottmcm reword the hint::blackbox non-guarantees People were tripped up by the "precludes", interpreting it that this function must not ever be used in cryptographic contexts rather than the std lib merely making zero promises about it being fit-for-purpose. What remains unchanged is that if someone does try to use it *despite the warnings* then it is on them to pin their compiler versions and verify the assembly of every single binary build they do.
…eral_maybe_minus, r=compiler-errors Minimize `can_begin_literal_maybe_minus` usage `can_begin_literal_maybe_minus` is used in a few confusing ways. This PR makes them clearer. r? ``@spastorino``
@bors r+ rollup=never p=5 |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: 54fcd5bb92 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (1208edd): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results (primary -2.0%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 690.827s -> 690.663s (-0.02%) |
Successful merges:
feature = "nightly"
in the new trait solver #126649 (Fixfeature = "nightly"
in the new trait solver)can_begin_literal_maybe_minus
usage #126708 (Minimizecan_begin_literal_maybe_minus
usage)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup