| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
When we suggest the replacement for a macro we include the "!" in the
suggested replacement but the span only contains the name of the macro
itself. Using that replacement would cause a duplicate "!" in the
resulting code.
I originally tried to extend the span to be replaced by 1 byte in
rust-lang/rust#47424. However, @zackmdavis pointed out that there can be
whitespace between the macro name and the bang.
Instead, just remove the bang from the suggested replacement.
Fixes #47418
|
|
No longer parse it.
Remove AutoTrait variant from AST and HIR.
Remove backwards compatibility lint.
Remove coherence checks, they make no sense for the new syntax.
Remove from rustdoc.
|
|
Use DefIndex encoding that works better with on-disk variable length integer representations.
Use the least instead of the most significant bit for representing the address space.
r? @eddyb
|
|
macros: improve 1.0/2.0 interaction
This PR supports using unhygienic macros from hygienic macros without breaking the latter's hygiene.
```rust
// crate A:
#[macro_export]
macro_rules! m1 { () => {
f(); // unhygienic: this macro needs `f` in its environment
fn g() {} // (1) unhygienic: `g` is usable outside the macro definition
} }
// crate B:
#![feature(decl_macro)]
extern crate A;
use A::m1;
macro m2() {
fn f() {} // (2)
m1!(); // After this PR, `f()` in the expansion resolves to (2), not (3)
g(); // After this PR, this resolves to `fn g() {}` from the above expansion.
// Today, it is a resolution error.
}
fn test() {
fn f() {} // (3)
m2!(); // Today, `m2!()` can see (3) even though it should be hygienic.
fn g() {} // Today, this conflicts with `fn g() {}` from the expansion, even though it should be hygienic.
}
```
Once this PR lands, you can make an existing unhygienic macro hygienic by wrapping it in a hygienic macro. There is an [example](https://github.com/rust-lang/rust/pull/46551/commits/b766fa887dc0e4b923a38751fe4d570e35a75710) of this in the tests.
r? @nrc
|
|
length integer encodings.
|
|
Upgrade `log` to `0.4` in multiple crates.
|
|
Support `extern` in paths
Implement the primary alternative to https://github.com/rust-lang/rust/pull/46613 + https://github.com/rust-lang/rust/pull/45771, achieving the same effect without requiring changes to other imports.
Both need to be experimentally evaluated before making further progress.
The PR also adds docs for all these related features into the unstable book.
cc https://github.com/rust-lang/rust/issues/44660
r? @nikomatsakis
|
|
rustc: use {U,I}size instead of {U,I}s shorthands.
`Us`/`Is` come from a time when `us` and `is` were the literal suffixes that are now `usize` / `isize`.
r? @nikomatsakis
|
|
These no longer work now that Cargo changes the cwd of rustc while it's running.
Instead use an absolute path that's set by rustbuild.
|
|
|
|
|
|
Report an error when resolving non-ident macro path failed
Closes #41719.
Please feel free to bikeshed on the error message.
|
|
|
|
|
|
Closure type error ui tweak
Do not point at the same span on all notes/help messages, and instead
show them without a span.
|
|
The Generics now contain one Vec of an enum for the generic parameters,
rather than two separate Vec's for lifetime and type parameters.
Additionally, places that previously used Vec<LifetimeDef> now use
Vec<GenericParam> instead.
|
|
|
|
|
|
|
|
|
|
|
|
macros: hygienize use of `core`/`std` in builtin macros
Today, if a builtin macro wants to access an item from `core` or `std` (depending `#![no_std]`), it generates `::core::path::to::item` or `::std::path::to::item` respectively (c.f. `fn std_path()` in `libsyntax/ext/base.rs`).
This PR refactors the builtin macros to instead always emit `$crate::path::to::item` here. That is, the def site of builtin macros is taken to be in `extern crate core;` or `extern crate std;`. Since builtin macros are macros 1.0 (i.e. mostly unhygienic), changing the def site can only effect the resolution of `$crate`.
r? @nrc
|
|
Record all imports (`use`, `extern crate`) in the crate metadata
This PR adds non-`pub` `use` and `extern crate` imports in the crate metadata since hygienic macros invoked in other crates may use them. We already include all other non-`pub` items in the crate metadata. This improves import suggestions in some cases.
Fixes #42337.
r? @nrc
|
|
|
|
|
|
|
|
We issue just one message for an erroneous glob private variant reëxport
(using the Session's one-time-diagnostics capability), but individual
(non-glob) such erroneous reëxports still get their own messages. The
suggestion to make the enum public is also one-time.
The enum variant reëxport error didn't have an associated error code
(and remedying this here is deemed out of the scope of this commit), so
we resort to the expediency of using 0 as the `DiagnosticMessageId`
value.
Adding Debug to NameResolution was helpful in development.
This resolves #46209.
|
|
|
|
macros 2.0.
|
|
Fix hygiene bug.
Fixes #42708.
r? @nrc
|
|
Generic Associated Types Parsing & Name Resolution
Hi!
This PR adds parsing for generic associated types! :tada: :tada: :tada:
Tracking Issue: #44265
## Notes For Reviewers
* [x] I still need to add the stdout and stderr files to my ui tests. It takes me a *long* time to compile the compiler locally, so I'm going to add this as soon as possible in the next day or so.
* [ ] My current ui tests aren't very good or very thorough. I'm reusing the `parse_generics` and `parse_where_clause` methods from elsewhere in the parser, so my changes work without being particularly complex. I'm not sure if I should duplicate all of the generics test cases for generic associated types. It might actually be appropriate to duplicate everything here, since we don't want to rely on an implementation detail in case it changes in the future. If you think so too, I'll adapt all of the generics test cases into the generic associated types test cases.
* [ ] There is still more work required to make the run-pass tests pass here. In particular, we need to make the following errors disappear:
```
error[E0110]: lifetime parameters are not allowed on this type
--> ./src/test/run-pass/rfc1598-generic-associated-types/streaming_iterator.rs:23:41
|
23 | bar: <T as StreamingIterator>::Item<'static>,
| ^^^^^^^ lifetime parameter not allowed on this type
```
```
error[E0261]: use of undeclared lifetime name `'a`
--> ./src/test/run-pass/rfc1598-generic-associated-types/iterable.rs:15:47
|
15 | type Iter<'a>: Iterator<Item = Self::Item<'a>>;
| ^^ undeclared lifetime
```
There is a FIXME comment in streaming_iterator. If you uncomment that line, you get the following:
```
error: expected one of `!`, `+`, `,`, `::`, or `>`, found `=`
--> ./src/test/run-pass/rfc1598-generic-associated-types/streaming_iterator.rs:29:45
|
29 | fn foo<T: for<'a> StreamingIterator<Item<'a>=&'a [i32]>>(iter: T) { /* ... */ }
| ^ expected one of `!`, `+`, `,`, `::`, or `>` here
```
r? @nikomatsakis
|
|
which was never used. Lifting the HasTypeParameters rib to all trait item kinds and all impl item kinds
|
|
|
|
Account for missing keyword in fn/struct definition
Fix #38911.
|
|
This commit adds support for nested groups inside `use` declarations,
such as `use foo::{bar, sub::{baz::Foo, *}};`.
|
|
|
|
Try to identify the following code in order to provide better
diagnostics, but return the error to bail out early during the parse.
|
|
When encountering `pub ident`, attempt to identify the code that comes
afterwards, wether it is a brace block (assume it is a struct), a paren
list followed by a colon (assume struct) or a paren list followed by a
block (assume a fn). Consume those blocks to avoid any further parser
errors and return a `Placeholder` item in order to allow the parser to
continue. In the case of unenclosed blocks, the behavior is the same as
it is currently: no further errors are processed.
|
|
Add hints for the case of confusing enum with its variants
A solution for https://github.com/rust-lang/rust/issues/43871. When one uses an enum in a place that accepts variants (e.g., `Option(result)` instead of `Some(result)`), suggest one of this enum's variants.
cc @estebank
|
|
|
|
|
|
Add structured suggestions for various "use" suggestions
r? @petrochenkov
|
|
|
|
|
|
|
|
|
