- 23 8月, 2018 2 次提交
-
-
由 Igor Gutorov 提交于
-
由 Vadim Petrochenkov 提交于
`tool_attributes`, `proc_macro_path_invoc`, partially `proc_macro_gen`
-
- 21 8月, 2018 1 次提交
-
-
由 Vadim Petrochenkov 提交于
-
- 20 8月, 2018 3 次提交
-
-
由 Donato Sciarra 提交于
-
由 Donato Sciarra 提交于
-
由 Donato Sciarra 提交于
-
- 19 8月, 2018 2 次提交
-
-
由 Matthias Krüger 提交于
-
由 Eduard-Mihai Burtescu 提交于
-
- 17 8月, 2018 1 次提交
-
-
由 Vadim Petrochenkov 提交于
-
- 14 8月, 2018 1 次提交
-
-
由 ljedrz 提交于
-
- 07 8月, 2018 3 次提交
-
-
由 Vadim Petrochenkov 提交于
Adjust a few fulldeps and pretty-printing tests Fix rebase
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
-
- 02 8月, 2018 2 次提交
-
-
由 John Renner 提交于
-
由 John Renner 提交于
-
- 01 8月, 2018 3 次提交
-
-
由 Vadim Petrochenkov 提交于
resolve/expansion: Implement tool attributes
-
由 John Renner 提交于
-
由 John Renner 提交于
-
- 31 7月, 2018 1 次提交
-
-
由 John Renner 提交于
-
- 27 7月, 2018 1 次提交
-
-
由 ljedrz 提交于
-
- 24 7月, 2018 1 次提交
-
-
由 mark 提交于
-
- 22 7月, 2018 1 次提交
-
-
由 Esteban Küber 提交于
-
- 19 7月, 2018 1 次提交
-
-
由 Alex Crichton 提交于
This commit fixes an issue where multiple custom attributes could not be fed into a custom derive in some situations with the `use_extern_macros` feature enabled. The problem was that the macro expander didn't consider that it was making progress when we were deducing that attributes should be lumped in with custom derive invocations. The fix applied here was to track in the expander if our attribute is changing (getting stashed away elsewhere and replaced with a new invocation). If it is swapped then it's considered progress, otherwise behavior should remain the same. Closes #52525
-
- 16 7月, 2018 1 次提交
-
-
由 Alex Crichton 提交于
This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros, custom derives, with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature, such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR, once landed, will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252
-
- 15 7月, 2018 1 次提交
-
-
由 Vadim Petrochenkov 提交于
-
- 11 7月, 2018 1 次提交
-
-
由 ljedrz 提交于
-
- 30 6月, 2018 3 次提交
-
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
-
- 27 6月, 2018 2 次提交
-
-
由 Michael Woerister 提交于
-
由 Vadim Petrochenkov 提交于
-
- 24 6月, 2018 6 次提交
-
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
-
- 02 6月, 2018 1 次提交
-
-
由 kennytm 提交于
-
- 26 5月, 2018 1 次提交
-
-
由 Vadim Petrochenkov 提交于
-
- 21 5月, 2018 1 次提交
-
-
由 Zack M. Davis 提交于
Consider this a down payment on #50723. To recap, an `Applicability` enum was recently (#50204) added, to convey to Rustfix and other tools whether we think it's OK for them to blindly apply the suggestion, or whether to prompt a human for guidance (because the suggestion might contain placeholders that we can't infer, or because we think it has a sufficiently high probability of being wrong even though it's— presumably—right often enough to be worth emitting in the first place). When a suggestion is marked as `MaybeIncorrect`, we try to use comments to indicate precisely why (although there are a few places where we just say `// speculative` because the present author's subjective judgement balked at the idea that the suggestion has no false positives). The `run-rustfix` directive is opporunistically set on some relevant UI tests (and a couple tests that were in the `test/ui/suggestions` directory, even if the suggestions didn't originate in librustc or libsyntax). This is less trivial than it sounds, because a surprising number of test files aren't equipped to be tested as fixed even when they contain successfully fixable errors, because, e.g., there are more, not-directly-related errors after fixing. Some test files need an attribute or underscore to avoid unused warnings tripping up the "fixed code is still producing diagnostics" check despite the fixes being correct; this is an interesting contrast-to/inconsistency-with the behavior of UI tests (which secretly pass `-A unused`), a behavior which we probably ought to resolve one way or the other (filed issue #50926). A few suggestion labels are reworded (e.g., to avoid phrasing it as a question, which which is discouraged by the style guidelines listed in `.span_suggestion`'s doc-comment).
-