- 23 3月, 2021 1 次提交
-
-
由 Camille GILLOT 提交于
-
- 22 3月, 2021 6 次提交
-
-
由 The8472 提交于
-
由 Camelid 提交于
-
由 Nikita Popov 提交于
This saves us both the Freeze/Unpin queries, and avoids placing noalias attributes, which have a compile-time impact on LLVM even in optnone builds (due to always_inline functions).
-
由 The8472 提交于
-
由 Nikita Popov 提交于
We don't have any known noalias bugs for LLVM 12 ... yet.
-
由 Nikita Popov 提交于
Such structures may contain self-references, in which case the same location may be accessible through a pointer that is not based-on the noalias pointer. This is still grey area as far as language semantics are concerned, but checking for !Unpin as an indicator for self-referential sturctures seems like a good approach for the meantime.
-
- 21 3月, 2021 2 次提交
-
-
由 Aaron Hill 提交于
Currently, the print helper macro performs 'recollection' by doing `token_stream.into_iter().collect()`. However, this will not affect nonterminals that occur nested inside delimited groups, since the wrapping delimited group will be left untouched. This commit adds 'deep recollection', which recursively recollects every delimited group in the token stream. As with normal recollection, we only print out something if deep recollection results in a different stringified token stream. This is useful for catching bugs where we update the AST of a nonterminal (which affects pretty-printing), but do not update the attatched `TokenStream`
-
由 lcnr 提交于
-
- 20 3月, 2021 2 次提交
-
-
由 Caio 提交于
-
由 Aaron Hill 提交于
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.
-
- 19 3月, 2021 6 次提交
-
-
由 Oli Scherer 提交于
-
由 Oli Scherer 提交于
-
由 Jennifer Wills 提交于
make changes to liveness to use closure_min_captures use different span borrow check uses new structures rename to CapturedPlace stop using upvar_capture in regionck remove the bridge cleanup from rebase + remove the upvar_capture reference from mutability_errors.rs remove line from livenes test make our unused var checking more consistent update tests adding more warnings to the tests move is_ancestor_or_same_capture to rustc_middle/ty update names to reflect the closures add FIXME check that all captures are immutable borrows before returning add surrounding if statement like the original move var out of the loop and rename Co-authored-by: NLogan Mosier <logmosier@gmail.com> Co-authored-by: NRoxane Fruytier <roxane.fruytier@hotmail.com>
-
由 Santiago Pastorino 提交于
-
由 SparrowLii 提交于
-
由 Aaron Hill 提交于
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.
-
- 18 3月, 2021 2 次提交
-
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
-
- 17 3月, 2021 10 次提交
-
-
由 Yuki Okushi 提交于
-
由 Ivan Tham 提交于
async-pub check created a regression for default
-
由 Ivan Tham 提交于
-
由 Ivan Tham 提交于
Redirects `const? async? unsafe? pub` to `pub const? async? unsafe?`. Fix #76437
-
由 Yuki Okushi 提交于
-
由 Yuki Okushi 提交于
-
由 Yuki Okushi 提交于
-
由 Joshua Nelson 提交于
Previously, there was no way to add a custom tool prefix, even if the tool itself had registered a lint: ``` #![feature(register_tool)] #![register_tool(xyz)] #![warn(xyz::my_lint)] ``` ``` $ rustc unknown-lint.rs --crate-type lib error[E0710]: an unknown tool name found in scoped lint: `xyz::my_lint` --> unknown-lint.rs:3:9 | 3 | #![warn(xyz::my_lint)] | ^^^ ``` This allows opting-in to lints from other tools using `register_tool`.
-
由 Simonas Kazlauskas 提交于
When cg_llvm encounters the `-Ctarget-cpu=native` it computes an explciit set of features that applies to the target in order to correctly compile code for the host CPU (because e.g. `skylake` alone is not sufficient to tell if some of the instructions are available or not). However there were a couple of issues with how we did this. Firstly, the order in which features were overriden wasn't quite right – conceptually you'd expect `-Ctarget-cpu=native` option to override the features that are implicitly set by the target definition. However due to how other `-Ctarget-cpu` values are handled we must adopt the following order of priority: * Features from -Ctarget-cpu=*; are overriden by * Features implied by --target; are overriden by * Features from -Ctarget-feature; are overriden by * function specific features. Another problem was in that the function level `target-features` attribute would overwrite the entire set of the globally enabled features, rather than just the features the `#[target_feature(enable/disable)]` specified. With something like `-Ctarget-cpu=native` we'd end up in a situation wherein a function without `#[target_feature(enable)]` annotation would have a broader set of features compared to a function with one such attribute. This turned out to be a cause of heavy run-time regressions in some code using these function-level attributes in conjunction with `-Ctarget-cpu=native`, for example. With this PR rustc is more careful about specifying the entire set of features for functions that use `#[target_feature(enable/disable)]` or `#[instruction_set]` attributes. Sadly testing the original reproducer for this behaviour is quite impossible – we cannot rely on `-Ctarget-cpu=native` to be anything in particular on developer or CI machines.
-
由 Joshua Nelson 提交于
Right now, rustdoc users have an unpleasant situation: they can either use the new tool lint names (`rustdoc::non_autolinks`) or they can use the old names (`non_autolinks`). If they use the tool lints, they get a hard error on stable compilers, because rustc rejects all tool names it doesn't recognize. If they use the old name, they get a warning to rename the lint to the new name. The only way to compile without warnings is to add `#[allow(renamed_removed_lints)]`, which defeats the whole point of the change: we *want* people to switch to the new name. To avoid people silencing the lint and never migrating to the tool lint, this avoids warning about the old name, while still allowing you to use the new name. Once the new `rustdoc` tool name makes it to the stable channel, we can change these lints to warn again. This adds the new lint functions `register_alias` and `register_ignored` - I didn't see an existing way to do this.
-
- 16 3月, 2021 11 次提交
-
-
由 Vadim Petrochenkov 提交于
-
由 Tomasz Miąsko 提交于
-
由 Tomasz Miąsko 提交于
83054 introduced validation of scalar range attributes, but panicking code that uses the attribute remained reachable. Use `delay_span_bug` instead to avoid the ICE.
-
由 Tomasz Miąsko 提交于
-
由 Tomasz Miąsko 提交于
-
由 Aaron Hill 提交于
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.
-
由 Vadim Petrochenkov 提交于
-
由 Oli Scherer 提交于
-
由 Oli Scherer 提交于
-
由 Oli Scherer 提交于
-
由 Oli Scherer 提交于
-