exclude `#![no_builtins]` crates from LTO
this prevents intrinsics like `memcpy` from being mis-optimized to
infinite recursive calls when LTO is used.
fixes#31544closes#35540
---
r? @alexcrichton
cc @Amanieu
The 'cfg' in the Options struct is only the commandline-specified
subset of the crate configuration and it's almost always wrong to
read that instead of the CrateConfig in HIR crate node.
Commandline arguments influence whether incremental compilation
can use its compilation cache and thus their changes relative to
previous compilation sessions need to be taking into account. This
commit makes sure that one has to specify for every commandline
argument whether it influences incremental compilation or not.
We don't actually officially support this at all, and the execution engine
support in LLVM we've had to gut as it's not compiling on MinGW, so just delete
this test for now.
This checks the `previous_work_products` data from the dep-graph and
tries to simply copy a `.o` file if possible. We also add new
work-products into the dep-graph, and create edges to/from the dep-node
for a work-product.
fix built-in target detection
previously the logic was accepting wrong triples (like
`x86_64_unknown-linux-musl`) as valid ones (like `x86_64-unknown-linux-musl`) if
they contained an underscore instead of a dash.
fixes#33329
---
r? @brson
I wanted to use a compile-fail test at first. But, you can't pass an extra `--target` flag to `rustc` for those because they already call `rustc --target $HOST` so you get a `error: Option 'target' given more than once.`. The run-make test used here works fine though.
Remove redundant `CompileController` entry points
Remove the `after_expand` and `after_write_deps` `CompileController` entry points.
The only things that separate these entry points from `after_hir_lowering` are dep-info generation and HIR map construction, neither of which is computationally intensive or has the potential to error.
r? @nrc
rustbuild: Touch up some test suites
This adds in some missing test suites, primarily a few pretty suites. It also starts optimizing tests by default as the current test suite does, but also recognizes `--disable-optimize-tests`.
Currently the optimization of tests isn't recognized by crate tests because Cargo doesn't support the ability to compile an unoptimized test suite against an optimized library. Perhaps a feature to add, though!
Originally fixed in #29961 the bug was unfortunately still present in the face
of crates using `#[macro_use]`. This commit refactors for the two code paths to
share common logic to ensure that they both pick up the same bug fix.
Closes#33762
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/1510Closes#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/1510Closes#33132
Perform name resolution before and during ast->hir lowering
This PR performs name resolution before and during ast->hir lowering instead of in phase 3.
r? @nrc
Overhaul borrowck error messages and compiler error formatting generally
This is a major overhaul of how the compiler reports errors. The primary goal is to be able to give many spans within the same overall context, such as this:
```
./borrow-errors.rs:73:17: 73:20: error: cannot borrow `*vec` as immutable because previous closure requires unique access [E0501]
70 let append = |e| {
~~~ closure construction occurs here
71 vec.push(e)
~~~ previous borrow occurs due to use of `vec` in closure
72 };
73 let data = &vec[3];
~~~ borrow occurs here
74 }
~ borrow from closure ends here
```
However, in the process we made a number of other changes:
- Removed the repetitive filenames from snippets and just give the line number.
- Color the line numbers blue so they "fade away"
- Remove the file name and line number from the error code suggestions since they don't seem to fit anymore. (This should probably happen in more places, like existing notes.)
- Newlines in between errors to help group them better.
This PR is not quite ready to land, but we thought it made sense to stop here and get some feedback from people at large. It'd be great if people can check out the branch and play with it. We'd be especially interested in hearing about cases that don't look good with the new formatting (I suspect they exist).
Here is a checklist of some pending work items for this PR. Some of them may be best left for follow-up PRs:
- [x] Accommodate multiple files in a `MultiSpan` (this should be easy)
- In this case, we want to print filenames though.
- [x] Remove duplicate E0500 code.
- [x] Make the header message bold, rather than current hack that makes all errors/warnings bold
- [x] Update warning text color (yellow is hard to read w/ a white background)
Moved numerous follow-ups to: https://github.com/rust-lang/rust/issues/33240
Joint work with @jonathandturner.
Fixes https://github.com/rust-lang/rust/issues/3533
previously the logic was accepting wrong triples (like
`x86_64_unknown-linux-musl`) as valid ones (like `x86_64-unknown-linux-musl`) if
they contained an underscore instead of a dash.
fixes#33329
Add CodeGen options to optimize for size.
Add CodeGen options to annotate functions with the attributes OptimizeSize and/or MinSize used by LLVM to reduce .text size.
Closes#32296
test: Move run-make tests into compiletest
Forcing them to be embedded in makefiles precludes being able to run them in
rustbuild, and adding them to compiletest gives us a great way to leverage
future enhancements to our "all encompassing test suite runner" as well as just
moving more things into Rust.
All tests are still Makefile-based in the sense that they rely on `make` being
available to run them, but there's no longer any Makefile-trickery to run them
and rustbuild can now run them out of the box as well.
Forcing them to be embedded in makefiles precludes being able to run them in
rustbuild, and adding them to compiletest gives us a great way to leverage
future enhancements to our "all encompassing test suite runner" as well as just
moving more things into Rust.
All tests are still Makefile-based in the sense that they rely on `make` being
available to run them, but there's no longer any Makefile-trickery to run them
and rustbuild can now run them out of the box as well.
