At the moment, this code is looking at the stat output to determine if a
temp directory can be written to. However, just because the stat bits
say that a directory is writable, does not make it so; and, likewise,
the operating system may in fact grant access to paths that the stat
bits and process UID say should be inaccessible.
These systems include:
* Posix ACL's
* Linux's capabilities like CAP_DAC_OVERRIDE
* Linux Security Modules like SELinux or AppArmor
* Syscall filters like Linux's seccomp
* Granular capability systems like FreeBSD's Capsicum
* OpenBSD's pledge and unveil
* Windows too has a rich ACL system for controlling filesystem access
The best thing to do is simply to try and access the path with
`File.writable?` and let the operating system tell us if the path can be
accessed.
warning
(https://github.com/ruby/irb/pull/1019)
* Suppress "literal string will be frozen in the future" warning
Before change:
```console
$ ruby -W -I lib -e 'require "irb"; IRB.setup(nil); IRB::Irb.new.build_statement("1 + 2")'
/Users/zzz/src/github.com/ruby/irb/lib/irb.rb:1135: warning: literal string will be frozen in the future
```
After change:
```console
$ ruby -W -I lib -e 'require "irb"; IRB.setup(nil); IRB::Irb.new.build_statement("1 + 2")'
```
* Making build_statement not modify the given argument
Because improves readability and code quality.
Co-authored-by: tomoya ishida <tomoyapenguin@gmail.com>
---------
3da04b9786
Co-authored-by: tomoya ishida <tomoyapenguin@gmail.com>
`--embed-mixins`
(https://github.com/ruby/rdoc/pull/842)
* Embed mixed-in methods and constants with `--embed-mixins`
When `--embed-mixins` option is set:
- methods from an `extend`ed module are documented as singleton methods
- attrs from an `extend`ed module are documented as class attributes
- methods from an `include`ed module are documented as instance methods
- attrs from an `include`ed module are documented as instance attributes
- constants from an `include`ed module are documented
Sections are created when needed, and Darkfish's template annotates
each of these mixed-in CodeObjects. We also respect the mixin methods'
visibility.
This feature is inspired by Yard's option of the same name.
* Add comment to document why we set object visibility
Co-authored-by: Stan Lo <stan001212@gmail.com>
* Add the mixin_from attribute to CodeObject's initializer
* Add test coverage for private mixed-in attributes.
---------
481c2ce660
Co-authored-by: Stan Lo <stan001212@gmail.com>
We fixed some issues recently where Bundler would try to activate a
pysch spec with missing extensions and crash. However, as a side effect,
we started printing warnings about missing extensions in situations
where we did not warn before.
It may be interesting to warn on these new situations too, but in order
to minimize changes for now, I'm reverting to printing warnings in the
same situations as before.
51ebff6982
A default gem does not always live in the same place. For example,
Bundler may be installed to `site_dir` when RubyGems have been upgraded.
A more reliable way seems to actually activate the default gem, so that
we can know for sure where it lives.
c69f6dfb18
(https://github.com/ruby/irb/pull/1018)
IRB need to accept bignum history size, but we don't want explicit bignum checks because threshold of bignum and fixnum depends on platform.
5151467e6a
