summary refs log tree commit diff
path: root/src/libsyntax/ext
AgeCommit message (Collapse)AuthorLines
2017-11-14avoid the pprust infrastructure in macro expansionAriel Ben-Yehuda-3/+24
This changes macro expansion to format the path of a macro directly instead of usng the pprust infrastructure. The pprust infrastructure tries to perform line-breaking in a slow fashion, which is undesired when formatting the path of a macro. This should to speed up expansion by a fair amount (I saw 20% on a profiler on `rustc_mir`, and 50% of the time marked as "expansion" in the profiler/time-passes is actually spent loading dependencies).
2017-10-17Lifting Generics from MethodSig to TraitItem and ImplItem since we want to ↵Sunjay Varma-2/+3
support generics in each variant of TraitItem and ImplItem
2017-10-03Rename FileMap::path and change to an OptionPhilip Craig-3/+3
2017-09-30Don't use remapped path when loading modules and include filesPhilip Craig-5/+3
2017-09-28Auto merge of #44528 - tmnilsson:attr_proc_macro_cfg_process, r=jseyfriedbors-14/+25
Apply attr proc macros before cfg processing Fixes #39336. r? @jseyfried
2017-09-27Apply attr proc macros before cfg processingTomas Nilsson-14/+25
Now items are not fully configured until right before expanding derives.
2017-09-27Auto merge of #44709 - Badel2:inclusive-range-dotdoteq, r=petrochenkovbors-0/+2
Initial support for `..=` syntax #28237 This PR adds `..=` as a synonym for `...` in patterns and expressions. Since `...` in expressions was never stable, we now issue a warning. cc @durka r? @aturon
2017-09-25Fix bug in collecting trait and impl items with derives.Jeffrey Seyfried-7/+1
2017-09-22Add support for `..=` syntaxAlex Burka-0/+2
Add ..= to the parser Add ..= to libproc_macro Add ..= to ICH Highlight ..= in rustdoc Update impl Debug for RangeInclusive to ..= Replace `...` to `..=` in range docs Make the dotdoteq warning point to the ... Add warning for ... in expressions Updated more tests to the ..= syntax Updated even more tests to the ..= syntax Updated the inclusive_range entry in unstable book
2017-09-21suggest an outer attribute when `#![derive(...)]` (predictably) failsZack M. Davis-5/+17
2017-09-21only set non-ADT derive error once per attribute, not per traitZack M. Davis-0/+18
A slight eccentricity of this change is that now non-ADT-derive errors prevent derive-macro-not-found errors from surfacing (see changes to the gating-of-derive compile-fail tests). Resolves #43927.
2017-09-17Rollup merge of #44088 - bjorn3:better_trace_macros, r=jseyfriedTim Neumann-3/+20
Fix "new trace_macros doesn't work if there's an error during expansion" Fixes #43493
2017-09-02Better trace-macro and less span_err_fatalbjorn3-2/+5
2017-09-02Dont abort on first macro errorbjorn3-1/+3
2017-09-01Implement RFC 1925Matt Ickstadt-1/+2
2017-08-30Make fields of `Span` privateVadim Petrochenkov-26/+26
2017-08-27Fix errorbjorn3-1/+0
2017-08-25Fix #43493 (new trace_macros doesn't work if there's an error during expansion)bjorn3-0/+13
2017-08-21Auto merge of #43540 - petrochenkov:pathrelax, r=nikomatsakisbors-3/+1
syntax: Relax path grammar TLDR: Accept the disambiguator `::` in "type" paths (`Type::<Args>`), accept the disambiguator `::` before parenthesized generic arguments (`Fn::(Args)`). The "turbofish" disambiguator `::<>` in expression paths is a necessary evil required for path parsing to be both simple and to give reasonable results. Since paths in expressions usually refer to values (but not necessarily, e.g. `Struct::<u8> { field: 0 }` is disambiguated, but refers to a type), people often consider `::<>` to be inherent to *values*, and not *expressions* and want to write disambiguated paths for values even in contexts where disambiguation is not strictly necessary, for example when a path is passed to a macro `m!(Vec::<i32>::new)`. The problem is that currently, if the disambiguator is not *required*, then it's *prohibited*. This results in confusion - see https://github.com/rust-lang/rust/issues/41740, https://internals.rust-lang.org/t/macro-path-uses-novel-syntax/5561. This PR makes the disambiguator *optional* instead of prohibited in contexts where it's not strictly required, so people can pass paths to macros in whatever form they consider natural (e.g. disambiguated form for value paths). This PR also accepts the disambiguator in paths with parenthesized arguments (`Fn::(Args)`) for consistency and to simplify testing of stuff like https://github.com/rust-lang/rust/pull/41856#issuecomment-301219194. Closes https://github.com/rust-lang/rust/issues/41740 cc @rust-lang/lang r? @nikomatsakis
2017-08-15use field init shorthand EVERYWHEREZack M. Davis-57/+58
Like #43008 (f668999), but _much more aggressive_.
2017-08-13Rollup merge of #43782 - nrc:include, r=GuillaumeGomezGuillaume Gomez-5/+6
Fix include! in doc tests By making the path relative to the current file. Fixes #43153 [breaking-change] - if you use `include!` inside a doc test, you'll need to change the path to be relative to the current file rather than relative to the working directory.
2017-08-12syntax: #[allow_internal_unsafe] bypasses the unsafe_code lint in macros.Eduard-Mihai Burtescu-15/+41
2017-08-11Rollup merge of #43712 - oli-obk:cfg, r=arielb1Guillaume Gomez-10/+10
Reexport all SyntaxExtension variants This was previously done very inconsistently and made matches look weird since some variants had the `SyntaxExtension::` prefix while others didn't.
2017-08-11Issue warnings for unnecessary path disambiguatorsVadim Petrochenkov-3/+1
2017-08-10Auto merge of #43582 - ivanbakel:unused_mut_ref, r=arielb1bors-3/+3
Fixed mutable vars being marked used when they weren't #### NB : bootstrapping is slow on my machine, even with `keep-stage` - fixes for occurances in the current codebase are <s>in the pipeline</s> done. This PR is being put up for review of the fix of the issue. Fixes #43526, Fixes #30280, Fixes #25049 ### Issue Whenever the compiler detected a mutable deref being used mutably, it marked an associated value as being used mutably as well. In the case of derefencing local variables which were mutable references, this incorrectly marked the reference itself being used mutably, instead of its contents - with the consequence of making the following code emit no warnings ``` fn do_thing<T>(mut arg : &mut T) { ... // don't touch arg - just deref it to access the T } ``` ### Fix Make dereferences not be counted as a mutable use, but only when they're on borrows on local variables. #### Why not on things other than local variables? * Whenever you capture a variable in a closure, it gets turned into a hidden reference - when you use it in the closure, it gets dereferenced. If the closure uses the variable mutably, that is actually a mutable use of the thing being dereffed to, so it has to be counted. * If you deref a mutable `Box` to access the contents mutably, you are using the `Box` mutably - so it has to be counted.
2017-08-10Some tidying up around include!Nick Cameron-5/+6
2017-08-10Add a feature gateest31-0/+10
@alexcrichton figured out a way how to do it :)
2017-08-07Reexport all SyntaxExtension variantsOliver Schneider-10/+10
2017-08-01Fixed all unnecessary muts in language coreIsaac van Bakel-3/+3
2017-07-28syntax: Capture a `TokenStream` when parsing itemsAlex Crichton-0/+2
This is then later used by `proc_macro` to generate a new `proc_macro::TokenTree` which preserves span information. Unfortunately this isn't a bullet-proof approach as it doesn't handle the case when there's still other attributes on the item, especially inner attributes. Despite this the intention here is to solve the primary use case for procedural attributes, attached to functions as outer attributes, likely bare. In this situation we should be able to now yield a lossless stream of tokens to preserve span information.
2017-07-28syntax: Add `tokens: Option<TokenStream>` to ItemAlex Crichton-2/+6
This commit adds a new field to the `Item` AST node in libsyntax to optionally contain the original token stream that the item itself was parsed from. This is currently `None` everywhere but is intended for use later with procedural macros.
2017-07-28Auto merge of #43432 - pczarn:macro-parser-description, r=jseyfriedbors-100/+102
Make the macro parser theory description more accurate The macro parser is described as an NFA, not an Earley parser.
2017-07-27Avoid duplicated errors for generic arguments in macro pathsVadim Petrochenkov-1/+1
2017-07-27Give span to angle bracketed generic argumentsVadim Petrochenkov-14/+7
2017-07-27Discern between `Path` and `Path<>` in ASTVadim Petrochenkov-12/+8
2017-07-27Auto merge of #43477 - est31:master, r=alexcrichtonbors-1/+1
Switch to begin_panic again In https://github.com/rust-lang/rust/pull/42938 we made the compiler emit a call to begin_panic_new in order to pass column info to it. Now with stage0 updated (https://github.com/rust-lang/rust/pull/43320), we can safely change begin_panic and start emitting calls for it again.
2017-07-25Switch to begin_panic againest31-1/+1
In https://github.com/rust-lang/rust/pull/42938 we made the compiler emit a call to begin_panic_new in order to pass column info to it. Now with stage0 updated (https://github.com/rust-lang/rust/pull/43320), we can safely change begin_panic and start emitting calls for it again.
2017-07-25Stabilize the `compile_error_macro` featureAlex Crichton-1/+0
Stabilizes: * `compile_error!` as a macro defined by rustc Closes #40872
2017-07-24Make the macro parser theory description more accuratePiotr Czarnecki-100/+102
2017-07-21Review commentsEsteban Küber-4/+5
2017-07-20Use the macro structure spans instead of the invocationEsteban Küber-2/+16
2017-07-15Auto merge of #43224 - jseyfried:fix_macro_idents_regression, r=nrcbors-1/+2
macros: fix regression involving identifiers in `macro_rules!` patterns. Fixes #42019. r? @nrc
2017-07-13Fix regression involving identifiers in `macro_rules!` patterns.Jeffrey Seyfried-1/+2
2017-07-11let #[allow_internal_unstable] cover :visAlex Burka-8/+19
2017-07-11Auto merge of #42913 - kennytm:fix-40569-ident-without-backtrack, r=jseyfriedbors-4/+70
Only match a fragment specifier the if it starts with certain tokens. When trying to match a fragment specifier, we first predict whether the current token can be matched at all. If it cannot be matched, don't bother to push the Earley item to `bb_eis`. This can fix a lot of issues which otherwise requires full backtracking (#42838). In this PR the prediction treatment is not done for `:item`, `:stmt` and `:tt`, but it could be expanded in the future. Fixes #24189. Fixes #26444. Fixes #27832. Fixes #34030. Fixes #35650. Fixes #39964. Fixes the 4th comment in #40569. Fixes the issue blocking #40984.
2017-07-10Store all generic arguments for method calls in ASTVadim Petrochenkov-2/+1
2017-07-07Only match a fragment specifier the if it starts with certain tokens.kennytm-4/+70
Fixes #24189. Fixes #26444. Fixes #27832. Fixes #34030. Fixes #35650. Fixes #39964. Fixes the 4th comment in #40569. Fixes the issue blocking #40984.
2017-07-06Disallow `$($v:vis)*`. Fix #42755.kennytm-0/+1
2017-07-06Auto merge of #42727 - alexcrichton:allocators-new, r=eddybbors-0/+6
rustc: Implement the #[global_allocator] attribute This PR is an implementation of [RFC 1974] which specifies a new method of defining a global allocator for a program. This obsoletes the old `#![allocator]` attribute and also removes support for it. [RFC 1974]: https://github.com/rust-lang/rfcs/pull/1974 The new `#[global_allocator]` attribute solves many issues encountered with the `#![allocator]` attribute such as composition and restrictions on the crate graph itself. The compiler now has much more control over the ABI of the allocator and how it's implemented, allowing much more freedom in terms of how this feature is implemented. cc #27389
2017-07-05rustc: Implement the #[global_allocator] attributeAlex Crichton-0/+6
This PR is an implementation of [RFC 1974] which specifies a new method of defining a global allocator for a program. This obsoletes the old `#![allocator]` attribute and also removes support for it. [RFC 1974]: https://github.com/rust-lang/rfcs/pull/197 The new `#[global_allocator]` attribute solves many issues encountered with the `#![allocator]` attribute such as composition and restrictions on the crate graph itself. The compiler now has much more control over the ABI of the allocator and how it's implemented, allowing much more freedom in terms of how this feature is implemented. cc #27389
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-25 03:49:57 +0000