about summary refs log tree commit diff
path: root/src/librustc_builtin_macros
AgeCommit message (Collapse)AuthorLines
2020-08-30mv compiler to compiler/mark-9640/+0
2020-08-22Use smaller def span for functionsAaron Hill-2/+3
Currently, the def span of a funtion encompasses the entire function signature and body. However, this is usually unnecessarily verbose - when we are pointing at an entire function in a diagnostic, we almost always want to point at the signature. The actual contents of the body tends to be irrelevant to the diagnostic we are emitting, and just takes up additional screen space. This commit changes the `def_span` of all function items (freestanding functions, `impl`-block methods, and `trait`-block methods) to be the span of the signature. For example, the function ```rust pub fn foo<T>(val: T) -> T { val } ``` now has a `def_span` corresponding to `pub fn foo<T>(val: T) -> T` (everything before the opening curly brace). Trait methods without a body have a `def_span` which includes the trailing semicolon. For example: ```rust trait Foo { fn bar(); }``` the function definition `Foo::bar` has a `def_span` of `fn bar();` This makes our diagnostic output much shorter, and emphasizes information that is relevant to whatever diagnostic we are reporting. We continue to use the full span (including the body) in a few of places: * MIR building uses the full span when building source scopes. * 'Outlives suggestions' use the full span to sort the diagnostics being emitted. * The `#[rustc_on_unimplemented(enclosing_scope="in this scope")]` attribute points the entire scope body. * The 'unconditional recursion' lint uses the full span to show additional context for the recursive call. All of these cases work only with local items, so we don't need to add anything extra to crate metadata.
2020-08-17rust_ast::ast => rustc_astUjjwal Sharma-36/+36
2020-08-15Merge branch 'master' into feature/incorporate-tracingpawanbisht62-20/+13
2020-08-13Rollup merge of #75319 - estebank:format-ice, r=eddybTyler Mandry-20/+13
Fix ICE #75307 in `format` Remove usages of `unwrap` (even when some are safe today). Fix #75307.
2020-08-10Merge branch 'master' into feature/incorporate-tracingpawanbisht62-79/+117
2020-08-08Fix ICE #75307 in `format`Esteban Küber-20/+13
Remove usages of `unwrap` (even when some are safe today).
2020-08-08Eliminate the `SessionGlobals` from `librustc_ast`.Nicholas Nethercote-79/+117
By moving `{known,used}_attrs` from `SessionGlobals` to `Session`. This means they are accessed via the `Session`, rather than via TLS. A few `Attr` methods and `librustc_ast` functions are now methods of `Session`. All of this required passing a `Session` to lots of functions that didn't already have one. Some of these functions also had arguments removed, because those arguments could be accessed directly via the `Session` argument. `contains_feature_attr()` was dead, and is removed. Some functions were moved from `librustc_ast` elsewhere because they now need to access `Session`, which isn't available in that crate. - `entry_point_type()` --> `librustc_builtin_macros` - `global_allocator_spans()` --> `librustc_metadata` - `is_proc_macro_attr()` --> `Session`
2020-08-06Merge branch 'master' into feature/incorporate-tracingpawanbisht62-3/+2
2020-08-06Incorporate tracing cratebishtpawan-3/+3
2020-08-04rustc_ast: `(Nested)MetaItem::check_name` -> `has_name`Vadim Petrochenkov-2/+2
For consistency with `Attribute::has_name` which doesn't mark the attribute as used either. Replace all uses of `check_name` with `has_name` outside of rustc
2020-08-02Auto merge of #74948 - lzutao:stalize-result-as-deref, r=dtolnaybors-1/+0
Stabilize `Result::as_deref` and `as_deref_mut` FCP completed in https://github.com/rust-lang/rust/issues/50264#issuecomment-645681400. This PR stabilizes two new APIs for `std::result::Result`: ```rust fn as_deref(&self) -> Result<&T::Target, &E> where T: Deref; fn as_deref_mut(&mut self) -> Result<&mut T::Target, &mut E> where T: DerefMut; ``` This PR also removes two rarely used unstable APIs from `Result`: ```rust fn as_deref_err(&self) -> Result<&T, &E::Target> where E: Deref; fn as_deref_mut_err(&mut self) -> Result<&mut T, &mut E::Target> where E: DerefMut; ``` Closes #50264
2020-07-31Move from `log` to `tracing`Oliver Scherer-1/+1
2020-07-31Stabilize as_deref and as_deref on ResultLzu Tao-1/+0
2020-07-17Remove `ExtCtxt::ident_of`.Nicholas Nethercote-130/+153
It's equivalent to `Ident::from_str_and_span`. The commit also introduces some more static symbols so that `Ident::new` can be used in various places instead of `Ident::from_str_and_span`. The commit also changes `Path::path` from a `&str` to a `Symbol`, which then allows the lifetime annotation to be removed from `Ty`. Also, the use of `Symbol` in `Bounds` removes the need for its lifetime annotation.
2020-07-17Simplify `LifetimeBounds`.Nicholas Nethercote-52/+34
The `lifetimes` field is always empty. This commit removes it, and renames the type as `Bounds`.
2020-07-17Remove unused `cx` parameter from `pathvec_std` and `path_std`.Nicholas Nethercote-21/+21
2020-07-15Add and use more static symbols.Nicholas Nethercote-49/+40
Note that the output of `unpretty-debug.stdout` has changed. In that test the hash values are normalized from a symbol numbers to small numbers like "0#0" and "0#1". The increase in the number of static symbols must have caused the original numbers to contain more digits, resulting in different pretty-printing prior to normalization.
2020-07-06Rollup merge of #73953 - JohnTitor:audit-hidden-sugg, r=estebankManish Goregaokar-0/+2
Audit hidden/short code suggestions Should fix #73641. Audit uses of `span_suggestion_short` and `tool_only_span_suggestion` (`span_suggestion_hidden` is already tested with `run-rustfix`). Leave some FIXMEs for futher improvements/fixes. r? @estebank
2020-07-03Rollup merge of #73670 - davidhewitt:format-args-capture, r=varkorManish Goregaokar-4/+53
Add `format_args_capture` feature This is the initial implementation PR for [RFC 2795](https://github.com/rust-lang/rfcs/pull/2795). Note that, as dicussed in the tracking issue (#67984), the feature gate has been called `format_args_capture`. Next up I guess I need to add documentation for this feature. I've not written any docs before for rustc / std so I would appreciate suggestions on where I should add docs.
2020-07-02Rollup merge of #73812 - petrochenkov:prettyref, r=varkorManish Goregaokar-2/+2
ast_pretty: Pass some token streams and trees by reference Salvaged from an intermediate version of https://github.com/rust-lang/rust/pull/73345.
2020-07-02Audit uses of `tool_only_span_suggestion`Yuki Okushi-0/+2
2020-07-01Update src/librustc_builtin_macros/format.rsDavid Hewitt-1/+1
Apply suggestion from varkor Co-authored-by: varkor <github@varkor.com>
2020-07-01Amend wording of noteDavid Hewitt-1/+1
2020-06-27Rename two `Resolver` traitsVadim Petrochenkov-9/+9
2020-06-27ast_pretty: Pass some token streams and trees by referenceVadim Petrochenkov-2/+2
2020-06-27Improve messaging from PR feedbackDavid Hewitt-9/+5
2020-06-26Rollup merge of #73597 - ayazhafiz:i/const-span, r=ecstatic-morseManish Goregaokar-1/+1
Record span of `const` kw in GenericParamKind Context: this is needed for a fix of https://github.com/rust-lang/rustfmt/issues/4263, which currently records the span of a const generic param incorrectly because the location of the `const` kw is not known. I am not sure how to add tests for this; any guidance in how to do so would be appreciated :slightly_smiling_face:
2020-06-25Auto merge of #71858 - petrochenkov:env, r=Mark-Simulacrumbors-7/+12
Print environment variables accessed by rustc as special comments into depinfo files So cargo (and perhaps others tools) can use them for linting (at least) or for actually rebuilding crates on env var changes. --- I've recently observed one more forgotten environment variable in a build script https://github.com/rust-lang/rust/pull/71314/commits/8a77d1ca3fc2df789157f7986ddbaf2a377ff0fe and thought it would be nice to provide the list of accessed variables to cargo automatically as a part of depinfo. Unsurprisingly, I wasn't the first who had this idea - cc https://github.com/rust-lang/rust/issues/70517 https://github.com/rust-lang/rust/issues/40364 https://github.com/rust-lang/rust/issues/44074. Also, there are dozens of uses of `(option_)env!` in rustc repo and, like, half of them are not registered in build scripts. --- Description: - depinfo files are extended with special comments containing info about environment variables accessed during compilation. - Comment format for environment variables with successfully retrieved value: `# env-dep:KEY=VALUE`. - Comment format for environment variables without successfully retrieved value: `# env-dep:KEY` (can happen with `option_env!`). - `KEY` and `VALUE` are minimally escaped (`\n`, `\r`, `\\`) so they don't break makefile comments and can be unescaped by anything that can unescape standard `escape_default` and friends. FCP report: https://github.com/rust-lang/rust/pull/71858#issuecomment-633071488 Closes https://github.com/rust-lang/rust/issues/70517 Closes https://github.com/rust-lang/rust/issues/40364 Closes https://github.com/rust-lang/rust/issues/44074 A new issue in the cargo repo will be needed to track the cargo side of this feature. r? @ehuss
2020-06-24Add `format_args_capture` featureDavid Hewitt-4/+57
2020-06-23Record span of `const` kw in GenericParamKindAyaz Hafiz-1/+1
Context: this is needed to fix https://github.com/rust-lang/rustfmt/issues/4263, which currently records the span of a const generic param incorrectly because the location of the `const` kw is not known. I am not sure how to add tests for this; any guidance in how to do so would be appreciated :slightly_smiling_face:
2020-06-20Run `./x.py fmt`Camelid-4/+1
2020-06-20Fix duplicate options errorCamelid-9/+12
The UI isn't glitching anymore.
2020-06-20Use `p.token` instead of `p.look_ahead()`Camelid-1/+1
2020-06-20Add documentationCamelid-0/+9
2020-06-20Create a separate, tool-only suggestion for the commaCamelid-5/+9
That way the comma isn't highlighted as part of the option in the UI. Weirdly, the comma removal suggestion shows up in the UI.
2020-06-20Make suggestion machine-applicableCamelid-2/+11
2020-06-20Use `span_suggestion` instead of `span_label`Camelid-1/+1
2020-06-20Use bitflags function instead of custom oneCamelid-7/+1
2020-06-20Get option name from symbol instead of snippetCamelid-17/+19
2020-06-20Use `span_label`Camelid-1/+1
2020-06-20Make warning an error; use help instead of suggestion; clean up codeCamelid-46/+21
For some reason, the help message is now in a separate message, which adds a lot of noise. I would like to try to get it back to one message.
2020-06-20Warn on duplicate `asm!` optionsCamelid-7/+58
2020-06-20Clean upCamelid-3/+3
2020-06-20Use `Vec<Span>` instead of `Option<Vec<Span>>`Camelid-13/+9
2020-06-20Allow multiple `asm!` optionsCamelid-16/+13
2020-06-15asm: Allow multiple template strings; interpret them as newline-separatedJosh Triplett-145/+182
Allow the `asm!` macro to accept a series of template arguments, and interpret them as if they were concatenated with a '\n' between them. This allows writing an `asm!` where each line of assembly appears in a separate template string argument. This syntax makes it possible for rustfmt to reliably format and indent each line of assembly, without risking changes to the inside of a template string. It also avoids the complexity of having the user carefully format and indent a multi-line string (including where to put the surrounding quotes), and avoids the extra indentation and lines of a call to `concat!`. For example, rewriting the second example from the [blog post on the new inline assembly syntax](https://blog.rust-lang.org/inside-rust/2020/06/08/new-inline-asm.html) using multiple template strings: ```rust fn main() { let mut bits = [0u8; 64]; for value in 0..=1024u64 { let popcnt; unsafe { asm!( " popcnt {popcnt}, {v}", "2:", " blsi rax, {v}", " jz 1f", " xor {v}, rax", " tzcnt rax, rax", " stosb", " jmp 2b", "1:", v = inout(reg) value => _, popcnt = out(reg) popcnt, out("rax") _, // scratch inout("rdi") bits.as_mut_ptr() => _, ); } println!("bits of {}: {:?}", value, &bits[0..popcnt]); } } ``` Note that all the template strings must appear before all other arguments; you cannot, for instance, provide a series of template strings intermixed with the corresponding operands. In order to get srcloc mappings right for macros that generate multi-line string literals, create one line_span for each line in the string literal, each pointing to the macro. Make `rustc_parse_format::Parser::curarg` `pub`, so that we can propagate it from one template string argument to the next.
2020-06-14asm: Unify pseudo-keyword parsing using `eat`, rather than a final `expect`Josh Triplett-2/+3
Currently, `asm!` parsing uses an `expect` for the last parsed pseudo-keyword (`sym`), which makes it difficult to extend without simultaneously refactoring. Use `eat` for the last pseudo-keyword, and then add an `else` that fails parsing. No change to error output.
2020-06-12Rollup merge of #73178 - petrochenkov:explint, r=varkorDylan DPC-2/+3
expand: More precise locations for expansion-time lints First commit: a macro expansion doesn't have a `NodeId` associated with it, but it has a parent `DefId` which we can use for linting. The observable effect is that lints associated with macro expansions can now be `allow`ed at finer-grained level than whole crate. Second commit: each macro definition has a `NodeId` which we can use for linting, unless that macro definition was decoded from other crate.
2020-06-11Rollup merge of #73230 - Amanieu:asm-unused2, r=petrochenkovDylan DPC-18/+29
Suggest including unused asm arguments in a comment to avoid error We require all arguments to an `asm!` to be used in the template string, just like format strings. However in some cases (e.g. `black_box`) it may be desirable to have `asm!` arguments that are not used in the template string. Currently this is a hard error rather than a lint since `#[allow]` does not work on macros (#63221), so this PR suggests using the unused arguments in an asm comment as a workaround. r? @petrochenkov