-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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 6 pull requests #128230
Rollup of 6 pull requests #128230
Commits on Jul 25, 2024
-
Configuration menu - View commit details
-
Copy full SHA for 2a73553 - Browse repository at this point
Copy the full SHA 2a73553View commit details -
Invert early exit conditions in
collect_tokens_trailing_token
.This has been bugging me for a while. I find complex "if any of these are true" conditions easier to think about than complex "if all of these are true" conditions, because you can stop as soon as one is true.
Configuration menu - View commit details
-
Copy full SHA for caee195 - Browse repository at this point
Copy the full SHA caee195View commit details -
Inline and remove
AttrWrapper::is_complete
.It has a single call site. This change makes the two `needs_collect` conditions more similar to each other, and therefore easier to understand.
Configuration menu - View commit details
-
Copy full SHA for 4288edb - Browse repository at this point
Copy the full SHA 4288edbView commit details -
Move
is_complete
to the module that uses it.And make it non-`pub`.
Configuration menu - View commit details
-
Copy full SHA for 3d363c3 - Browse repository at this point
Copy the full SHA 3d363c3View commit details -
Invert the sense of
is_complete
and rename it asneeds_tokens
.I have always found `is_complete` an unhelpful name. The new name (and inverted sense) fits in better with the conditions at its call sites.
Configuration menu - View commit details
-
Copy full SHA for e631b1e - Browse repository at this point
Copy the full SHA e631b1eView commit details
Commits on Jul 26, 2024
-
Don't include inner attribute ranges in
CaptureState
.The current code is this: ``` self.capture_state.replace_ranges.push((start_pos..end_pos, Some(target))); self.capture_state.replace_ranges.extend(inner_attr_replace_ranges); ``` What's not obvious is that every range in `inner_attr_replace_ranges` must be a strict sub-range of `start_pos..end_pos`. Which means, in `LazyAttrTokenStreamImpl::to_attr_token_stream`, they will be done first, and then the `start_pos..end_pos` replacement will just overwrite them. So they aren't needed.
Configuration menu - View commit details
-
Copy full SHA for a560810 - Browse repository at this point
Copy the full SHA a560810View commit details -
Imagine you have replace ranges (2..20,X) and (5..15,Y), and these tokens: ``` a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x ``` If we replace (5..15,Y) first, then (2..20,X) we get this sequence ``` a,b,c,d,e,Y,_,_,_,_,_,_,_,_,_,p,q,r,s,t,u,v,w,x a,b,X,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,_,u,v,w,x ``` which is what we want. If we do it in the other order, we get this: ``` a,b,X,_,_,_,_,_,_,_,_,_,_,_,_,p,q,r,s,t,u,v,w,x a,b,X,_,_,Y,_,_,_,_,_,_,_,_,_,_,_,_,_,_,u,v,w,x ``` which is wrong. So it's true that we need the `.rev()` but the comment is wrong about why.
Configuration menu - View commit details
-
Copy full SHA for 6e87858 - Browse repository at this point
Copy the full SHA 6e87858View commit details -
A fully imperative style is easier to read than a half-iterator, half-imperative style. Also, rename `inner_attr` as `attr` because it might be an outer attribute.
Configuration menu - View commit details
-
Copy full SHA for 6ea2da5 - Browse repository at this point
Copy the full SHA 6ea2da5View commit details -
Configuration menu - View commit details
-
Copy full SHA for 55d37ae - Browse repository at this point
Copy the full SHA 55d37aeView commit details -
Configuration menu - View commit details
-
Copy full SHA for 984039f - Browse repository at this point
Copy the full SHA 984039fView commit details -
Configuration menu - View commit details
-
Copy full SHA for 192671f - Browse repository at this point
Copy the full SHA 192671fView commit details -
Configuration menu - View commit details
-
Copy full SHA for 33b98bf - Browse repository at this point
Copy the full SHA 33b98bfView commit details -
Configuration menu - View commit details
-
Copy full SHA for 114e0dc - Browse repository at this point
Copy the full SHA 114e0dcView commit details -
Configuration menu - View commit details
-
Copy full SHA for fd9d0bf - Browse repository at this point
Copy the full SHA fd9d0bfView commit details -
Rollup merge of rust-lang#121676 - Bryanskiy:polarity, r=petrochenkov
Support ?Trait bounds in supertraits and dyn Trait under a feature gate This patch allows `maybe` polarity bounds under a feature gate. The only language change here is that corresponding hard errors are replaced by feature gates. Example: ```rust #![feature(allow_maybe_polarity)] ... trait Trait1 : ?Trait { ... } // ok fn foo(_: Box<(dyn Trait2 ?Trait)>) {} // ok fn bar<T: ?Sized ?Trait>(_: &T) {} // ok ``` Maybe bounds still don't do anything (except for `Sized` trait), however this patch will allow us to [experiment with default auto traits](rust-lang#120706 (comment)). This is a part of the [MCP: Low level components for async drop](rust-lang/compiler-team#727)
Configuration menu - View commit details
-
Copy full SHA for a9af0a3 - Browse repository at this point
Copy the full SHA a9af0a3View commit details -
Rollup merge of rust-lang#124339 - oli-obk:supports_feature, r=wesley…
…wiser allow overwriting the output of `rustc --version` Our wonderful bisection folk [have to work around](rust-lang#123276 (comment)) crates that do incomplete nightly/feature detection, as otherwise the bisection just points to where the feature detection breaks, and not to the actual breakage they are looking for. This is also annoying behaviour to nightly users who did not opt-in to those nightly features. Most nightly users want to be in control of the nightly breakage they get, by * choosing when to update rustc * choosing when to update dependencies * choosing which nightly features they are willing to take the breakage for The reason this breakage occurs is that the build script of some crates run `rustc --version`, and if the version looks like nightly or dev, it will enable nightly features. These nightly features may break in random ways whenever we change something in nightly, so every release of such a crate will only work with a small range of nightly releases. This causes bisection to fail whenever it tries an unsupported nightly, even though that crate is not related to the bisection at all, but is just an unrelated dependency. This PR (and the policy I want to establish with this FCP) is only for situations like the `version_check`'s `supports_feature` function. It is explicitly not for `autocfg` or similar feature-detection-by-building-rust-code, irrespective of my opinions on it and the similarity of nightly breakage that can occur with such schemes. These cause much less breakage, but should the breakage become an issue, they should get covered by this policy, too. This PR allows changing the version and release strings reported by `rustc --version` via the `RUSTC_OVERRIDE_VERSION_STRING` env var. The bisection issue is then fixed by rust-lang/cargo-bisect-rustc#335. I mainly want to establish a compiler team policy: > We do not consider feature detection on nightly (on stable via compiler version numbering is fine) a valid use case that we need to support, and if it causes problems, we are at liberty to do what we deem best - either actively working to prevent it or to actively ignore it. We may try to work with responsive and cooperative authors, but are not obligated to. Should they subvert the workarounds that nightly users or cargo-bisect-rustc can use, we should be able to land rustc PRs that target the specific crates that cause issues for us and outright replace their build script's logic to disable nightly detection. I am not including links to crates, PRs or issues here, as I don't actually care about the specific use cases and don't want to make it trivial to go there and leave comments. This discussion is going to be interesting enough on its own, without branching out.
Configuration menu - View commit details
-
Copy full SHA for da74d40 - Browse repository at this point
Copy the full SHA da74d40View commit details -
Rollup merge of rust-lang#128223 - nnethercote:refactor-collect_token…
…s, r=petrochenkov Refactor complex conditions in `collect_tokens_trailing_token` More readability improvements for this complicated function. r? `@petrochenkov`
Configuration menu - View commit details
-
Copy full SHA for 64eff24 - Browse repository at this point
Copy the full SHA 64eff24View commit details -
Rollup merge of rust-lang#128224 - nnethercote:fewer-replace_ranges, …
…r=petrochenkov Remove unnecessary range replacements This PR removes an unnecessary range replacement in `collect_tokens_trailing_token`, and does a couple of other small cleanups. r? `@petrochenkov`
Configuration menu - View commit details
-
Copy full SHA for e2eb043 - Browse repository at this point
Copy the full SHA e2eb043View commit details -
Rollup merge of rust-lang#128226 - oli-obk:option_vs_empty_slice, r=p…
…etrochenkov Remove redundant option that was just encoding that a slice was empty There is already a sanity check ensuring we don't put empty attribute lists into the HIR: https://github.com/rust-lang/rust/blob/6ef11b81c2c02c3c4b7556d1991a98572fe9af87/compiler/rustc_ast_lowering/src/lib.rs#L661-L667
Configuration menu - View commit details
-
Copy full SHA for 202c765 - Browse repository at this point
Copy the full SHA 202c765View commit details -
Rollup merge of rust-lang#128227 - Kobzol:ci-unrolled-perf-build-matr…
…ix, r=tgross35 CI: do not respect custom try jobs for unrolled perf builds Before this PR, if a pull request merged in a rollup had some `try-job` annotations, the unrolled perf builds were running the custom try jobs instead of the default job, which was wrong. Found out [here](https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/try-perf.20jobs.20respect.20try-job.20annotations).
Configuration menu - View commit details
-
Copy full SHA for 53f0849 - Browse repository at this point
Copy the full SHA 53f0849View commit details