| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
This commit starts passing the `--whole-archive` flag (`-force_load` on OSX) to
the linker when linking rlibs into dylibs. The primary purpose of this commit is
to ensure that the linker doesn't strip out objects from an archive when
creating a dynamic library. Information on how this can go wrong can be found in
issues #14344 and #25185.
The unfortunate part about passing this flag to the linker is that we have to
preprocess the rlib to remove the metadata and compressed bytecode found within.
This means that creating a dylib will now take longer to link as we've got to
copy around the input rlibs to a temporary location, modify them, and then
invoke the linker. This isn't done for executables, however, so the "hello
world" compile time is not affected.
This fix was instigated because of the previous commit where rlibs may not
contain multiple object files instead of one due to codegen units being greater
than one. That change prevented the main distribution from being compiled with
more than one codegen-unit and this commit fixes that.
Closes #14344
Closes #25185
|
|
|
|
|
|
|
|
It now says '#[feature] may not be used on the stable release channel'.
I had to convert this error from a lint to a normal compiler error.
I left the lint previously-used for this in place since removing it is
a breaking change. It will just go unused until the end of time.
Fixes #24125
|
|
Environment variables are global state so this can lead to surprising results if
the driver is called in a multithreaded environment (e.g. doctests). There
shouldn't be any memory corruption that's possible, but a lot of the bots have
been failing because they can't find `cc` or `gcc` in the path during doctests,
and I highly suspect that it is due to the compiler modifying `PATH` in a
multithreaded fashion.
This commit moves the logic for appending to `PATH` to only affect the child
process instead of also affecting the parent, at least for the linking stage.
When loading dynamic libraries the compiler still modifies `PATH` on Windows,
but this may be more difficult to fix than spawning off a new process.
|
|
It now says '#[feature] may not be used on the stable release channel'.
I had to convert this error from a lint to a normal compiler error.
I left the lint previously-used for this in place since removing it is
a breaking change. It will just go unused until the end of time.
Fixes #24125
|
|
|
|
|
|
|
|
Environment variables are global state so this can lead to surprising results if
the driver is called in a multithreaded environment (e.g. doctests). There
shouldn't be any memory corruption that's possible, but a lot of the bots have
been failing because they can't find `cc` or `gcc` in the path during doctests,
and I highly suspect that it is due to the compiler modifying `PATH` in a
multithreaded fashion.
This commit moves the logic for appending to `PATH` to only affect the child
process instead of also affecting the parent, at least for the linking stage.
When loading dynamic libraries the compiler still modifies `PATH` on Windows,
but this may be more difficult to fix than spawning off a new process.
|
|
`driver::build_output_filenames` calls `file_stem` on a PathBuf obtained from the output file compiler flag. It's possible to pass the empty string to this compiler flag. When file_stem is called on an empty Path, it returns None, which is unwrapped and the compiler panics.
This change modifies the `unwrap` to an `unwrap_or` so that the empty string is passed through the compilation pipeline until it reaches `trans::back::write_output_file`, which will emit an appropriate error.
Instead of panicking, the error that is emitted now is:
```
$ rustc -o "" thing.rs
error: could not write output to : No such file or directory
```
The `:` is a little strange, but it /is/ reporting the filename (the empty string) correctly, I suppose. Both gcc and clang hand the output file to ld, which emits a similar error message when faced with the empty string as an output file:
```
$ clang -o "" thing.c
ld: can't open output file for writing: , errno=2 for architecture x86_64
```
This PR also adds a test for this, in `run-make`. This fixes issue #26092.
|
|
|
|
file_stem
|
|
|
|
|
|
by 90%.
|
|
This lets plugin authors opt attributes out of the `custom_attribute`
and `unused_attribute` checks.
cc @thepowersgang
|
|
Stripping unconfigured items prior to collecting crate metadata means we
can say things like `#![cfg_attr(foo, crate_type="lib")]`.
Fixes #25347.
|
|
Fixes the problem in #16974 with unhelpful error messages when accidentally using the wrong syntax for the `crate_type="lib"` attribute. The attribute syntax error now shows up instead of "main function not found".
|
|
If the user intended to set the crate_type to "lib" but accidentally used
incorrect syntax such as `#![crate_type(lib)]`, the compilation would fail with
"main function not found". This made it hard to locate the source of the
problem, since the failure would cause the warning about the incorrect
attribute not to be shown.
|
|
This lets plugin authors opt attributes out of the `custom_attribute`
and `unused_attribute` checks.
|
|
Turns out that a verbatim path was leaking through to gcc via the PATH
environment variable (pointing to the bundled gcc provided by the main
distribution) which was wreaking havoc when gcc itself was run. The fix here is
to just stop passing verbatim paths down by adding more liberal uses of
`fix_windows_verbatim_for_gcc`.
Closes #25072
|
|
|
|
This is the second attempt at turning the trace_macros macro into a compiler flag.
See #22619
|
|
closes #24434
This PR changes executes `syntax::config::strip_unconfigured_items` before `syntax::feature_gate::check_crate_macros(sess.codemap()`. As far as I know, `strip_unconfigured_items` should be independent of `check_crate_macros`.
|
|
`s/(?<!\{ self)(?<=\.)len\(\) == 0/is_empty()/g`
|
|
closes #24434
|
|
|
|
Fixes #22619
|
|
|
|
Pretty much what it says on the tin.
|
|
|
|
This commit removes all parsing, resolve, and compiler support for the old and
long-deprecated int/uint types.
|
|
This commit:
* Introduces `std::convert`, providing an implementation of
RFC 529.
* Deprecates the `AsPath`, `AsOsStr`, and `IntoBytes` traits, all
in favor of the corresponding generic conversion traits.
Consequently, various IO APIs now take `AsRef<Path>` rather than
`AsPath`, and so on. Since the types provided by `std` implement both
traits, this should cause relatively little breakage.
* Deprecates many `from_foo` constructors in favor of `from`.
* Changes `PathBuf::new` to take no argument (creating an empty buffer,
as per convention). The previous behavior is now available as
`PathBuf::from`.
* De-stabilizes `IntoCow`. It's not clear whether we need this separate trait.
Closes #22751
Closes #14433
[breaking-change]
|
|
|
|
rustc will ICE if you specify an outfile path that is bare without a
directory. As a workaround, before this -o ./foo will work
|
|
Closes #23089
|
|
Closes #23089
|
|
This ensures we catch everything; previously, an unknown attribute
inserted by #[cfg_attr(...)] in a macro expansion would not be detected.
|
|
This commit deprecates the majority of std::old_io::fs in favor of std::fs and
its new functionality. Some functions remain non-deprecated but are now behind a
feature gate called `old_fs`. These functions will be deprecated once
suitable replacements have been implemented.
The compiler has been migrated to new `std::fs` and `std::path` APIs where
appropriate as part of this change.
|
|
This commit moves `std::env` away from the `std::old_io` error type as well as
the `std::old_path` module. Methods returning an error now return `io::Error`
and methods consuming or returning paths use `std::path` instead of
`std::old_path`. This commit does not yet mark these APIs as `#[stable]`.
This commit also migrates `std::old_io::TempDir` to `std::fs::TempDir` with
essentially the exact same API. This type was added to interoperate with the new
path API and has its own `tempdir` feature.
Finally, this commit reverts the deprecation of `std::os` APIs returning the old
path API types. This deprecation can come back once the entire `std::old_path`
module is deprecated.
[breaking-change]
|
|
This commit moves `std::env` away from the `std::old_io` error type as well as
the `std::old_path` module. Methods returning an error now return `io::Error`
and methods consuming or returning paths use `std::path` instead of
`std::old_path`. This commit does not yet mark these APIs as `#[stable]`.
This commit also migrates `std::old_io::TempDir` to `std::fs::TempDir` with
essentially the exact same API. This type was added to interoperate with the new
path API and has its own `tempdir` feature.
Finally, this commit reverts the deprecation of `std::os` APIs returning the old
path API types. This deprecation can come back once the entire `std::old_path`
module is deprecated.
[breaking-change]
|
|
|
|
|
|
|
|
r? @aturon
|
|
post-analysis callback. We can also pass this to post-write-deps callback.
|
|
where possible.
|
