about summary refs log tree commit diff
path: root/src/libsyntax/ext/base.rs
AgeCommit message (Collapse)AuthorLines
2019-10-16move syntax::ext to new crate syntax_expandMazdak Farrokhzad-1188/+0
2019-10-15syntax::parse::sess -> syntax::sessMazdak Farrokhzad-4/+5
2019-10-03proc_macro: Add `Span::mixed_site` exposing `macro_rules` hygieneVadim Petrochenkov-0/+6
2019-09-26Rename `Item.node` to `Item.kind`varkor-1/+1
2019-09-26Rename `Stmt.node` to `Stmt.kind`varkor-2/+2
2019-09-26Rename `Ty.node` to `Ty.kind`varkor-1/+1
2019-09-26Rename `Lit.node` to `Lit.kind`varkor-1/+1
2019-09-26Rename `Pat.node` to `Pat.kind`varkor-2/+2
2019-09-26Rename `Expr.node` to `Expr.kind`varkor-3/+3
For both `ast::Expr` and `hir::Expr`.
2019-09-24Rollup merge of #64698 - Centril:infer-const-with-stash, r=estebankMazdak Farrokhzad-4/+0
Recover on `const X = 42;` and infer type + Error Stash API Here we: 1. Introduce a notion of the "error stash". This is a map in the `Handler` to which you can `err.stash(...)` away your diagnostics and then steal them in a later "phase" of the compiler (e.g. stash in parser, steal in typeck) to enrich them with more information that isn't available in the previous "phase". I believe I've covered all the bases to make sure these diagnostics are actually emitted eventually even under `#[cfg(FALSE)]` but please check my logic. 2. Recover when parsing `[const | static mut?] $ident = $expr;` which has a missing type. Use the "error stash" to stash away the error and later steal the error in typeck where we emit the error as `MachineApplicable` with the actual inferred type. This builds on https://github.com/rust-lang/rust/pull/62804. cc https://github.com/rust-lang/rfcs/pull/2545 r? @estebank
2019-09-24Stabilize `str::len`, `[T]::len`, `is_empty` and `str::as_bytes` as const fnOliver Scherer-27/+3
2019-09-23cleanup librustc_errors Handler code.Mazdak Farrokhzad-4/+0
2019-09-17Remove unused methods from HandlerMark Rousskov-3/+0
2019-09-15Remove `with_legacy_ctxt`Matthew Jasper-7/+0
2019-09-15Give more `Idents` spansMatthew Jasper-2/+2
2019-09-09Resolve attributes in several placesCaio-0/+140
Arm, Field, FieldPat, GenericParam, Param, StructField and Variant
2019-09-07Aggregation of cosmetic changes made during work on REPL PRs: libsyntaxAlexander Regueiro-1/+1
2019-09-07Rollup merge of #63919 - matthewjasper:remove-gensymmed, r=petrochenkovMazdak Farrokhzad-7/+13
Use hygiene for AST passes AST passes are now able to have resolve consider their expansions as if they were opaque macros defined either in some module in the current crate, or a fake empty module with `#[no_implicit_prelude]`. * Add an ExpnKind for AST passes. * Remove gensyms in AST passes. * Remove gensyms in`#[test]`, `#[bench]` and `#[test_case]`. * Allow opaque macros to define tests. * Move tests for unit tests to their own directory. * Remove `Ident::{gensym, is_gensymed}` - `Ident::gensym_if_underscore` still exists. cc #60869, #61019 r? @petrochenkov
2019-09-05Add `with_{def_site,call_site,legacy}_ctxt,` methods to `Span`Vadim Petrochenkov-7/+7
Use these to create call-site spans for AST passes when needed.
2019-09-05Make use of hygiene in AST passesMatthew Jasper-2/+0
2019-09-05Allow ast passes to create hygienic spansMatthew Jasper-1/+9
2019-09-03use TokenStream rather than &[TokenTree] for built-in macrosAleksey Kladov-15/+12
That way, we don't loose the jointness info
2019-08-29Rollup merge of #63867 - petrochenkov:dhelpers, r=matthewjasperMazdak Farrokhzad-1/+19
resolve: Block expansion of a derive container until all its derives are resolved So, it turns out there's one more reason to block expansion of a `#[derive]` container until all the derives inside it are resolved, beside `Copy` (https://github.com/rust-lang/rust/pull/63248). The set of derive helper attributes registered by derives in the container also has to be known before the derives themselves are expanded, otherwise it may be too late (see https://github.com/rust-lang/rust/pull/63468#issuecomment-524550872 and the `#[stable_hasher]`-related test failures in https://github.com/rust-lang/rust/pull/63468). So, we stop our attempts to unblock the container earlier, as soon as the `Copy` status is known, and just block until all its derives are resolved. After all the derives are resolved we immediately go and process their helper attributes in the item, without delaying it until expansion of the individual derives. Unblocks https://github.com/rust-lang/rust/pull/63468 r? @matthewjasper (as a reviewer of https://github.com/rust-lang/rust/pull/63248) cc @c410-f3r
2019-08-27Respect attributes on proc macro definitionsVadim Petrochenkov-2/+65
2019-08-27resolve: Block expansion of a derive container until all its derives are ↵Vadim Petrochenkov-1/+19
resolved Also mark derive helpers as known as a part of the derive container's expansion instead of expansion of the derives themselves which may happen too late.
2019-08-23Remove default macro transparenciesVadim Petrochenkov-20/+0
All transparancies are passed explicitly now. Also remove `#[rustc_macro_transparency]` annotations from built-in macros, they are no longer used. `#[rustc_macro_transparency]` only makes sense for declarative macros now.
2019-08-23Audit uses of `apply_mark` in built-in macrosVadim Petrochenkov-7/+23
Replace them with equivalents of `Span::{def_site,call_site}` from proc macro API. The new API is much less error prone and doesn't rely on macros having default transparency.
2019-08-21resolve/expand: Rename some things for clarity and add commentsVadim Petrochenkov-2/+3
2019-08-21expand: Do not do questionable span adjustment before eagerly expanding an ↵Vadim Petrochenkov-4/+1
expression Maybe it made sense when it was introduced, but now it's doing something incorrect.
2019-08-17resolve/expand: Rename some things for clarityVadim Petrochenkov-4/+4
2019-08-15hygiene: `ExpnInfo` -> `ExpnData`Vadim Petrochenkov-9/+9
For naming consistency with everything else in this area
2019-08-15hygiene: Merge `ExpnInfo` and `InternalExpnData`Vadim Petrochenkov-2/+3
2019-08-15hygiene: Remove `Option`s from functions returning `ExpnInfo`Vadim Petrochenkov-14/+7
The expansion info is not optional and should always exist
2019-08-15`Ident::with_empty_ctxt` -> `Ident::with_dummy_span`Vadim Petrochenkov-1/+1
`Ident` has had a full span rather than just a `SyntaxContext` for a long time now.
2019-08-15syntax_pos: `NO_EXPANSION`/`SyntaxContext::empty()` -> `SyntaxContext::root()`Vadim Petrochenkov-1/+1
For consistency with `ExpnId::root`. Also introduce a helper `Span::with_root_ctxt` for creating spans with `SyntaxContext::root()` context
2019-08-15Remove `Spanned` from `mk_name_value_item_str` and `expr_to_spanned_string`Vadim Petrochenkov-4/+4
2019-08-14Rollup merge of #63537 - petrochenkov:novisit, r=alexcrichtonMazdak Farrokhzad-4/+10
expand: Unimplement `MutVisitor` on `MacroExpander` Each call to `fully_expand_fragment` is something unique, interesting, and requiring attention. It represents a "root" of expansion and its use means that something unusual is happening, like eager expansion or expansion performed outside of the primary expansion pass. So, it shouldn't hide under a generic visitor call. Also, from all the implemented visitor methods only two were actually used. cc https://github.com/rust-lang/rust/pull/63468#discussion_r313504119
2019-08-14expand: Unimplement `MutVisitor` on `MacroExpander`Vadim Petrochenkov-4/+10
Each call to `fully_expand_fragment` is something unique, interesting, and requiring attention. It represents a "root" of expansion and its use means that something unusual is happening, like eager expansion or expansion performed outside of the primary expansion pass. So, it shouldn't be hide under a generic visitor call. Also, from all the implemented visitor methods only two were actually used.
2019-08-13syntax: Remove `DummyResult::expn_only`Vadim Petrochenkov-33/+6
2019-08-10resolve: Remove remaining special cases from built-in macrosVadim Petrochenkov-2/+2
2019-08-05Auto merge of #63248 - petrochenkov:nomarker, r=matthewjasperbors-2/+16
Move special treatment of `derive(Copy, PartialEq, Eq)` from expansion infrastructure to elsewhere As described in https://github.com/rust-lang/rust/pull/62086#issuecomment-515195477. Reminder: - `derive(PartialEq, Eq)` makes the type it applied to a "structural match" type, so constants of this type can be used in patterns (and const generics in the future). - `derive(Copy)` notifies other derives that the type it applied to implements `Copy`, so `derive(Clone)` can generate optimized code and other derives can generate code working with `packed` types and types with `rustc_layout_scalar_valid_range` attributes. First, the special behavior is now enabled after properly resolving the derives, rather than after textually comparing them with `"Copy"`, `"PartialEq"` and `"Eq"` in `fn add_derived_markers`. The markers are no longer kept as attributes in AST since derives cannot modify items and previously did it through hacks in the expansion infra. Instead, the markers are now kept in a "global context" available from all the necessary places, namely - resolver. For `derive(PartialEq, Eq)` the markers are created by the derive macros themselves and then consumed during HIR lowering to add the `#[structural_match]` attribute in HIR. This is still a hack, but now it's a hack local to two specific macros rather than affecting the whole expansion infra. Ideally we should find the way to put `#[structural_match]` on the impls rather than on the original item, and then consume it in `rustc_mir`, then no hacks in expansion and lowering will be required. (I'll make an issue about this for someone else to solve, after this PR lands.) The marker for `derive(Copy)` cannot be emitted by the `Copy` macro itself because we need to know it *before* the `Copy` macro is expanded for expanding other macros. So we have to do it in resolve and block expansion of any derives in a `derive(...)` container until we know for sure whether this container has `Copy` in it or not. Nasty stuff. r? @eddyb or @matthewjasper
2019-08-03Move special treatment of `derive(Copy, PartialEq, Eq)` from expansion ↵Vadim Petrochenkov-2/+16
infrastructure to elsewhere
2019-07-30Point at type ascription before macro invocation on expansion parse errorEsteban Küber-0/+2
2019-07-27syntax_ext: `proc_macro_decls` -> `proc_macro_harness`Vadim Petrochenkov-1/+1
Few other minor renamings for consistency. Remove one unused dependency from `rustc_passes`. Fix libsyntax tests. Fix rebase.
2019-07-27Break dependencies between `syntax_ext` and some other cratesVadim Petrochenkov-1/+1
Move `source_uitil` macros into `syntax_ext` Cleanup dependencies of `rustc_driver`
2019-07-26Introduce built-in macros through libcoreVadim Petrochenkov-1/+5
2019-07-23Make path::resolve a method on ExtCtxtJonas Schievink-1/+26
2019-07-19Adjust other names after the `Mark` renamingVadim Petrochenkov-7/+7
2019-07-19libsyntax: Remove `Mark` into `ExpnId`Vadim Petrochenkov-7/+7
2019-07-11hygiene: Introduce a helper method for creating new expansionsVadim Petrochenkov-0/+2
Creating a fresh expansion and immediately generating a span from it is the most common scenario. Also avoid allocating `allow_internal_unstable` lists for derive markers repeatedly. And rename `ExpnInfo::with_unstable` to `ExpnInfo::allow_unstable`, seems to be a better fitting name.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-20 20:22:49 +0000