| Age | Commit message (Collapse) | Author | Lines |
|
|
|
|
|
|
|
- Move the type parameter from `encode` and `decode` methods to
the trait.
- Remove `UseSpecialized(En|De)codable` traits.
- Remove blanket impls for references.
- Add `RefDecodable` trait to allow deserializing to arena-allocated
references safely.
- Remove ability to (de)serialize HIR.
- Create proc-macros `(Ty)?(En|De)codable` to help implement these new
traits.
|
|
By moving `{known,used}_attrs` from `SessionGlobals` to `Session`. This
means they are accessed via the `Session`, rather than via TLS. A few
`Attr` methods and `librustc_ast` functions are now methods of
`Session`.
All of this required passing a `Session` to lots of functions that didn't
already have one. Some of these functions also had arguments removed, because
those arguments could be accessed directly via the `Session` argument.
`contains_feature_attr()` was dead, and is removed.
Some functions were moved from `librustc_ast` elsewhere because they now need
to access `Session`, which isn't available in that crate.
- `entry_point_type()` --> `librustc_builtin_macros`
- `global_allocator_spans()` --> `librustc_metadata`
- `is_proc_macro_attr()` --> `Session`
|
|
It's currently a `BTreeSet<Symbol>`, which is a strange type. The
`BTreeSet` suggests that element order is important, but `Symbol` is a
type whose ordering isn't useful to humans. The ordering of the
collection only manifests in an obscure error message ("no module named
`...`") that doesn't appear in any tests.
This commit changes the `Symbol` to a `String`, which is more
typical.
|
|
For consistency with `Attribute::has_name` which doesn't mark the attribute as used either.
Replace all uses of `check_name` with `has_name` outside of rustc
|
|
|
|
|
|
|
|
|
|
In various ways, such as changing functions to take a `Symbol` instead
of a `&str`.
|
|
Note that the output of `unpretty-debug.stdout` has changed. In that
test the hash values are normalized from a symbol numbers to small
numbers like "0#0" and "0#1". The increase in the number of static
symbols must have caused the original numbers to contain more digits,
resulting in different pretty-printing prior to normalization.
|
|
Other terms are more inclusive and precise.
|
|
They're unused now.
|
|
|
|
|
|
Because there is at most one file.
|
|
|
|
It's no longer necessary now that bitcode is embedded into object files.
This change meant that `WorkProductFileKind::Bytecode` is no longer
necessary, which means that type is no longer necessary, which allowed
several places in the code to become simpler.
|
|
Store LLVM bitcode in object files, not compressed
This commit is an attempted resurrection of #70458 where LLVM bitcode
emitted by rustc into rlibs is stored into object file sections rather
than in a separate file. The main rationale for doing this is that when
rustc emits bitcode it will no longer use a custom compression scheme
which makes it both easier to interoperate with existing tools and also
cuts down on compile time since this compression isn't happening.
The blocker for this in #70458 turned out to be that native linkers
didn't handle the new sections well, causing the sections to either
trigger bugs in the linker or actually end up in the final linked
artifact. This commit attempts to address these issues by ensuring that
native linkers ignore the new sections by inserting custom flags with
module-level inline assembly.
Note that this does not currently change the API of the compiler at all.
The pre-existing `-C bitcode-in-rlib` flag is co-opted to indicate
whether the bitcode should be present in the object file or not.
Finally, note that an important consequence of this commit, which is also
one of its primary purposes, is to enable rustc's `-Clto` bitcode
loading to load rlibs produced with `-Clinker-plugin-lto`. The goal here
is that when you're building with LTO Cargo will tell rustc to skip
codegen of all intermediate crates and only generate LLVM IR. Today
rustc will generate both object code and LLVM IR, but the object code is
later simply thrown away, wastefully.
|
|
This commit is an attempted resurrection of #70458 where LLVM bitcode
emitted by rustc into rlibs is stored into object file sections rather
than in a separate file. The main rationale for doing this is that when
rustc emits bitcode it will no longer use a custom compression scheme
which makes it both easier to interoperate with existing tools and also
cuts down on compile time since this compression isn't happening.
The blocker for this in #70458 turned out to be that native linkers
didn't handle the new sections well, causing the sections to either
trigger bugs in the linker or actually end up in the final linked
artifact. This commit attempts to address these issues by ensuring that
native linkers ignore the new sections by inserting custom flags with
module-level inline assembly.
Note that this does not currently change the API of the compiler at all.
The pre-existing `-C bitcode-in-rlib` flag is co-opted to indicate
whether the bitcode should be present in the object file or not.
Finally, note that an important consequence of this commit, which is also
one of its primary purposes, is to enable rustc's `-Clto` bitcode
loading to load rlibs produced with `-Clinker-plugin-lto`. The goal here
is that when you're building with LTO Cargo will tell rustc to skip
codegen of all intermediate crates and only generate LLVM IR. Today
rustc will generate both object code and LLVM IR, but the object code is
later simply thrown away, wastefully.
|
|
|
|
|
|
|
|
|
|
r=michaelwoerister
Clean up debugging options
I found various sub-optimal things when I was looking at option handling.
|
|
Because it uses `parse_bool` and defaults to true, it is actually
impossible to set it to false. And it hasn't been experimental for some
time now.
|
|
|
|
|
|
hir: replace "items" terminology with "nodes" where appropriate.
The newly added `HirOwnerItems` confused me before I realized that "items" there actually referred to HIR nodes, not `hir:Item` or "item-like" (which we should IMO replace with "owner").
I suspect the naming had something to do with `ItemLocalId`'s use of "item".
That is, `ItemLocalId` could be interpreted to mean one of two things:
* `IntraItemNodeId` i.e. `IntraOwnerNodeId`
* this is IMO correct, and I'd even like to rename it, but I didn't want to throw that into this PR
* `IntraOwnerItemId`
* this is what `HirOwnerItems` would seem to imply
r? @Zoxc cc @michaelwoerister @nikomatsakis
|
|
|
|
|
|
Remove some imports to the rustc crate
- When we have `NestedVisitorMap::None`, we use `type Map = dyn intravisit::Map<'v>;` instead of the actual map. This doesn't actually result in dynamic dispatch (in the future we may want to use an associated type default to simplify the code).
- Use `rustc_session::` imports instead of `rustc::{session, lint}`.
r? @Zoxc
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
remove lifetimes that can be elided (clippy::needless_lifetimes)
|
|
|
|
Rename rustc guide
This is in preparation for https://github.com/rust-lang/rustc-guide/issues/470
Needs to be merged after we actually rename the guide.
Have used this to rename:
`git grep -l 'rustc_guide' | xargs sed -i 's/rustc_guide/rustc_dev_guide/g'`
`git grep -l 'rustc-guide' | xargs sed -i 's/rustc-guide/rustc-dev-guide/g'`
`git grep -l 'rustc guide' | xargs sed -i 's/rustc guide/rustc dev guide/g'`
|
|
Rename DefKind::Method and TraitItemKind::Method
r? @eddyb, @Centril, or @matthewjasper
cc #69498 #60163
|
|
|
|
|
|
|
|
|
|
|