| Age | Commit message (Collapse) | Author | Lines |
|
Support stability and deprecation checking for all macros
RELNOTES: Deprecation attributes on macros now have effect.
Fixes https://github.com/rust-lang/rust/issues/34079
Fixes https://github.com/rust-lang/rust/issues/49912
Unblocks https://github.com/rust-lang/rust/pull/62086
Unblocks https://github.com/rust-lang/rust/pull/61000
|
|
They always end up interned anyway
|
|
Now that procedural macros no longer link transitively to libsyntax,
this shouldn't be needed any more! This commit is an experiment in
removing all dynamic libraries from rustc except for librustc_driver
itself. Let's see how far we can get with that!
|
|
|
|
|
|
|
|
Implement another internal lints
cc #49509
This adds ~~two~~ one internal lint~~s~~:
1. LINT_PASS_IMPL_WITHOUT_MACRO: Make sure, that the `{declare,impl}_lint_pass` macro is used to implement lint passes. cc #59669
2. ~~USAGE_OF_TYCTXT_AND_SPAN_ARGS: item 2 on the list in #49509~~
~~With 2. I wasn't sure, if this lint should be applied everywhere. That means a careful review of 0955835 would be great. Also 73fb9b4 allows this lint on some functions. Should I also apply this lint there?~~
TODO (not directly relevant for review):
- [ ] https://github.com/rust-lang/rust/pull/59316#discussion_r280186517 (not sure yet, if this works or how to query for `rustc_private`, since it's not in [`Features`](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/feature_gate/struct.Features.html) :thinking: cc @eddyb)
- [x] https://github.com/rust-lang/rust/pull/61735#discussion_r292389870
- [x] Check explicitly for the `{declare,impl}_lint_pass!` macros
r? @oli-obk
|
|
|
|
Minimizes risk.
|
|
Inform the query system about properties of queries at compile time
|
|
Implement arbitrary_enum_discriminant
Implements RFC rust-lang/rfcs#2363 (tracking issue #60553).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This is an extremely marginal error, so the cost of properly threading
`Handler` everywhere just not seemed justified. However, it's useful
to panic when we create a file, and not when we slice strings with
overflown indexes somewhere in the guts of the compiler.
For this reason, while we provide safe `try_new_source_file`, we don't
change the existing public interface and just panic more or less
cleanly.
|
|
Optimize matches
Attempt to fix or improve #60571
This is breaking some diagnostics because the MIR for match arms isn't in source order any more.
cc @centril
|
|
r=petrochenkov
Remove some unnecessary symbol interner ops
* Don't gensym symbols that don't need to worry about colliding with other symbols
* Use symbol constants instead of interning string literals in a few places.
* Don't generate a module in `__register_diagnostic`
r? @petrochenkov
|
|
|
|
|
|
We used to call the less efficient `<&str>::eq` and `<&[T]>::eq`.
|
|
Allow attributes in formal function parameters
Implements https://github.com/rust-lang/rust/issues/60406.
This is my first contribution to the compiler and since this is a large and complex project, I am not fully aware of the consequences of the changes I have made.
**TODO**
- [x] Forbid some built-in attributes.
- [x] Expand cfg/cfg_attr
|
|
Use Symbol, Span in libfmt_macros
I'm not super happy with this, personally, but I think it might be a decent start -- happy to take suggestions as to how to expand this or change things further.
r? @estebank
Fixes #60795
|
|
Add deny(unused_lifetimes) to all the crates that have deny(internal).
@Zoxc brought up, regarding #61722, that we don't force the removal of unused lifetimes.
Turns out that it's not that bad to enable for compiler crates (I wonder why it's not `warn` by default?).
I would've liked to enable `single_use_lifetimes` as well, but https://github.com/rust-lang/rust/issues/53738 makes it unusable for now.
For the `rustfmt` commit, I used https://github.com/rust-lang/rustfmt/issues/1324#issuecomment-482109952, and manually filtered out some noise.
r? @oli-obk cc @rust-lang/compiler
|
|
|
|
Tracking issue: #60405
|
|
This should be used when trying to get at subsets of a larger span,
especially when the larger span is not available in the code attempting
to work with those subsets (especially common in the fmt_macros crate).
This is usually a good replacement for (BytePos, BytePos) and (usize,
usize) tuples.
This commit also removes from_inner_byte_pos, since it took usize
arguments, which is error prone.
|
|
|
|
|
|
Unlike other built-in attributes, this attribute accepts any input
|
|
`#[rustc_allocator]`
|
|
|
|
Make tuple constructors real const fns
Mir construction special cases `Ctor(...)` to be lowered as `Ctor { 0: ... }`, which means this doesn't come up much in practice, but it seems inconsistent not to allow this.
r? @oli-obk
|
|
|
|
|
|
|
|
|
|
|
|
These combine two `HygieneData::with` calls into one.
|
|
|
|
This combines multiple `HygieneData::with` calls on a hot path.
|
|
This combines multiple `HygieneData::with` calls into one, by combining
parts of `hygienic_eq` and `adjust_ident`.
|
|
This combines two `HygieneData::with` calls into one on a hot path.
|
|
They can each now do a single `HygieneData::with` call by replacing the
`SyntaxContext` and `Mark` methods with the equivalent methods from
`HygieneData`.
|
|
This combines two `HygieneData::with` calls into one.
|