| Age | Commit message (Collapse) | Author | Lines |
|
This saves a couple of Symbol::intern calls
|
|
Remove deprecated LLVM-style inline assembly
The `llvm_asm!` was deprecated back in #87590 1.56.0, with intention to remove
it once `asm!` was stabilized, which already happened in #91728 1.59.0. Now it
is time to remove `llvm_asm!` to avoid continued maintenance cost.
Closes #70173.
Closes #92794.
Closes #87612.
Closes #82065.
cc `@rust-lang/wg-inline-asm`
r? `@Amanieu`
|
|
aborting immediately.
The panic handler is called with a special flag which forces it to abort
after calling the panic hook.
|
|
feat: rustc_pass_by_value lint attribute
Useful for thin wrapper attributes that are best passed as value instead
of reference.
Fixes #76935
|
|
Add diagnostic items for macros
For use in Clippy, it adds diagnostic items to all the stable public macros
Clippy has lints that look for almost all of these (currently by name or path), but there are a few that aren't currently part of any lint, I could remove those if it's preferred to add them as needed rather than ahead of time
|
|
Use pre-interned symbols in a couple of places
Re-open of https://github.com/rust-lang/rust/pull/92733 as bors glitched.
|
|
Particularly when constructing file paths and fully qualified paths.
This avoids a lot of allocations, speeding things up on almost all
examples.
|
|
|
|
|
|
Make `DefId` `repr(C)`, optimize big-endian field order
r? `@michaelwoerister`
|
|
|
|
Ensure that `Fingerprint` caching respects hashing configuration
Fixes #92266
In some `HashStable` impls, we use a cache to avoid re-computing
the same `Fingerprint` from the same structure (e.g. an `AdtDef`).
However, the `StableHashingContext` used can be configured to
perform hashing in different ways (e.g. skipping `Span`s). This
configuration information is not included in the cache key,
which will cause an incorrect `Fingerprint` to be used if
we hash the same structure with different `StableHashingContext`
settings.
To fix this, the configuration settings of `StableHashingContext`
are split out into a separate `HashingControls` struct. This
struct is used as part of the cache key, ensuring that our caches
always produce the correct result for the given settings.
With this in place, we now turn off `Span` hashing during the
entire process of computing the hash included in legacy symbols.
This current has no effect, but will matter when a future PR
starts hashing more `Span`s that we currently skip.
|
|
Useful for thin wrapper attributes that are best passed as value instead
of reference.
|
|
|
|
|
|
|
|
|
|
Fixes #92266
In some `HashStable` impls, we use a cache to avoid re-computing
the same `Fingerprint` from the same structure (e.g. an `AdtDef`).
However, the `StableHashingContext` used can be configured to
perform hashing in different ways (e.g. skipping `Span`s). This
configuration information is not included in the cache key,
which will cause an incorrect `Fingerprint` to be used if
we hash the same structure with different `StableHashingContext`
settings.
To fix this, the configuration settings of `StableHashingContext`
are split out into a separate `HashingControls` struct. This
struct is used as part of the cache key, ensuring that our caches
always produce the correct result for the given settings.
With this in place, we now turn off `Span` hashing during the
entire process of computing the hash included in legacy symbols.
This current has no effect, but will matter when a future PR
starts hashing more `Span`s that we currently skip.
|
|
Add negative `impl` for `Ord`, `PartialOrd` on `LocalDefId`
Suggested in https://github.com/rust-lang/rust/pull/92233#discussion_r776123222.
This also fixes some formatting in the doc comment.
r? `@cjgillot`
|
|
|
|
|
|
Add `#[rustc_clean(loaded_from_disk)]` to assert loading of query result
Currently, you can use `#[rustc_clean]` to assert to that a particular
query (technically, a `DepNode`) is green or red. However, a green
`DepNode` does not mean that the query result was actually deserialized
from disk - we might have never re-run a query that needed the result.
Some incremental tests are written as regression tests for ICEs that
occured during query result decoding. Using
`#[rustc_clean(loaded_from_disk="typeck")]`, you can now assert
that the result of a particular query (e.g. `typeck`) was actually
loaded from disk, in addition to being green.
|
|
Add comment about why `LocalDefId` should not be `Ord`
Also fix some formatting in the doc comment.
|
|
Implement `Ord`, `PartialOrd` for SpanData
|
|
Currently, you can use `#[rustc_clean]` to assert to that a particular
query (technically, a `DepNode`) is green or red. However, a green
`DepNode` does not mean that the query result was actually deserialized
from disk - we might have never re-run a query that needed the result.
Some incremental tests are written as regression tests for ICEs that
occured during query result decoding. Using
`#[rustc_clean(loaded_from_disk="typeck")]`, you can now assert
that the result of a particular query (e.g. `typeck`) was actually
loaded from disk, in addition to being green.
|
|
Remove `SymbolStr`
This was originally proposed in https://github.com/rust-lang/rust/pull/74554#discussion_r466203544. As well as removing the icky `SymbolStr` type, it allows the removal of a lot of `&` and `*` occurrences.
Best reviewed one commit at a time.
r? `@oli-obk`
|
|
Include rustc version in `rustc_span::StableCrateId`
`rustc_span::def_id::StableCrateId` is a hash of various data about a crate during compilation. This PR includes the version of `rustc` in the input when computing this hash. From a cursory reading of [RFC 2603](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html), this appears to be acceptable within that design.
In order to pass the `mir-opt` and `ui` test suites, this adds new [normalization for hashes and symbol names in `compiletest`](https://github.com/rust-lang/rust/pull/89836/files#diff-03a0567fa80ca04ed5a55f9ac5c711b4f84659be2d0ac4a984196d581c04f76b). These are enabled by default, but we might prefer it to be configurable.
In the UI tests, I had to truncate a significant amount of error annotations in v0 symbols (and maybe some legacy) in order to get the normalization to work correctly. (See https://github.com/rust-lang/rust/issues/90116.)
Closes #85142.
|
|
|
|
By changing `as_str()` to take `&self` instead of `self`, we can just
return `&str`. We're still lying about lifetimes, but it's a smaller lie
than before, where `SymbolStr` contained a (fake) `&'static str`!
|
|
manually implement `Hash` for `DefId`
This might speed up hashing for hashers that can work on individual u64s. Just as an experiment, suggested in a reddit thread on `FxHasher`. cc `@nnethercote`
Note that this should not be merged as is without cfg-ing the code path for 64 bits.
|
|
Implement RUSTC_FORCE_INCR_COMP_ARTIFACT_HEADER
Also makes minor docs edits.
|
|
Normalize symbol hashes in compiletest.
Remove DefId sorting
|
|
Remove redundant [..]s
|
|
This also reorders the fields to reduce the assembly operations for hashing
and changes two UI tests that depended on the former ordering because of
hashmap iteration order.
|
|
Rollup of 6 pull requests
Successful merges:
- #87599 (Implement concat_bytes!)
- #89999 (Update std::env::temp_dir to use GetTempPath2 on Windows when available.)
- #90796 (Remove the reg_thumb register class for asm! on ARM)
- #91042 (Use Vec extend instead of repeated pushes on several places)
- #91634 (Do not attempt to suggest help for overly malformed struct/function call)
- #91685 (Install llvm tools to sysroot when assembling local toolchain)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Remove the reg_thumb register class for asm! on ARM
Also restricts r8-r14 from being used on Thumb1 targets as per #90736.
cc ``@Lokathor``
r? ``@joshtriplett``
|
|
Implement concat_bytes!
This implements the unstable `concat_bytes!` macro, which has tracking issue #87555. It can be used like:
```rust
#![feature(concat_bytes)]
fn main() {
assert_eq!(concat_bytes!(), &[]);
assert_eq!(concat_bytes!(b'A', b"BC", [68, b'E', 70]), b"ABCDEF");
}
```
If strings or characters are used where byte strings or byte characters are required, it suggests adding a `b` prefix. If a number is used outside of an array it suggests arrayifying it. If a boolean is used it suggests replacing it with the numeric value of that number. Doubly nested arrays of bytes are disallowed.
|
|
Improve 'cannot contain emoji' error.
Before:
```
error: identifiers cannot contain emoji: `🦀`
--> src/main.rs:2:9
|
2 | let 🦀 = 1;
| ^^
```
After:
```
error: Ferris cannot be used as an identifier
--> src/main.rs:2:9
|
2 | let 🦀 = 1;
| ^^ help: try using their name instead: `ferris`
```
r? `@estebank`
|
|
|
|
Also restricts r8-r14 from being used on Thumb1 targets as per #90736.
|
|
Support AVR for inline asm!
A first pass at support for the AVR platform in inline `asm!`. Passes the initial compiler tests, have not yet done more complete verification.
In particular, the register classes could use a lot more fleshing out, this draft PR so far only includes the most basic.
cc `@Amanieu` `@dylanmckay`
|
|
Recommend fix `count()` -> `len()` on slices
Fixes #87302
|
|
Fixes #87302
|
|
The tracking issue for this is #87555.
|
|
|
|
std: Stabilize the `thread_local_const_init` feature
This commit is intended to follow the stabilization disposition of the
FCP that has now finished in #84223. This stabilizes the ability to flag
thread local initializers as `const` expressions which enables the macro
to generate more efficient code for accessing it, notably removing
runtime checks for initialization.
More information can also be found in #84223 as well as the tests where
the feature usage was removed in this PR.
Closes #84223
|
|
Keep spans for generics in `#[derive(_)]` desugaring
Keep the spans for generics coming from a `derive`d Item, so that errors
and suggestions have better detail.
Fix #84003.
|
|
|
|
|
|
Reintroduce `into_future` in `.await` desugaring
This is a reintroduction of the remaining parts from https://github.com/rust-lang/rust/pull/65244 that have not been relanded yet.
This isn't quite ready to merge yet. The last attempt was reverting due to performance regressions, so we need to make sure this does not introduce those issues again.
Issues #67644, #67982
/cc `@yoshuawuyts`
|