| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
* Adds either an MD5 or SHA1 hash to the debug info.
* Adds new unstable option `-Z src-hash-algorithm` to control the hashing algorithm.
|
|
|
|
asm! is left as a wrapper around llvm_asm! to maintain compatibility.
|
|
|
|
They used to be covered by `optin_builtin_traits` but negative impls
are now applicable to all traits, not just auto traits.
This also adds docs in the unstable book for the current state of auto traits.
|
|
|
|
Split long derive lists into two derive attributes.
|
|
pnkfelix:issue-68808-dont-turn-dummy-spans-into-invalid-lines, r=estebank
Revised span-to-lines conversion to produce an empty vec on DUMMY_SP.
This required revising some of the client code to stop relying on the returned set of lines being non-empty.
Fix #68808
|
|
Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>
|
|
|
|
more clippy fixes
* remove unused unit values (clippy::unused_unit)
* make some let-if-bindings more idiomatic (clippy::useless_let_if_seq)
* clarify when we pass () to functions (clippy::unit_arg)
* don't redundantly repeat field names (clippy::redundant_field_names)
* remove redundant returns (clippy::needless_return)
* use let instead of match for matches with single bindings (clippy::match_single_binding)
* don't convert results to options just for matching (clippy::if_let_some_result)
|
|
parse/lexer: support `StringReader::retokenize` called on external files.
This ~~should theoretically~~ fixes #69933, ~~but I'm not sure what the best way to test it is~~.
**EDIT**: see https://github.com/rust-lang/rust/issues/69933#issuecomment-602019598.
r? @petrochenkov cc @Xanewok @staktrace
|
|
|
|
add #[rustc_layout(debug)]
@eddyb recently told me about the `#[rustc_layout]` attribute, and I think it would be very useful if it could be used to print all the layout information Rust has about a type. When working with layouts (e.g. in Miri), it is often not clear how certain surface language features get represented internally. I have some awful hacks locally to be able to dump this debug information; with this attribute I could get it on the playground which is so much better. :)
|
|
more clippy fixes
* remove redundant returns (clippy::needless_return)
* remove redundant import (clippy::single_component_path_imports)
* remove redundant format!() call (clippy::useless_format)
* don't use ok() before calling expect() (clippy::ok_expect)
|
|
Use generator resume arguments in the async/await lowering
This removes the TLS requirement from async/await and enables it in `#![no_std]` crates.
Closes https://github.com/rust-lang/rust/issues/56974
I'm not confident the HIR lowering is completely correct, there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.
|
|
|
|
This required revising some of the client code to stop relying on
the returned set of lines being non-empty.
|
|
|
|
|
|
|
|
|
|
LocalDefId::from_def_id.
|
|
|
|
Previously, metadata encoding used DUMMY_SP to represent any spans that
referenced an 'imported' SourceFile - e.g. a SourceFile from an upstream
dependency. These leads to sub-optimal error messages in certain cases
(see the included test).
This PR changes how we encode and decode spans in crate metadata. We
encode spans in one of two ways:
* 'Local' spans, which reference non-imported SourceFiles, are encoded
exactly as before.
* 'Foreign' spans, which reference imported SourceFiles, are encoded
with the CrateNum of their 'originating' crate. Additionally, their
'lo' and 'high' values are rebased on top of the 'originating' crate,
which allows them to be used with the SourceMap data encoded for that
crate.
The `ExternalSource` enum is renamed to `ExternalSourceKind`. There is
now a struct called `ExternalSource`, which holds an
`ExternalSourceKind` along with the original line number information for
the file. This is used during `Span` serialization to rebase spans onto
their 'owning' crate.
|
|
Make methods declared by `newtype_index` macro `const`
Crates that use the macro to define an `Idx` type need to enable `#![feature(const_if_match, const_panic)]`.
|
|
|
|
|
|
|
|
Make macro metavars respect (non-)hygiene
This makes them more consistent with other name resolution while not breaking any code on crater.
|
|
expand: Implement something similar to `#[cfg(accessible(path))]`
cc https://github.com/rust-lang/rust/issues/64797
The feature is implemented as a `#[cfg_accessible(path)]` attribute macro rather than as `#[cfg(accessible(path))]` because it needs to wait until `path` becomes resolvable, and `cfg` cannot wait, but macros can wait.
Later we can think about desugaring or not desugaring `#[cfg(accessible(path))]` into `#[cfg_accessible(path)]`.
This implementation is also incomplete in the sense that it never returns "false" from `cfg_accessible(path)`, it requires some tweaks to resolve, which is not quite ready to answer queries like this during early resolution.
However, the most important part of this PR is not `cfg_accessible` itself, but expansion infrastructure for retrying expansions.
Before this PR we could say "we cannot resolve this macro path, let's try it later", with this PR we can say "we cannot expand this macro, let's try it later" as well.
This is a pre-requisite for
- turning `#[derive(...)]` into a regular attribute macro,
- properly supporting eager expansion for macros that cannot yet be resolved like
```
fn main() {
println!(not_available_yet!());
}
macro_rules! make_available {
() => { #[macro_export] macro_rules! not_available_yet { () => { "Hello world!" } }}
}
make_available!();
```
|
|
Implement a feature for a sound specialization subset
This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use.
The plan is to then:
* Update `libcore` and `liballoc` to compile with `min_specialization`.
* Add a lint to forbid use of `feature(specialization)` (and other unsound, type system extending features) in the standard library.
* Fix the soundness issues around `specialization`.
* Remove `min_specialization`
The rest of this is an overview from a comment in this PR
## Basic approach
To enforce this requirement on specializations we take the following approach:
1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`.
2. Check for any direct use of `'static` in the substs of `impl2`.
3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate.
4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs).
## Example
Suppose we have the following always applicable impl:
```rust
impl<T> SpecExtend<T> for std::vec::IntoIter<T> { /* specialized impl */ }
impl<T, I: Iterator<Item=T>> SpecExtend<T> for I { /* default impl */ }
```
We get that the subst for `impl2` are `[T, std::vec::IntoIter<T>]`. `T` is constrained to be `<I as Iterator>::Item`, so we check only `std::vec::IntoIter<T>` for repeated parameters, which it doesn't have. The predicates of `impl1` are only `T: Sized`, which is also a predicate of impl2`. So this specialization is sound.
## Extensions
Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits.
### rustc_specialization_trait
If a trait is always applicable, then it's sound to specialize on it. We check trait is always applicable in the same way as impls, except that step 4 is now "all predicates on `impl1` are always applicable". We require that `specialization` or `min_specialization` is enabled to implement these traits.
### rustc_specialization_marker
There are also some specialization on traits with no methods, including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can.
r? @nikomatsakis
cc #31844 #67194
|
|
|
|
resolve/hygiene: `macro_rules` are not "legacy"
The "modern" vs "legacy" naming was introduced by jseyfried during initial implementation of macros 2.0.
At this point it's clear that `macro_rules` are not going anywhere and won't be deprecated in the near future.
So this PR changes the naming "legacy" (when it implies "macro_rules") to "macro_rules".
This should also help people reading this code because it's wasn't obvious that "legacy" actually meant "macro_rules" in these contexts.
The most contentious renaming here is probably
```
fn modern -> fn normalize_to_macros_2_0
fn modern_and_legacy -> fn normalize_to_macro_rules
```
Other alternatives that I could think of are `normalize_to_opaque`/`normalize_to_semitransparent`, or `strip_non_opaque`/`strip_transparent`, but they seemed less intuitive.
The documentation to these functions can be found in `symbol.rs`.
r? @matthewjasper
|
|
`modern_and_legacy` -> `normalize_to_macro_rules`
|
|
|
|
|
|
Optimize catch_unwind to match C++ try/catch
This refactors the implementation of catching unwinds to allow LLVM to inline the "try" closure directly into the happy path, avoiding indirection. This means that the catch_unwind implementation is (after this PR) zero-cost unless a panic is thrown.
https://rust.godbolt.org/z/cZcUSB is an example of the current codegen in a simple case. Notably, the codegen is *exactly the same* if `-Cpanic=abort` is passed, which is clearly not great.
This PR, on the other hand, generates the following assembly:
```asm
# -Cpanic=unwind:
push rbx
mov ebx,0x2a
call QWORD PTR [rip+0x1c53c] # <happy>
mov eax,ebx
pop rbx
ret
mov rdi,rax
call QWORD PTR [rip+0x1c537] # cleanup function call
call QWORD PTR [rip+0x1c539] # <unfortunate>
mov ebx,0xd
mov eax,ebx
pop rbx
ret
# -Cpanic=abort:
push rax
call QWORD PTR [rip+0x20a1] # <happy>
mov eax,0x2a
pop rcx
ret
```
Fixes #64224, and resolves #64222.
|
|
fix more clippy findings
* reduce references on match patterns (clippy::match_ref_pats)
* Use writeln!(fmt, "word") instead of write!(fmt, "word\n") (clippy::write_with_newline)
* libtest: remove redundant argument to writeln!() (clippy::writeln_empty_string)
* remove unneeded mutable references (cippy::unnecessary_mut_passed)
* libtest: declare variables as floats instead of casting them (clippy::unnecessary_cast)
* rustdoc: remove redundant static lifetimes (clippy::redundant_static_lifetimes)
* call .as_deref() instead of .as_ref().map(Deref::deref) (clippy::option_as_ref_deref)
* iterate over a maps values directly. (clippy::for_kv_map)
* rustdoc: simplify boolean condition (clippy::nonminimal_bool)
* Use ?-operator in more places (clippy::question_mark, had some false negatives fixed recently)
* rustdoc: Use .any(p) instead of find(p).is_some(). (clippy::search_is_some)
* rustdoc: don't call into_iter() on iterator. (clippy::identity_conversion)
|
|
miri: ICE on invalid terminators
We've run a lot of MIR in Miri (including some generators) and never seen these.
@tmandry is it correct that `Yield` and `GeneratorDrop` get lowered away?
@eddyb @oli-obk what's with this `Abort` that does not seem to ever actually exist? Codegen *does* seem to handle it, so I wonder why Miri can get away without that. In fact, codegen handles it twice:
https://github.com/rust-lang/rust/blob/1d5241c96208ca7d925442b1a5fa45ad18717a6f/src/librustc_codegen_ssa/mir/block.rs#L796
https://github.com/rust-lang/rust/blob/1d5241c96208ca7d925442b1a5fa45ad18717a6f/src/librustc_codegen_ssa/mir/mod.rs#L296
|
|
Improve expression & attribute parsing
This PR includes misc improvements to expression and attribute parsing.
1. Some code simplifications
2. Better recovery for various block forms, e.g. `loop statements }` (missing `{` after `loop`). (See e.g., `block-no-opening-brace.rs` among others for examples.)
3. Added recovery for e.g., `unsafe $b` where `$b` refers to a `block` macro fragment. (See `bad-interpolated-block.rs` for examples.)
4. ^--- These are done so that code sharing in block parsing is increased.
5. Added recovery for e.g., `'label: loop { ... }` (See `labeled-no-colon-expr.rs`.)
6. Added recovery for e.g., `&'lifetime expr` (See `regions-out-of-scope-slice.rs`.)
7. Added recovery for e.g., `fn foo() = expr;` (See `fn-body-eq-expr-semi.rs`.)
8. Simplified attribute parsing code & slightly improved diagnostics.
9. Added recovery for e.g., `Box<('a) + Trait>`.
10. Added recovery for e.g, `if true #[attr] {} else #[attr] {} else #[attr] if true {}`.
r? @estebank
|
|
make `mem::discriminant` const
implements #69821, which could be used as a tracking issue for `const_discriminant`.
Should this be added to the meta tracking issue #57563?
@Lokathor
|
|
Cleanup `rmeta::MacroDef`
Avoid using rountrip parsing in the encoder and in `fn load_macro_untracked`.
The main reason I was interested in this was to remove `rustc_parse` as a dependency of `rustc_metadata` but it seems like this had other benefits as well.
Fixes #49511.
r? @eddyb
cc @matthewjasper @estebank @petrochenkov
|
|
|
|
This removes a hack from `load_macro_untracked` in which parsing is used.
|
|
Remove spotlight
I had a few comments saying that this feature was at best misunderstood or not even used so I decided to organize a poll about on [twitter](https://twitter.com/imperioworld_/status/1232769353503956994). After 87 votes, the result is very clear: it's not useful. Considering the amount of code we have just to run it, I think it's definitely worth it to remove it.
r? @kinnison
cc @ollie27
|
|
|
|
|
|
|
