| Age | Commit message (Collapse) | Author | Lines |
|
|
|
Internal docs
This PR is a rebase of #30621. That PR can be closed.
CC @ticki @Aatch @cyplo
|
|
Fix some code layout, remove some unnecessary returns, fix typos,
punctuation, and comment consistency.
|
|
Preserve span when lowering ExprKind::Paren
Fix #33681.
|
|
rustc: Add a new crate type, cdylib
This commit is an implementation of [RFC 1510] which adds a new crate type,
`cdylib`, to the compiler. This new crate type differs from the existing `dylib`
crate type in a few key ways:
* No metadata is present in the final artifact
* Symbol visibility rules are the same as executables, that is only reachable
`extern` functions are visible symbols
* LTO is allowed
* All libraries are always linked statically
This commit is relatively simple by just plubming the compiler with another
crate type which takes different branches here and there. The only major change
is an implementation of the `Linker::export_symbols` function on Unix which now
actually does something. This helps restrict the public symbols from a cdylib on
Unix.
With this PR a "hello world" `cdylib` is 7.2K while the same `dylib` is 2.4MB,
which is some nice size savings!
[RFC 1510]: https://github.com/rust-lang/rfcs/pull/1510
Closes #33132
|
|
This commit is an implementation of [RFC 1510] which adds a new crate type,
`cdylib`, to the compiler. This new crate type differs from the existing `dylib`
crate type in a few key ways:
* No metadata is present in the final artifact
* Symbol visibility rules are the same as executables, that is only reachable
`extern` functions are visible symbols
* LTO is allowed
* All libraries are always linked statically
This commit is relatively simple by just plubming the compiler with another
crate type which takes different branches here and there. The only major change
is an implementation of the `Linker::export_symbols` function on Unix which now
actually does something. This helps restrict the public symbols from a cdylib on
Unix.
With this PR a "hello world" `cdylib` is 7.2K while the same `dylib` is 2.4MB,
which is some nice size savings!
[RFC 1510]: https://github.com/rust-lang/rfcs/pull/1510
Closes #33132
|
|
implement fuzzy matching in on_unimplemented
Fixes #31062
r? @nikomatsakis
|
|
Fix for old school error issues, improvements to new school
This PR:
* Fixes some old school error issues, specifically #33559, #33543, #33366
* Improves wording borrowck errors with match patterns
* De-emphasize multi-line spans, so we don't color the single source character when we're trying to say "span starts here"
* Rollup of #33392 (which should help fix #33390)
r? @nikomatsakis
|
|
|
|
track incr. comp. dependencies across crates
This PR refactors the compiler's incremental compilation hashing so that it can track dependencies across crates. The main bits are:
- computing a hash representing the metadata for an item we are emitting
- we do this by making `MetaData(X)` be the current task while computing metadata for an item
- this naturally registers reads from any tables and things that we read for that purpose
- we can then hash all the inputs to those tables
- tracking when we access metadata
- we do this by registering a read of `MetaData(X)` for each foreign item `X` whose metadata we read
- hashing metadata from foreign items
- we do this by loading up metadata from a file in the incr. comp. directory
- if there is no file, we use the SVH for the entire crate
There is one very simple test only at this point. The next PR will be focused on expanding out the tests.
Note that this is based on top of https://github.com/rust-lang/rust/pull/33228
r? @michaelwoerister
|
|
|
|
In MSVC (at least), linking requires accessing metadata, which generates
reads.
|
|
|
|
|
|
|
|
For external crates, we must build up a map that goes from
the DefKey to the DefIndex. We do this by iterating over each
index that is found in the metadata and loading the associated
DefKey.
|
|
Create some re-usable filtering subroutines.
|
|
We used to store a u64 converted to a String for some reason. Now we
don't.
|
|
Generate a second hash file that contains the metadata for an X node.
|
|
This lets us determine what was used to construct the metadata.
Conflicts:
src/librustc_metadata/encoder.rs
|
|
Conflicts:
src/librustc_metadata/csearch.rs
|
|
This got removed at some point, it seems.
|
|
This is a [breaking-change] for plugin authors.
You must now create a dep-graph earlier.
|
|
This is a [breaking-change] for plugins, which
ought by now to have stopped relying on downcasting.
|
|
|
|
Rollup of 5 pull requests
- Successful merges: #33656, #33666, #33673, #33675, #33695
- Failed merges:
|
|
introduce a specializes cache
This query is frequently used during trait selection and caching the
result can be a reasonable performance win.
The one case I examined thus far was the mrusty package (v0.5.1), where I saw an improvement in "typeck item bodies" from ~8.3s to ~1.9s.
r? @aturon
|
|
Remove hir::Ident
Now when name resolution is done on AST, `hir::Ident` is no longer necessary.
See https://github.com/rust-lang/rust/pull/30145 for more details.
r? @nrc
|
|
nikomatsakis:issue-32330-lbr-in-return-type-warning-2, r=aturon
Warnings for issue #32330
This is an extension of the previous PR that issues warnings in more situations than before. It does not handle *all* cases of #32330 but I believe it issues warnings for all cases I've seen in practice.
Before merging I'd like to address:
- open a good issue explaining the problem and how to fix it (I have a [draft writeup][])
- work on the error message, which I think is not as clear as it could/should be (suggestions welcome)
r? @aturon
[draft writeup]: https://gist.github.com/nikomatsakis/631ec8b4af9a18b5d062d9d9b7d3d967
|
|
|
|
This is a step towards fixing #32330. The full fix would be a breaking
change, so we begin by issuing warnings for scenarios that will break.
|
|
We ought not to be affecting inference state when assembling candidates,
so invoke select inside of a probe.
|
|
This query is frequently used during trait selection and caching the
result can be a reasonable performance win.
|
|
|
|
|
|
Replace the obligation forest with a graph
In the presence of caching, arbitrary nodes in the obligation forest can be merged, which makes it a general graph. Handle it as such, using cycle-detection algorithms in the processing.
I should do performance measurements sometime.
This was pretty much written as a proof-of-concept. Please help me write this in a less-ugly way. I should also add comments explaining what is going on.
r? @nikomatsakis
|
|
|
|
|
|
Do not rename invalid identifiers, they stop being invalid after renaming
|
|
|
|
diagnostics: Fix minor typo in E0038
|
|
Remove ExplicitSelf from HIR
`self` argument is already kept in the argument list and can be retrieved from there if necessary, so there's no need for the duplication.
The same changes can be applied to AST, I'll make them in the next breaking batch.
The first commit also improves parsing of method declarations and fixes https://github.com/rust-lang/rust/issues/33413.
r? @eddyb
|
|
Batch of improvements to errors for new error format
This is a batch of improvements to existing errors to help get the most out of the new error format.
* Added labels to primary spans (^^^) for a set of errors that didn't currently have them
* Highlight the source blue under the secondary notes for better readability
* Move some of the "Note:" into secondary spans+labels
* Fix span_label to take &mut instead, which makes it work the same as other methods in that set
|
|
|
|
|
|
Plumb inference obligations through selection, take 2
Using a `SnapshotVec` and dumping inferred obligations into `Vtable` variants.
r? @nikomatsakis
|
|
Support references to outer type params for assoc consts
Fixes #28809
r? @eddyb
|
|
Remove unification despite ambiguity in projection
Turns out that closures aren't explicitly considered in `project.rs`, so the ambiguity handling w.r.t. closures can just be removed as the change done in `select.rs` covers it.
r? @nikomatsakis
|
|
Refactor code around LocalCrateReader.
|
|
|