| Age | Commit message (Collapse) | Author | Lines |
|---|
|
proc macros
|
|
|
|
Remove lifetime from Resolver
|
|
Contexually dependent error message for E0424 when value is assigned to "self"
This is an improvement for pull request #54495 referencing issue #54369. If the "self" keyword is assigned a value as though it were a valid identifier, it will now report:
```
let self = "self";
^^^^ `self` value is a keyword and may not be bound to variables or shadowed
```
instead of
```
let self = "self";
^^^^ `self` value is a keyword only available in methods with `self` parameter
```
If anyone has a better idea for what the error should be I'd be happy to modify it appropriately.
|
|
|
|
Ever since we added a Cargo-based build system for the compiler the
standard library has always been a little special, it's never been able
to depend on crates.io crates for runtime dependencies. This has been a
result of various limitations, namely that Cargo doesn't understand that
crates from crates.io depend on libcore, so Cargo tries to build crates
before libcore is finished.
I had an idea this afternoon, however, which lifts the strategy
from #52919 to directly depend on crates.io crates from the standard
library. After all is said and done this removes a whopping three
submodules that we need to manage!
The basic idea here is that for any crate `std` depends on it adds an
*optional* dependency on an empty crate on crates.io, in this case named
`rustc-std-workspace-core`. This crate is overridden via `[patch]` in
this repository to point to a local crate we write, and *that* has a
`path` dependency on libcore.
Note that all `no_std` crates also depend on `compiler_builtins`, but if
we're not using submodules we can publish `compiler_builtins` to
crates.io and all crates can depend on it anyway! The basic strategy
then looks like:
* The standard library (or some transitive dep) decides to depend on a
crate `foo`.
* The standard library adds
```toml
[dependencies]
foo = { version = "0.1", features = ['rustc-dep-of-std'] }
```
* The crate `foo` has an optional dependency on `rustc-std-workspace-core`
* The crate `foo` has an optional dependency on `compiler_builtins`
* The crate `foo` has a feature `rustc-dep-of-std` which activates these
crates and any other necessary infrastructure in the crate.
A sample commit for `dlmalloc` [turns out to be quite simple][commit].
After that all `no_std` crates should largely build "as is" and still be
publishable on crates.io! Notably they should be able to continue to use
stable Rust if necessary, since the `rename-dependency` feature of Cargo
is soon stabilizing.
As a proof of concept, this commit removes the `dlmalloc`,
`libcompiler_builtins`, and `libc` submodules from this repository. Long
thorns in our side these are now gone for good and we can directly
depend on crates.io! It's hoped that in the long term we can bring in
other crates as necessary, but for now this is largely intended to
simply make it easier to manage these crates and remove submodules.
This should be a transparent non-breaking change for all users, but one
possible stickler is that this almost for sure breaks out-of-tree
`std`-building tools like `xargo` and `cargo-xbuild`. I think it should
be relatively easy to get them working, however, as all that's needed is
an entry in the `[patch]` section used to build the standard library.
Hopefully we can work with these tools to solve this problem!
[commit]: https://github.com/alexcrichton/dlmalloc-rs/commit/28ee12db813a3b650a7c25d1c36d2c17dcb88ae3
|
|
|
|
resolve: Reduce some clutter in import ambiguity errors
Noticed in https://www.reddit.com/r/rust/comments/a3pyrw/announcing_rust_131_and_rust_2018/eb8alhi/.
The first error is distracting, but unnecessary, it's a *consequence* of the ambiguity error and appears because one of the ambiguous `actix` modules (unsurprisingly) doesn't have the expected name in it.
|
|
|
|
|
|
Replace usages of `..i + 1` ranges with `..=i`.
Before this change we were using old computer code techniques. After this change we use the new and improved computer code techniques.
|
|
attributes
|
|
Delay gensym creation for "underscore items" (`use foo as _`/`const _`) until name resolution
So they cannot be cloned by macros. See https://github.com/rust-lang/rust/pull/56303 for the discussion.
Mostly fix cross-crate use of underscore items by inverting the "gensyms are lost in metadata" bug as described in https://github.com/rust-lang/rust/pull/56303#issuecomment-442464695.
Fix unused import warnings for single-segment imports (first commit) and `use crate_name as _` imports (as specified in https://github.com/rust-lang/rust/pull/56303#issuecomment-442274118).
Prohibit accidentally implemented `static _: TYPE = EXPR;` (cc https://github.com/rust-lang/rust/pull/55983).
Add more tests for `use foo as _` imports.
|
|
libsyntax_pos: A few tweaks
|
|
|
|
|
|
`CrateRoot` -> `PathRoot`, `::` doesn't necessarily mean crate root now
`SelfValue` -> `SelfLower`, `SelfType` -> `SelfUpper`, both `self` and `Self` can be used in type and value namespaces now
|
|
Stabilize self_in_typedefs feature
[**Tracking Issue**](https://github.com/rust-lang/rust/issues/49303)
r? @centril
|
|
|
|
Prohibit `static _`
Fis unused import warnings for `use foo as _`
Add more tests for `use foo as _`
|
|
|
|
|
|
|
|
|
|
|
|
More precise spans for ambiguities from macros
|
|
edition
|
|
Flatten `ModuleOrUniformRoot` variants
|
|
|
|
Use per-span hygiene in a few other places in resolve
Prefer `rust_2015`/`rust_2018` helpers to comparing editions
|
|
|
|
|
|
|
|
|
|
resolve: Make "empty import canaries" invisible from other crates
Empty imports `use prefix::{};` are desugared into `use prefix::{self as _};` to make sure the prefix is checked for privacy/stability/etc.
This caused issues in cross-crate scenarios because gensyms are lost in crate metadata (the `_` is a gensym).
Fixes https://github.com/rust-lang/rust/issues/55811
|
|
rustc: remove {FxHash,Node,DefId,HirId,ItemLocal}{Map,Set} "constructor" fns.
These are cruft left over from a time when `Foo::default()` didn't "just work".
|
|
|
|
|
|
|
|
|
|
|
|
|
|
generic parameters
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
