| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
rename cfg(rustdoc) into cfg(doc)
Needed by https://github.com/rust-lang/rust/pull/61351
r? @QuietMisdreavus
|
|
- Use `Option<NonZeroU32>` to represent issue numbers.
|
|
Support registering inert attributes and attribute tools using crate-level attributes
And remove `#[feature(custom_attribute)]`.
(`rustc_plugin::Registry::register_attribute` is not removed yet, I'll do it in a follow up PR.)
```rust
#![register_attr(my_attr)]
#![register_tool(my_tool)]
#[my_attr] // OK
#[my_tool::anything] // OK
fn main() {}
```
---
Some tools (`rustfmt` and `clippy`) used in tool attributes are hardcoded in the compiler.
We need some way to introduce them without hardcoding as well.
This PR introduces a way to do it with a crate level attribute.
The previous attempt to introduce them through command line (https://github.com/rust-lang/rust/pull/57921) met some resistance.
This probably needs to go through an RFC before stabilization.
However, I'd prefer to land *this* PR without an RFC to able to remove `#[feature(custom_attribute)]` and `Registry::register_attribute` while also providing a replacement.
---
`register_attr` is a direct replacement for `#![feature(custom_attribute)]` (https://github.com/rust-lang/rust/issues/29642), except it doesn't rely on implicit fallback from unresolved attributes to custom attributes (which was always hacky and is the primary reason for the removal of `custom_attribute`) and requires registering the attribute explicitly.
It's not clear whether it should go through stabilization or not.
It's quite possible that all the uses should migrate to `#![register_tool]` (https://github.com/rust-lang/rust/issues/66079) instead.
---
Details:
- The naming is `register_attr`/`register_tool` rather than some `register_attributes` (plural, no abbreviation) for consistency with already existing attributes like `cfg_attr`, or `feature`, etc.
---
Previous attempt: https://github.com/rust-lang/rust/pull/57921
cc https://github.com/rust-lang/rust/issues/44690
Tracking issues: #66079 (`register_tool`), #66080 (`register_attr`)
Closes https://github.com/rust-lang/rust/issues/29642
|
|
Split libsyntax apart
In this PR the general idea is to separate the AST, parser, and friends by a more data / logic structure (tho not fully realized!) by separating out the parser and macro expansion code from libsyntax. Specifically have now three crates instead of one (libsyntax):
- libsyntax:
- concrete syntax tree (`syntax::ast`)
- definition of tokens and token-streams (`syntax::{token, tokenstream}`) -- used by `syntax::ast`
- visitors (`syntax::visit`, `syntax::mut_visit`)
- shared definitions between `libsyntax_expand`
- feature gating (`syntax::feature_gate`) -- we could possibly move this out to its own crater later.
- attribute and meta item utilities, including used-marking (`syntax::attr`)
- pretty printer (`syntax::print`) -- this should possibly be moved out later. For now I've reduced down the dependencies to a single essential one which could be broken via `ParseSess`. This entails that e.g. `Debug` impls for `Path` cannot reference the pretty printer.
- definition of `ParseSess` (`syntax::sess`) -- this is used by `syntax::{attr, print, feature_gate}` and is a common definition used by the parser and other things like librustc.
- the `syntax::source_map` -- this includes definitions used by `syntax::ast` and other things but could ostensibly be moved `syntax_pos` since that is more related to this module.
- a smattering of misc utilities not sufficiently important to itemize -- some of these could be moved to where they are used (often a single place) but I wanted to limit the scope of this PR.
- librustc_parse:
- parser (`rustc_parse::parser`) -- reading a file and such are defined in the crate root tho.
- lexer (`rustc_parse::lexer`)
- validation of meta grammar (post-expansion) in (`rustc_parse::validate_attr`)
- libsyntax_expand -- this defines the infra for macro expansion and conditional compilation but this is not libsyntax_ext; we might want to merge them later but currently libsyntax_expand is depended on by librustc_metadata which libsyntax_ext is not.
- conditional compilation (`syntax_expand::config`) -- moved from `syntax::config` to here
- the bulk of this crate is made up of the old `syntax::ext`
r? @estebank
|
|
|
|
|
|
|
|
r=nikomatsakis
Stabilize the `re_rebalance_coherence` feature
This PR stabilizes [RFC 2451](https://rust-lang.github.io/rfcs/2451-re-rebalancing-coherence.html), re-rebalance coherence.
Changes include removing the attribute from tests which tested both the old and new behavior, moving the feature to `accepted` and removing the old logic.
I'll also open a [PR](https://github.com/rust-lang-nursery/reference/pull/703) against the reference, updating it with the content of the RFC.
Closes #63599
r? @nikomatsakis
|
|
|
|
The code was previously suggesting `#[repr(C, packed, ...)]` for
incorrect uses of `repr` (e.g. `#[repr = "C"]`). This change suggests
the usage of `#[repr(C)]` instead.
r? @estebank
ref #61286
|
|
Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>
|
|
|
|
A scheme for more macro-matcher friendly pre-expansion gating
Pre-expansion gating will now avoid gating macro matchers that did not result in `Success(...)`. That is, the following is now OK despite `box 42` being a valid `expr` and that form being pre-expansion gated:
```rust
macro_rules! m {
($e:expr) => { 0 }; // This fails on the input below due to `, foo`.
(box $e:expr, foo) => { 1 }; // Successful matcher, we should get `2`.
}
fn main() {
assert_eq!(1, m!(box 42, foo));
}
```
Closes https://github.com/rust-lang/rust/issues/65846.
r? @petrochenkov
cc @Mark-Simulacrum
|
|
syntax: ABI-oblivious grammar
This PR has the following effects:
1. `extern $lit` is now legal where `$lit:literal` and `$lit` is substituted for a string literal.
2. `extern "abi_that_does_not_exist"` is now *syntactically* legal whereas before, the set of ABI strings was hard-coded into the grammar of the language. With this PR, the set of ABIs are instead validated and translated during lowering. That seems more appropriate.
3. `ast::FloatTy` is now distinct from `rustc_target::abi::FloatTy`. The former is used substantially more and the translation between them is only necessary in a single place.
4. As a result of 2-3, libsyntax no longer depends on librustc_target, which should improve pipe-lining somewhat.
cc @rust-lang/lang -- the points 1-2 slightly change the definition of the language but in a way which seems consistent with our general principles (in particular wrt. the discussions of turning things into semantic errors). I expect this to be uncontroversial but it's worth letting y'all know. :)
r? @varkor
|
|
|
|
Rollup of 12 pull requests
Successful merges:
- #65794 (gate rustc_on_unimplemented under rustc_attrs)
- #65945 (Optimize long-linker-command-line test)
- #66044 (Improve uninit/zeroed lint)
- #66076 (HIR docs: mention how to resolve method paths)
- #66084 (Do not require extra LLVM backends for `x.py test` to pass)
- #66111 (improve from_raw_parts docs)
- #66114 (Improve std::thread::Result documentation)
- #66117 (Fixed PhantomData markers in Arc and Rc)
- #66146 (Remove unused parameters in `__thread_local_inner`)
- #66147 (Miri: Refactor to_scalar_ptr out of existence)
- #66162 (Fix broken link in README)
- #66171 (Update link on CONTRIBUTING.md)
Failed merges:
r? @ghost
|
|
gate rustc_on_unimplemented under rustc_attrs
Move `rustc_on_implemented` from the `on_implemented` gate to `rustc_attrs` as it is internal.
Closes #29628
r? @varkor
|
|
|
|
`AttrKind` is a new type with two variants, `Normal` and `DocComment`. It's a
big performance win (over 10% in some cases) because `DocComment` lets doc
comments (which are common) be represented very cheaply.
`Attribute` gets some new helper methods to ease the transition:
- `has_name()`: check if the attribute name matches a single `Symbol`; for
`DocComment` variants it succeeds if the symbol is `sym::doc`.
- `is_doc_comment()`: check if it has a `DocComment` kind.
- `{get,unwrap}_normal_item()`: extract the item from a `Normal` variant;
panic otherwise.
Fixes #60935.
|
|
This kind of thing just makes the code harder to read.
|
|
|
|
|
|
|
|
r=estebank
Rename `LocalInternedString` and more
This PR renames `LocalInternedString` as `SymbolStr`, removes an unnecessary `impl` from it, improves comments, and cleans up some `SymbolStr` uses.
r? @estebank
|
|
|
|
Including removing a bunch of unnecessary `.as_str()` calls, and a bunch
of unnecessary sigils.
|
|
|
|
This reverts commit 2d182b82ce5ecfe8090ba3d4e78f1cd72c072ef1.
|
|
This reverts commit c17a1fd7d0ef0f1f546445d0c8bdb11be55e4be7.
|
|
This reverts commit 04c661ba021730bc13d33c6d55cb9aad05026f36.
|
|
This reverts commit 49cbfa1a6f6469ddbc0e88161e52104cc87aea9b.
|
|
This reverts commit 1f470ceac2202ecffe8a15acc1139edb9ad4a03b.
|
|
This reverts commit 2aff6b36d7ed5c25700669a92b4a43200ee0fe6b.
|
|
This reverts commit 665a876e307933c6480a6c55a3e38e88937aff2c.
|
|
This reverts commit 1935ba658c576f14397c2c7a26a6642cf08f26a6.
|
|
This reverts commit 137ded8ab1edf5112c45e0b6854272ae2e9d3a6d.
|
|
This reverts commit e4ed8865786a787a7b0c045f7674569b6be0e9bc.
|
|
This reverts commit 15a6c09b6e8a977f2c6f5a73de01a20d00b37930.
|
|
|
|
|
|
Add new EFIAPI ABI
Fixes #54527
Adds a new ABI, "efiapi", which reflects the calling convention as specified by [the current spec UEFI spec](https://uefi.org/sites/default/files/resources/UEFI%20Spec%202_7_A%20Sept%206.pdf#G6.999903). When compiling for x86_64, we should select the `win64` ABI, while on all other architectures (Itanium, x86, ARM and ARM64 and RISC-V), we should select the `C` ABI.
Currently, this is done by just turning it into the C ABI everywhere except on x86_64, where it's turned into the win64 ABI. Should we prevent this ABI from being used on unsupported architectures, and if so, how would this be done?
|
|
|
|
|
|
Adds a new ABI for the EFIAPI calls. This ABI should reflect the latest
version of the UEFI specification at the time of commit (UEFI spec 2.8,
URL below). The specification says that for x86_64, we should follow the
win64 ABI, while on all other supported platforms (ia32, itanium, arm,
arm64 and risc-v), we should follow the C ABI.
To simplify the implementation, we will simply follow the C ABI on all
platforms except x86_64, even those technically unsupported by the UEFI
specification.
https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf
|
|
This commit stabilizes RFC 2008 (#44109) by removing the feature gate.
Signed-off-by: David Wood <david@davidtw.co>
|
|
Adjust the tracking issue for `untagged_unions`.
Makes https://github.com/rust-lang/rust/issues/55149 the new tracking issue for `untagged_unions`.
Closes https://github.com/rust-lang/rust/issues/32836 which is the old tracking issue.
r? @varkor
|
|
Also elaborate on some feature gates in `active.rs`.
|
|
|
|
|
